mirror of
https://github.com/github/codeql.git
synced 2025-12-30 15:46:34 +01:00
Add changes from Michael
This commit is contained in:
@@ -63,7 +63,7 @@ We need to add a tuple to the **sinkModel**\(package, type, subtypes, name, sign
|
||||
pack: codeql/java-all
|
||||
extensible: sinkModel
|
||||
data:
|
||||
- ["java.sql", "Statement", True, "execute", "(String)", "", "Argument[0]", "sql", "manual"]
|
||||
- ["java.sql", "Statement", True, "execute", "(String)", "", "Argument[0]", "sql-injection", "manual"]
|
||||
|
||||
|
||||
Since we are adding a new sink, we need to add a tuple to the **sinkModel** extensible predicate.
|
||||
@@ -79,7 +79,7 @@ The sixth value should be left empty and is out of scope for this documentation.
|
||||
The remaining values are used to define the **access path**, the **kind**, and the **provenance** (origin) of the sink.
|
||||
|
||||
- The seventh value **Argument[0]** is the **access path** to the first argument passed to the method, which means that this is the location of the sink.
|
||||
- The eighth value **sql** is the kind of the sink. The sink kind is used to define the queries where the sink is in scope. In this case - the SQL injection queries.
|
||||
- The eighth value **sql-injection** is the kind of the sink. The sink kind is used to define the queries where the sink is in scope. In this case - the SQL injection queries.
|
||||
- The ninth value **manual** is the provenance of the sink, which is used to identify the origin of the sink.
|
||||
|
||||
Example: Taint source from the **java.net** package
|
||||
@@ -303,7 +303,6 @@ Taint source. Most taint tracking queries will use all sources added to this ext
|
||||
|
||||
- **output**: Access path to the source, where the possibly tainted data flows from.
|
||||
- **kind**: Kind of the source.
|
||||
- **provenance**: Provenance (origin) of the source definition.
|
||||
|
||||
As most sources are used by all taint tracking queries there are only a few different source kinds.
|
||||
The following source kinds are supported:
|
||||
@@ -359,7 +358,6 @@ Flow through (summary). This extensible predicate is used to model flow through
|
||||
- **input**: Access path to the input of the element (where data will flow from to the output).
|
||||
- **output**: Access path to the output of the element (where data will flow to from the input).
|
||||
- **kind**: Kind of the flow through.
|
||||
- **provenance**: Provenance (origin) of the flow through.
|
||||
|
||||
The following kinds are supported:
|
||||
|
||||
@@ -374,7 +372,6 @@ It only has minor impact on the data flow analysis.
|
||||
Manual neutrals are considered high confidence dispatch call targets and can reduce the number of dispatch call targets during data flow analysis (a performance optimization).
|
||||
|
||||
- **kind**: Kind of the neutral. For neutrals the kind can be **summary**, **source**, or **sink** to indicate that the callable is neutral with respect to flow (no summary), source (is not a source) or sink (is not a sink).
|
||||
- **provenance**: Provenance (origin) of the flow through.
|
||||
|
||||
.. _access-paths:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user