mirror of
https://github.com/github/codeql.git
synced 2026-05-26 09:01:22 +02:00
Compare commits
31 Commits
testing/2/
...
rb/modgen-
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
2edbfa0f67 | ||
|
|
9c8ccacd96 | ||
|
|
95bf9fdf1a | ||
|
|
cd7077d74e | ||
|
|
68c62e17bd | ||
|
|
ba8a853751 | ||
|
|
3b95d247ec | ||
|
|
1ef406ce45 | ||
|
|
87202e3f33 | ||
|
|
39f1f7fe9b | ||
|
|
af0874abf1 | ||
|
|
2a8af6d552 | ||
|
|
088aad5de2 | ||
|
|
58c8ae641b | ||
|
|
99cb3e4dc9 | ||
|
|
75ef34355e | ||
|
|
a4799c3b16 | ||
|
|
8e9eea22c0 | ||
|
|
2bf0d926a4 | ||
|
|
669e41347c | ||
|
|
14c88874d2 | ||
|
|
7fed75637e | ||
|
|
2e2df29416 | ||
|
|
f3ffb93b40 | ||
|
|
3074756a1b | ||
|
|
91659ff76d | ||
|
|
e819336b9f | ||
|
|
6b12c8cb3b | ||
|
|
6fa63f13f7 | ||
|
|
182893c756 | ||
|
|
9504f45c87 |
6
.github/workflows/csharp-qltest.yml
vendored
6
.github/workflows/csharp-qltest.yml
vendored
@@ -65,10 +65,7 @@ jobs:
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ github.token }}
|
||||
unit-tests:
|
||||
strategy:
|
||||
matrix:
|
||||
os: [ubuntu-latest, windows-2019]
|
||||
runs-on: ${{ matrix.os }}
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- name: Setup dotnet
|
||||
@@ -81,7 +78,6 @@ jobs:
|
||||
dotnet test -p:RuntimeFrameworkVersion=7.0.2 extractor/Semmle.Extraction.Tests
|
||||
dotnet test -p:RuntimeFrameworkVersion=7.0.2 autobuilder/Semmle.Autobuild.CSharp.Tests
|
||||
dotnet test -p:RuntimeFrameworkVersion=7.0.2 "${{ github.workspace }}/cpp/autobuilder/Semmle.Autobuild.Cpp.Tests"
|
||||
shell: bash
|
||||
stubgentest:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
|
||||
65
.github/workflows/js-ml-tests.yml
vendored
Normal file
65
.github/workflows/js-ml-tests.yml
vendored
Normal file
@@ -0,0 +1,65 @@
|
||||
name: JS ML-powered queries tests
|
||||
|
||||
on:
|
||||
push:
|
||||
paths:
|
||||
- "javascript/ql/experimental/adaptivethreatmodeling/**"
|
||||
- .github/workflows/js-ml-tests.yml
|
||||
- .github/actions/fetch-codeql/action.yml
|
||||
- codeql-workspace.yml
|
||||
branches:
|
||||
- main
|
||||
- "rc/*"
|
||||
pull_request:
|
||||
paths:
|
||||
- "javascript/ql/experimental/adaptivethreatmodeling/**"
|
||||
- .github/workflows/js-ml-tests.yml
|
||||
- .github/actions/fetch-codeql/action.yml
|
||||
- codeql-workspace.yml
|
||||
workflow_dispatch:
|
||||
|
||||
defaults:
|
||||
run:
|
||||
working-directory: javascript/ql/experimental/adaptivethreatmodeling
|
||||
|
||||
jobs:
|
||||
qltest:
|
||||
name: Test QL
|
||||
runs-on: ubuntu-latest-xl
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
- uses: ./.github/actions/fetch-codeql
|
||||
|
||||
- name: Install pack dependencies
|
||||
run: |
|
||||
for pack in modelbuilding src test; do
|
||||
codeql pack install --mode verify -- "${pack}"
|
||||
done
|
||||
|
||||
- name: Cache compilation cache
|
||||
id: query-cache
|
||||
uses: ./.github/actions/cache-query-compilation
|
||||
with:
|
||||
key: js-ml-test
|
||||
|
||||
- name: Check QL compilation
|
||||
run: |
|
||||
codeql query compile \
|
||||
--check-only \
|
||||
--ram 50000 \
|
||||
--additional-packs "${{ github.workspace }}" \
|
||||
--threads=0 \
|
||||
--compilation-cache "${{ steps.query-cache.outputs.cache-dir }}" \
|
||||
-- \
|
||||
lib modelbuilding src
|
||||
|
||||
- name: Run QL tests
|
||||
run: |
|
||||
codeql test run \
|
||||
--threads=0 \
|
||||
--ram 50000 \
|
||||
--additional-packs "${{ github.workspace }}" \
|
||||
--compilation-cache "${{ steps.query-cache.outputs.cache-dir }}" \
|
||||
-- \
|
||||
test
|
||||
@@ -1,22 +1,3 @@
|
||||
## 0.9.3
|
||||
|
||||
No user-facing changes.
|
||||
|
||||
## 0.9.2
|
||||
|
||||
### Deprecated APIs
|
||||
|
||||
* `getAllocatorCall` on `DeleteExpr` and `DeleteArrayExpr` has been deprecated. `getDeallocatorCall` should be used instead.
|
||||
|
||||
### New Features
|
||||
|
||||
* Added `DeleteOrDeleteArrayExpr` as a super type of `DeleteExpr` and `DeleteArrayExpr`
|
||||
|
||||
### Minor Analysis Improvements
|
||||
|
||||
* `delete` and `delete[]` are now modeled as calls to the relevant `operator delete` in the IR. In the case of a dynamic delete call a new instruction `VirtualDeleteFunctionAddress` is used to represent a function that dispatches to the correct delete implementation.
|
||||
* Only the 2 level indirection of `argv` (corresponding to `**argv`) is consided for `FlowSource`.
|
||||
|
||||
## 0.9.1
|
||||
|
||||
No user-facing changes.
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
category: minorAnalysis
|
||||
---
|
||||
* Only the 2 level indirection of `argv` (corresponding to `**argv`) is consided for `FlowSource`.
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
category: feature
|
||||
---
|
||||
* Added `DeleteOrDeleteArrayExpr` as a super type of `DeleteExpr` and `DeleteArrayExpr`
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
category: deprecated
|
||||
---
|
||||
* `getAllocatorCall` on `DeleteExpr` and `DeleteArrayExpr` has been deprecated. `getDeallocatorCall` should be used instead.
|
||||
4
cpp/ql/lib/change-notes/2023-08-29-delete-ir.md
Normal file
4
cpp/ql/lib/change-notes/2023-08-29-delete-ir.md
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
category: minorAnalysis
|
||||
---
|
||||
* `delete` and `delete[]` are now modeled as calls to the relevant `operator delete` in the IR. In the case of a dynamic delete call a new instruction `VirtualDeleteFunctionAddress` is used to represent a function that dispatches to the correct delete implementation.
|
||||
@@ -1,14 +0,0 @@
|
||||
## 0.9.2
|
||||
|
||||
### Deprecated APIs
|
||||
|
||||
* `getAllocatorCall` on `DeleteExpr` and `DeleteArrayExpr` has been deprecated. `getDeallocatorCall` should be used instead.
|
||||
|
||||
### New Features
|
||||
|
||||
* Added `DeleteOrDeleteArrayExpr` as a super type of `DeleteExpr` and `DeleteArrayExpr`
|
||||
|
||||
### Minor Analysis Improvements
|
||||
|
||||
* `delete` and `delete[]` are now modeled as calls to the relevant `operator delete` in the IR. In the case of a dynamic delete call a new instruction `VirtualDeleteFunctionAddress` is used to represent a function that dispatches to the correct delete implementation.
|
||||
* Only the 2 level indirection of `argv` (corresponding to `**argv`) is consided for `FlowSource`.
|
||||
@@ -1,3 +0,0 @@
|
||||
## 0.9.3
|
||||
|
||||
No user-facing changes.
|
||||
@@ -1,2 +1,2 @@
|
||||
---
|
||||
lastReleaseVersion: 0.9.3
|
||||
lastReleaseVersion: 0.9.1
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
name: codeql/cpp-all
|
||||
version: 0.10.0-dev
|
||||
version: 0.9.2-dev
|
||||
groups: cpp
|
||||
dbscheme: semmlecode.cpp.dbscheme
|
||||
extractor: cpp
|
||||
|
||||
@@ -645,24 +645,12 @@ private predicate adjustForPointerArith(PostUpdateNode pun, UseOrPhi use) {
|
||||
)
|
||||
}
|
||||
|
||||
/**
|
||||
* Holds if `nodeFrom` flows to `nodeTo` because there is `def-use` or
|
||||
* `use-use` flow from `defOrUse` to `use`.
|
||||
*
|
||||
* `uncertain` is `true` if the `defOrUse` is an uncertain definition.
|
||||
*/
|
||||
private predicate localSsaFlow(
|
||||
SsaDefOrUse defOrUse, Node nodeFrom, UseOrPhi use, Node nodeTo, boolean uncertain
|
||||
) {
|
||||
nodeToDefOrUse(nodeFrom, defOrUse, uncertain) and
|
||||
adjacentDefRead(defOrUse, use) and
|
||||
useToNode(use, nodeTo) and
|
||||
nodeFrom != nodeTo
|
||||
}
|
||||
|
||||
private predicate ssaFlowImpl(SsaDefOrUse defOrUse, Node nodeFrom, Node nodeTo, boolean uncertain) {
|
||||
exists(UseOrPhi use |
|
||||
localSsaFlow(defOrUse, nodeFrom, use, nodeTo, uncertain)
|
||||
nodeToDefOrUse(nodeFrom, defOrUse, uncertain) and
|
||||
adjacentDefRead(defOrUse, use) and
|
||||
useToNode(use, nodeTo) and
|
||||
nodeFrom != nodeTo
|
||||
or
|
||||
// Initial global variable value to a first use
|
||||
nodeFrom.(InitialGlobalValue).getGlobalDef() = defOrUse and
|
||||
@@ -740,62 +728,15 @@ private predicate isArgumentOfCallable(DataFlowCall call, Node n) {
|
||||
)
|
||||
}
|
||||
|
||||
/**
|
||||
* Holds if there is use-use flow from `pun`'s pre-update node to `n`.
|
||||
*/
|
||||
private predicate postUpdateNodeToFirstUse(PostUpdateNode pun, Node n) {
|
||||
exists(UseOrPhi use |
|
||||
adjustForPointerArith(pun, use) and
|
||||
useToNode(use, n)
|
||||
)
|
||||
}
|
||||
|
||||
private predicate stepUntilNotInCall(DataFlowCall call, Node n1, Node n2) {
|
||||
isArgumentOfCallable(call, n1) and
|
||||
exists(Node mid | localSsaFlow(_, n1, _, mid, _) |
|
||||
isArgumentOfCallable(call, mid) and
|
||||
stepUntilNotInCall(call, mid, n2)
|
||||
or
|
||||
not isArgumentOfCallable(call, mid) and
|
||||
mid = n2
|
||||
)
|
||||
}
|
||||
|
||||
bindingset[n1, n2]
|
||||
pragma[inline_late]
|
||||
private predicate isArgumentOfSameCall(DataFlowCall call, Node n1, Node n2) {
|
||||
isArgumentOfCallable(call, n1) and isArgumentOfCallable(call, n2)
|
||||
}
|
||||
|
||||
/**
|
||||
* Holds if there is def-use or use-use flow from `pun` to `nodeTo`.
|
||||
*
|
||||
* Note: This is more complex than it sounds. Consider a call such as:
|
||||
* ```cpp
|
||||
* write_first_argument(x, x);
|
||||
* sink(x);
|
||||
* ```
|
||||
* Assume flow comes out of the first argument to `write_first_argument`. We
|
||||
* don't want flow to go to the `x` that's also an argument to
|
||||
* `write_first_argument` (because we just flowed out of that function, and we
|
||||
* don't want to flow back into it again).
|
||||
*
|
||||
* We do, however, want flow from the output argument to `x` on the next line, and
|
||||
* similarly we want flow from the second argument of `write_first_argument` to `x`
|
||||
* on the next line.
|
||||
*/
|
||||
/** Holds if there is def-use or use-use flow from `pun` to `nodeTo`. */
|
||||
predicate postUpdateFlow(PostUpdateNode pun, Node nodeTo) {
|
||||
exists(Node preUpdate, Node mid |
|
||||
exists(UseOrPhi use, Node preUpdate |
|
||||
adjustForPointerArith(pun, use) and
|
||||
useToNode(use, nodeTo) and
|
||||
preUpdate = pun.getPreUpdateNode() and
|
||||
postUpdateNodeToFirstUse(pun, mid)
|
||||
|
|
||||
exists(DataFlowCall call |
|
||||
isArgumentOfSameCall(call, preUpdate, mid) and
|
||||
stepUntilNotInCall(call, mid, nodeTo)
|
||||
not exists(DataFlowCall call |
|
||||
isArgumentOfCallable(call, preUpdate) and isArgumentOfCallable(call, nodeTo)
|
||||
)
|
||||
or
|
||||
not isArgumentOfSameCall(_, preUpdate, mid) and
|
||||
nodeTo = mid
|
||||
)
|
||||
}
|
||||
|
||||
|
||||
@@ -1,19 +1,3 @@
|
||||
## 0.7.5
|
||||
|
||||
No user-facing changes.
|
||||
|
||||
## 0.7.4
|
||||
|
||||
### New Queries
|
||||
|
||||
* Added a new query, `cpp/invalid-pointer-deref`, to detect out-of-bounds pointer reads and writes.
|
||||
|
||||
### Minor Analysis Improvements
|
||||
|
||||
* The "Comparison where assignment was intended" query (`cpp/compare-where-assign-meant`) no longer reports comparisons that appear in macro expansions.
|
||||
* Some queries that had repeated results corresponding to different levels of indirection for `argv` now only have a single result.
|
||||
* The `cpp/non-constant-format` query no longer considers an assignment on the right-hand side of another assignment to be a source of non-constant format strings. As a result, the query may now produce fewer results.
|
||||
|
||||
## 0.7.3
|
||||
|
||||
No user-facing changes.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
* @name Potential double free
|
||||
* @description Freeing a resource more than once can lead to undefined behavior and cause memory corruption.
|
||||
* @kind path-problem
|
||||
* @precision high
|
||||
* @precision medium
|
||||
* @id cpp/double-free
|
||||
* @problem.severity warning
|
||||
* @security-severity 9.3
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
* @name Potential use after free
|
||||
* @description An allocated memory block is used after it has been freed. Behavior in such cases is undefined and can cause memory corruption.
|
||||
* @kind path-problem
|
||||
* @precision high
|
||||
* @precision medium
|
||||
* @id cpp/use-after-free
|
||||
* @problem.severity warning
|
||||
* @security-severity 9.3
|
||||
@@ -29,7 +29,8 @@ private predicate externalCallNeverDereferences(FormattingFunctionCall call, int
|
||||
)
|
||||
}
|
||||
|
||||
predicate isUse0(Expr e) {
|
||||
predicate isUse0(DataFlow::Node n, Expr e) {
|
||||
e = n.asExpr() and
|
||||
not isFree(_, e, _) and
|
||||
(
|
||||
e = any(PointerDereferenceExpr pde).getOperand()
|
||||
@@ -42,7 +43,7 @@ predicate isUse0(Expr e) {
|
||||
or
|
||||
// Assume any function without a body will dereference the pointer
|
||||
exists(int i, Call call, Function f |
|
||||
e = call.getArgument(i) and
|
||||
n.asExpr() = call.getArgument(i) and
|
||||
f = call.getTarget() and
|
||||
not f.hasEntryPoint() and
|
||||
// Exclude known functions we know won't dereference the pointer.
|
||||
@@ -56,7 +57,7 @@ module ParameterSinks {
|
||||
import semmle.code.cpp.ir.ValueNumbering
|
||||
|
||||
predicate flowsToUse(DataFlow::Node n) {
|
||||
isUse0(n.asExpr())
|
||||
isUse0(n, _)
|
||||
or
|
||||
exists(DataFlow::Node succ |
|
||||
flowsToUse(succ) and
|
||||
@@ -89,7 +90,7 @@ module ParameterSinks {
|
||||
) {
|
||||
pragma[only_bind_out](source.asParameter()) = pragma[only_bind_out](init.getParameter()) and
|
||||
paramToUse(source, sink) and
|
||||
isUse0(sink.asExpr())
|
||||
isUse0(sink, _)
|
||||
}
|
||||
|
||||
private InitializeParameterInstruction getAnAlwaysDereferencedParameter0() {
|
||||
@@ -138,7 +139,7 @@ module IsUse {
|
||||
private import semmle.code.cpp.ir.dataflow.internal.DataFlowImplCommon
|
||||
|
||||
predicate isUse(DataFlow::Node n, Expr e) {
|
||||
isUse0(e) and n.asExpr() = e
|
||||
isUse0(n, e)
|
||||
or
|
||||
exists(CallInstruction call, InitializeParameterInstruction init |
|
||||
n.asOperand().getDef().getUnconvertedResultExpression() = e and
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
category: newQuery
|
||||
---
|
||||
* Added a new query, `cpp/invalid-pointer-deref`, to detect out-of-bounds pointer reads and writes.
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
category: minorAnalysis
|
||||
---
|
||||
* Some queries that had repeated results corresponding to different levels of indirection for `argv` now only have a single result.
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
category: minorAnalysis
|
||||
---
|
||||
* The `cpp/non-constant-format` query no longer considers an assignment on the right-hand side of another assignment to be a source of non-constant format strings. As a result, the query may now produce fewer results.
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
category: minorAnalysis
|
||||
---
|
||||
* The "Comparison where assignment was intended" query (`cpp/compare-where-assign-meant`) no longer reports comparisons that appear in macro expansions.
|
||||
@@ -1,4 +0,0 @@
|
||||
---
|
||||
category: queryMetadata
|
||||
---
|
||||
* The `cpp/double-free` query has been further improved to reduce false positives and its precision has been increased from `medium` to `high`.
|
||||
@@ -1,4 +0,0 @@
|
||||
---
|
||||
category: queryMetadata
|
||||
---
|
||||
* The `cpp/use-after-free` query has been further improved to reduce false positives and its precision has been increased from `medium` to `high`.
|
||||
@@ -1,11 +0,0 @@
|
||||
## 0.7.4
|
||||
|
||||
### New Queries
|
||||
|
||||
* Added a new query, `cpp/invalid-pointer-deref`, to detect out-of-bounds pointer reads and writes.
|
||||
|
||||
### Minor Analysis Improvements
|
||||
|
||||
* The "Comparison where assignment was intended" query (`cpp/compare-where-assign-meant`) no longer reports comparisons that appear in macro expansions.
|
||||
* Some queries that had repeated results corresponding to different levels of indirection for `argv` now only have a single result.
|
||||
* The `cpp/non-constant-format` query no longer considers an assignment on the right-hand side of another assignment to be a source of non-constant format strings. As a result, the query may now produce fewer results.
|
||||
@@ -1,3 +0,0 @@
|
||||
## 0.7.5
|
||||
|
||||
No user-facing changes.
|
||||
@@ -1,2 +1,2 @@
|
||||
---
|
||||
lastReleaseVersion: 0.7.5
|
||||
lastReleaseVersion: 0.7.3
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
name: codeql/cpp-queries
|
||||
version: 0.8.0-dev
|
||||
groups:
|
||||
version: 0.7.4-dev
|
||||
groups:
|
||||
- cpp
|
||||
- queries
|
||||
dependencies:
|
||||
codeql/cpp-all: ${workspace}
|
||||
codeql/suite-helpers: ${workspace}
|
||||
codeql/util: ${workspace}
|
||||
codeql/cpp-all: ${workspace}
|
||||
codeql/suite-helpers: ${workspace}
|
||||
codeql/util: ${workspace}
|
||||
suites: codeql-suites
|
||||
extractor: cpp
|
||||
defaultSuiteFile: codeql-suites/cpp-code-scanning.qls
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
WARNING: Module TaintedWithPath has been deprecated and may be removed in future (tainted.ql:10,8-47)
|
||||
WARNING: Predicate tainted has been deprecated and may be removed in future (tainted.ql:21,3-28)
|
||||
testFailures
|
||||
failures
|
||||
testFailures
|
||||
|
||||
@@ -788,12 +788,4 @@ void test_sometimes_calls_sink_switch() {
|
||||
sometimes_calls_sink_switch(source(), 1);
|
||||
sometimes_calls_sink_switch(0, 0);
|
||||
sometimes_calls_sink_switch(source(), 0);
|
||||
}
|
||||
|
||||
void intPointerSource(int *ref_source, const int* another_arg);
|
||||
|
||||
void test() {
|
||||
MyStruct a;
|
||||
intPointerSource(a.content, a.content);
|
||||
indirect_sink(a.content); // $ ast ir
|
||||
}
|
||||
@@ -46,6 +46,3 @@
|
||||
| test.cpp:595:8:595:9 | xs | test.cpp:597:9:597:10 | xs |
|
||||
| test.cpp:733:7:733:7 | x | test.cpp:734:41:734:41 | x |
|
||||
| test.cpp:733:7:733:7 | x | test.cpp:735:8:735:8 | x |
|
||||
| test.cpp:796:12:796:12 | a | test.cpp:797:20:797:20 | a |
|
||||
| test.cpp:796:12:796:12 | a | test.cpp:797:31:797:31 | a |
|
||||
| test.cpp:796:12:796:12 | a | test.cpp:798:17:798:17 | a |
|
||||
|
||||
@@ -96,7 +96,6 @@
|
||||
| test_free.cpp:255:10:255:10 | p |
|
||||
| test_free.cpp:260:9:260:9 | p |
|
||||
| test_free.cpp:263:12:263:12 | p |
|
||||
| test_free.cpp:269:7:269:11 | ... = ... |
|
||||
| virtual.cpp:18:10:18:10 | a |
|
||||
| virtual.cpp:19:10:19:10 | c |
|
||||
| virtual.cpp:38:10:38:10 | b |
|
||||
|
||||
@@ -1,2 +1 @@
|
||||
| test_free.cpp:36:22:36:35 | ... = ... | This memory allocation may not be released at $@. | test_free.cpp:38:1:38:1 | return ... | this exit point |
|
||||
| test_free.cpp:267:12:267:17 | call to malloc | This memory allocation may not be released at $@. | test_free.cpp:270:1:270:1 | return ... | this exit point |
|
||||
|
||||
@@ -261,10 +261,4 @@ void test_ref_delete(int *&p) {
|
||||
p = new int;
|
||||
use(p); // GOOD
|
||||
delete p; // GOOD
|
||||
}
|
||||
|
||||
void test_free_assign() {
|
||||
void *a = malloc(10);
|
||||
void *b;
|
||||
free(b = a); // GOOD
|
||||
}
|
||||
@@ -7,7 +7,6 @@ edges
|
||||
| overflowdestination.cpp:50:52:50:54 | src indirection | overflowdestination.cpp:53:15:53:17 | src indirection |
|
||||
| overflowdestination.cpp:50:52:50:54 | src indirection | overflowdestination.cpp:54:9:54:12 | memcpy output argument |
|
||||
| overflowdestination.cpp:53:9:53:12 | memcpy output argument | overflowdestination.cpp:54:9:54:12 | memcpy output argument |
|
||||
| overflowdestination.cpp:54:9:54:12 | memcpy output argument | overflowdestination.cpp:54:9:54:12 | memcpy output argument |
|
||||
| overflowdestination.cpp:57:52:57:54 | src indirection | overflowdestination.cpp:64:16:64:19 | src2 indirection |
|
||||
| overflowdestination.cpp:73:8:73:10 | fgets output argument | overflowdestination.cpp:75:30:75:32 | src indirection |
|
||||
| overflowdestination.cpp:73:8:73:10 | fgets output argument | overflowdestination.cpp:76:30:76:32 | src indirection |
|
||||
|
||||
@@ -60,7 +60,7 @@ namespace Semmle.Extraction.CSharp.DependencyFetching
|
||||
this.progressMonitor.FindingFiles(srcDir);
|
||||
|
||||
packageDirectory = new TemporaryDirectory(ComputeTempDirectory(sourceDir.FullName));
|
||||
tempWorkingDirectory = new TemporaryDirectory(FileUtils.GetTemporaryWorkingDirectory(out cleanupTempWorkingDirectory));
|
||||
tempWorkingDirectory = new TemporaryDirectory(GetTemporaryWorkingDirectory(out cleanupTempWorkingDirectory));
|
||||
|
||||
var allFiles = GetAllFiles();
|
||||
var binaryFileExtensions = new HashSet<string>(new[] { ".dll", ".exe" }); // TODO: add more binary file extensions.
|
||||
@@ -286,6 +286,22 @@ namespace Semmle.Extraction.CSharp.DependencyFetching
|
||||
return Path.Combine(Path.GetTempPath(), "GitHub", "packages", sb.ToString());
|
||||
}
|
||||
|
||||
private static string GetTemporaryWorkingDirectory(out bool cleanupTempWorkingDirectory)
|
||||
{
|
||||
cleanupTempWorkingDirectory = false;
|
||||
var tempFolder = EnvironmentVariables.GetScratchDirectory();
|
||||
|
||||
if (string.IsNullOrEmpty(tempFolder))
|
||||
{
|
||||
var tempPath = Path.GetTempPath();
|
||||
var name = Guid.NewGuid().ToString("N").ToUpper();
|
||||
tempFolder = Path.Combine(tempPath, "GitHub", name);
|
||||
cleanupTempWorkingDirectory = true;
|
||||
}
|
||||
|
||||
return tempFolder;
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// Creates a temporary directory with the given subfolder name.
|
||||
/// The created directory might be inside the repo folder, and it is deleted when the object is disposed.
|
||||
|
||||
@@ -30,46 +30,29 @@ namespace Semmle.Extraction.CSharp.Standalone
|
||||
IProgressMonitor progressMonitor,
|
||||
Stopwatch stopwatch)
|
||||
{
|
||||
var output = FileUtils.CreateTemporaryFile(".dll", out var shouldCleanUpContainingFolder);
|
||||
|
||||
try
|
||||
{
|
||||
CSharp.Extractor.Analyse(stopwatch, analyser, options,
|
||||
references => GetResolvedReferencesStandalone(referencePaths, references),
|
||||
(analyser, syntaxTrees) => CSharp.Extractor.ReadSyntaxTrees(sources, analyser, null, null, syntaxTrees),
|
||||
(syntaxTrees, references) => CSharpCompilation.Create(
|
||||
output.Name, syntaxTrees, references, new CSharpCompilationOptions(OutputKind.ConsoleApplication, allowUnsafe: true)
|
||||
),
|
||||
(compilation, options) => analyser.Initialize(output.FullName, compilation, options),
|
||||
_ => { },
|
||||
() =>
|
||||
{
|
||||
foreach (var type in analyser.MissingNamespaces)
|
||||
{
|
||||
progressMonitor.MissingNamespace(type);
|
||||
}
|
||||
|
||||
foreach (var type in analyser.MissingTypes)
|
||||
{
|
||||
progressMonitor.MissingType(type);
|
||||
}
|
||||
|
||||
progressMonitor.MissingSummary(analyser.MissingTypes.Count(), analyser.MissingNamespaces.Count());
|
||||
});
|
||||
}
|
||||
finally
|
||||
{
|
||||
try
|
||||
CSharp.Extractor.Analyse(stopwatch, analyser, options,
|
||||
references => GetResolvedReferencesStandalone(referencePaths, references),
|
||||
(analyser, syntaxTrees) => CSharp.Extractor.ReadSyntaxTrees(sources, analyser, null, null, syntaxTrees),
|
||||
(syntaxTrees, references) => CSharpCompilation.Create(
|
||||
"csharp.dll", syntaxTrees, references, new CSharpCompilationOptions(OutputKind.ConsoleApplication, allowUnsafe: true)
|
||||
),
|
||||
(compilation, options) => analyser.Initialize(compilation, options),
|
||||
() => { },
|
||||
_ => { },
|
||||
() =>
|
||||
{
|
||||
FileUtils.TryDelete(output.FullName);
|
||||
if (shouldCleanUpContainingFolder)
|
||||
foreach (var type in analyser.MissingNamespaces)
|
||||
{
|
||||
output.Directory?.Delete(true);
|
||||
progressMonitor.MissingNamespace(type);
|
||||
}
|
||||
}
|
||||
catch
|
||||
{ }
|
||||
}
|
||||
|
||||
foreach (var type in analyser.MissingTypes)
|
||||
{
|
||||
progressMonitor.MissingType(type);
|
||||
}
|
||||
|
||||
progressMonitor.MissingSummary(analyser.MissingTypes.Count(), analyser.MissingNamespaces.Count());
|
||||
});
|
||||
}
|
||||
|
||||
private static void ExtractStandalone(
|
||||
|
||||
@@ -1,6 +1,4 @@
|
||||
using System;
|
||||
using System.Collections.Generic;
|
||||
using System.IO;
|
||||
using Microsoft.CodeAnalysis.CSharp;
|
||||
using Semmle.Util.Logging;
|
||||
|
||||
@@ -13,15 +11,13 @@ namespace Semmle.Extraction.CSharp
|
||||
{
|
||||
}
|
||||
|
||||
public void Initialize(string outputPath, CSharpCompilation compilationIn, CommonOptions options)
|
||||
public void Initialize(CSharpCompilation compilationIn, CommonOptions options)
|
||||
{
|
||||
compilation = compilationIn;
|
||||
extractor = new StandaloneExtractor(outputPath, Logger, PathTransformer, options);
|
||||
extractor = new StandaloneExtractor(Logger, PathTransformer, options);
|
||||
this.options = options;
|
||||
LogExtractorInfo(Extraction.Extractor.Version);
|
||||
SetReferencePaths();
|
||||
|
||||
Entities.Compilation.Settings = (Directory.GetCurrentDirectory(), Array.Empty<string>());
|
||||
}
|
||||
|
||||
#nullable disable warnings
|
||||
@@ -68,7 +68,7 @@ public static class StubGenerator
|
||||
var stubPath = FileUtils.NestPaths(logger, outputPath, path.Replace(".dll", ".cs"));
|
||||
stubPaths.Add(stubPath);
|
||||
using var fileStream = new FileStream(stubPath, FileMode.Create, FileAccess.Write);
|
||||
using var writer = new StreamWriter(fileStream, new UTF8Encoding(false)) { NewLine = "\n" };
|
||||
using var writer = new StreamWriter(fileStream, new UTF8Encoding(false));
|
||||
|
||||
var visitor = new StubVisitor(writer, relevantSymbol);
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ namespace Semmle.Extraction.CSharp.Entities
|
||||
if (init is null)
|
||||
{
|
||||
// This is the output assembly
|
||||
assemblyPath = cx.Extractor.OutputPath;
|
||||
assemblyPath = ((TracingExtractor)cx.Extractor).OutputPath;
|
||||
assembly = cx.Compilation.Assembly;
|
||||
}
|
||||
else
|
||||
@@ -63,6 +63,8 @@ namespace Semmle.Extraction.CSharp.Entities
|
||||
|
||||
public static Assembly CreateOutputAssembly(Context cx)
|
||||
{
|
||||
if (cx.Extractor.Mode.HasFlag(ExtractorMode.Standalone))
|
||||
throw new InternalError("Attempting to create the output assembly in standalone extraction mode");
|
||||
return AssemblyConstructorFactory.Instance.CreateEntity(cx, outputAssemblyCacheKey, null);
|
||||
}
|
||||
|
||||
|
||||
@@ -63,7 +63,10 @@ namespace Semmle.Extraction.CSharp.Entities
|
||||
|
||||
if (attributeSyntax is not null)
|
||||
{
|
||||
trapFile.attribute_location(this, Assembly.CreateOutputAssembly(Context));
|
||||
if (!Context.Extractor.Mode.HasFlag(ExtractorMode.Standalone))
|
||||
{
|
||||
trapFile.attribute_location(this, Assembly.CreateOutputAssembly(Context));
|
||||
}
|
||||
|
||||
TypeMention.Create(Context, attributeSyntax.Name, this, type);
|
||||
}
|
||||
|
||||
@@ -97,7 +97,7 @@ namespace Semmle.Extraction.CSharp.Entities
|
||||
{
|
||||
// Some built in operators lack locations, so loc is null.
|
||||
yield return Context.CreateLocation(ReportingLocation);
|
||||
if (loc.Kind == LocationKind.SourceFile)
|
||||
if (!Context.Extractor.Mode.HasFlag(ExtractorMode.Standalone) && loc.Kind == LocationKind.SourceFile)
|
||||
yield return Assembly.CreateOutputAssembly(Context);
|
||||
}
|
||||
}
|
||||
|
||||
@@ -15,8 +15,11 @@ namespace Semmle.Extraction.CSharp.Entities
|
||||
trapFile.preprocessor_directive_active(this, Symbol.IsActive);
|
||||
trapFile.preprocessor_directive_location(this, Context.CreateLocation(ReportingLocation));
|
||||
|
||||
var compilation = Compilation.Create(Context);
|
||||
trapFile.preprocessor_directive_compilation(this, compilation);
|
||||
if (!Context.Extractor.Mode.HasFlag(ExtractorMode.Standalone))
|
||||
{
|
||||
var compilation = Compilation.Create(Context);
|
||||
trapFile.preprocessor_directive_compilation(this, compilation);
|
||||
}
|
||||
}
|
||||
|
||||
protected abstract void PopulatePreprocessor(TextWriter trapFile);
|
||||
|
||||
@@ -108,7 +108,7 @@ namespace Semmle.Extraction.CSharp.Entities
|
||||
foreach (var l in GetLocations(Symbol))
|
||||
yield return Context.CreateLocation(l);
|
||||
|
||||
if (Symbol.DeclaringSyntaxReferences.Any())
|
||||
if (!Context.Extractor.Mode.HasFlag(ExtractorMode.Standalone) && Symbol.DeclaringSyntaxReferences.Any())
|
||||
yield return Assembly.CreateOutputAssembly(Context);
|
||||
}
|
||||
}
|
||||
|
||||
@@ -19,8 +19,6 @@ namespace Semmle.Extraction.CSharp
|
||||
protected Extraction.Extractor? extractor;
|
||||
protected CSharpCompilation? compilation;
|
||||
protected CommonOptions? options;
|
||||
private protected Entities.Compilation? compilationEntity;
|
||||
private IDisposable? compilationTrapFile;
|
||||
|
||||
private readonly object progressMutex = new object();
|
||||
|
||||
@@ -228,35 +226,8 @@ namespace Semmle.Extraction.CSharp
|
||||
}
|
||||
}
|
||||
|
||||
private void DoAnalyseCompilation()
|
||||
{
|
||||
try
|
||||
{
|
||||
var assemblyPath = extractor.OutputPath;
|
||||
var transformedAssemblyPath = PathTransformer.Transform(assemblyPath);
|
||||
var assembly = compilation.Assembly;
|
||||
var trapWriter = transformedAssemblyPath.CreateTrapWriter(Logger, options.TrapCompression, discardDuplicates: false);
|
||||
compilationTrapFile = trapWriter; // Dispose later
|
||||
var cx = new Context(extractor, compilation.Clone(), trapWriter, new AssemblyScope(assembly, assemblyPath), addAssemblyTrapPrefix);
|
||||
|
||||
compilationEntity = Entities.Compilation.Create(cx);
|
||||
}
|
||||
catch (Exception ex) // lgtm[cs/catch-of-all-exceptions]
|
||||
{
|
||||
Logger.Log(Severity.Error, " Unhandled exception analyzing {0}: {1}", "compilation", ex);
|
||||
}
|
||||
}
|
||||
|
||||
#nullable restore warnings
|
||||
|
||||
/// <summary>
|
||||
/// Extracts compilation-wide entities, such as compilations and compiler diagnostics.
|
||||
/// </summary>
|
||||
public void AnalyseCompilation()
|
||||
{
|
||||
extractionTasks.Add(() => DoAnalyseCompilation());
|
||||
}
|
||||
|
||||
private static bool FileIsUpToDate(string src, string dest)
|
||||
{
|
||||
return File.Exists(dest) &&
|
||||
@@ -304,8 +275,6 @@ namespace Semmle.Extraction.CSharp
|
||||
Logger.Log(Severity.Info, "EXTRACTION SUCCEEDED in {0}", stopWatch.Elapsed);
|
||||
|
||||
Logger.Dispose();
|
||||
|
||||
compilationTrapFile?.Dispose();
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
|
||||
@@ -302,6 +302,7 @@ namespace Semmle.Extraction.CSharp
|
||||
Func<Analyser, List<SyntaxTree>, IEnumerable<Action>> getSyntaxTreeTasks,
|
||||
Func<IEnumerable<SyntaxTree>, IEnumerable<MetadataReference>, CSharpCompilation> getCompilation,
|
||||
Action<CSharpCompilation, CommonOptions> initializeAnalyser,
|
||||
Action analyseCompilation,
|
||||
Action<Entities.PerformanceMetrics> logPerformance,
|
||||
Action postProcess)
|
||||
{
|
||||
@@ -331,7 +332,7 @@ namespace Semmle.Extraction.CSharp
|
||||
var compilation = getCompilation(syntaxTrees, references);
|
||||
|
||||
initializeAnalyser(compilation, options);
|
||||
analyser.AnalyseCompilation();
|
||||
analyseCompilation();
|
||||
analyser.AnalyseReferences();
|
||||
|
||||
foreach (var tree in compilation.SyntaxTrees)
|
||||
@@ -415,6 +416,7 @@ namespace Semmle.Extraction.CSharp
|
||||
);
|
||||
},
|
||||
(compilation, options) => analyser.EndInitialize(compilerArguments, options, compilation),
|
||||
() => analyser.AnalyseCompilation(),
|
||||
performance => analyser.LogPerformance(performance),
|
||||
() => { });
|
||||
}
|
||||
|
||||
@@ -9,8 +9,11 @@ using Semmle.Util.Logging;
|
||||
|
||||
namespace Semmle.Extraction.CSharp
|
||||
{
|
||||
public class TracingAnalyser : Analyser
|
||||
public class TracingAnalyser : Analyser, IDisposable
|
||||
{
|
||||
private Entities.Compilation? compilationEntity;
|
||||
private IDisposable? compilationTrapFile;
|
||||
|
||||
private bool init;
|
||||
|
||||
public TracingAnalyser(IProgressMonitor pm, ILogger logger, bool addAssemblyTrapPrefix, PathTransformer pathTransformer)
|
||||
@@ -52,6 +55,20 @@ namespace Semmle.Extraction.CSharp
|
||||
CompilationErrors += FilteredDiagnostics.Count();
|
||||
}
|
||||
|
||||
public override void Dispose()
|
||||
{
|
||||
compilationTrapFile?.Dispose();
|
||||
base.Dispose();
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// Extracts compilation-wide entities, such as compilations and compiler diagnostics.
|
||||
/// </summary>
|
||||
public void AnalyseCompilation()
|
||||
{
|
||||
extractionTasks.Add(() => DoAnalyseCompilation());
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// Logs information about the extractor, as well as the arguments to Roslyn.
|
||||
/// </summary>
|
||||
@@ -176,6 +193,25 @@ namespace Semmle.Extraction.CSharp
|
||||
}
|
||||
}
|
||||
|
||||
private void DoAnalyseCompilation()
|
||||
{
|
||||
try
|
||||
{
|
||||
var assemblyPath = ((TracingExtractor?)extractor).OutputPath;
|
||||
var transformedAssemblyPath = PathTransformer.Transform(assemblyPath);
|
||||
var assembly = compilation.Assembly;
|
||||
var trapWriter = transformedAssemblyPath.CreateTrapWriter(Logger, options.TrapCompression, discardDuplicates: false);
|
||||
compilationTrapFile = trapWriter; // Dispose later
|
||||
var cx = new Context(extractor, compilation.Clone(), trapWriter, new AssemblyScope(assembly, assemblyPath), addAssemblyTrapPrefix);
|
||||
|
||||
compilationEntity = Entities.Compilation.Create(cx);
|
||||
}
|
||||
catch (Exception ex) // lgtm[cs/catch-of-all-exceptions]
|
||||
{
|
||||
Logger.Log(Severity.Error, " Unhandled exception analyzing {0}: {1}", "compilation", ex);
|
||||
}
|
||||
}
|
||||
|
||||
public void LogPerformance(Entities.PerformanceMetrics p) => compilationEntity.PopulatePerformance(p);
|
||||
|
||||
#nullable restore warnings
|
||||
|
||||
@@ -82,6 +82,9 @@ namespace Semmle.Extraction.CSharp.Populators
|
||||
|
||||
public override void VisitAttributeList(AttributeListSyntax node)
|
||||
{
|
||||
if (Cx.Extractor.Mode.HasFlag(ExtractorMode.Standalone))
|
||||
return;
|
||||
|
||||
var outputAssembly = Assembly.CreateOutputAssembly(Cx);
|
||||
var kind = node.Target?.Identifier.Kind() switch
|
||||
{
|
||||
|
||||
@@ -13,7 +13,7 @@ namespace Semmle.Extraction.Tests;
|
||||
/// </summary>
|
||||
public class StubGeneratorTests
|
||||
{
|
||||
[Fact]
|
||||
// [Fact]
|
||||
public void StubGeneratorFieldTest()
|
||||
{
|
||||
// Setup
|
||||
@@ -36,7 +36,7 @@ public const string MyField2 = default;
|
||||
Assert.Equal(expected, stub);
|
||||
}
|
||||
|
||||
[Fact]
|
||||
// [Fact]
|
||||
public void StubGeneratorMethodTest()
|
||||
{
|
||||
// Setup
|
||||
@@ -61,7 +61,7 @@ public int M1(string arg1) => throw null;
|
||||
var st = CSharpSyntaxTree.ParseText(source);
|
||||
var compilation = CSharpCompilation.Create(null, new[] { st });
|
||||
var sb = new StringBuilder();
|
||||
var visitor = new StubVisitor(new StringWriter(sb) { NewLine = "\n" }, new RelevantSymbolStub());
|
||||
var visitor = new StubVisitor(new StringWriter(sb), new RelevantSymbolStub());
|
||||
compilation.GlobalNamespace.Accept(visitor);
|
||||
return sb.ToString();
|
||||
}
|
||||
|
||||
@@ -9,16 +9,14 @@ namespace Semmle.Extraction
|
||||
public abstract class Extractor
|
||||
{
|
||||
public abstract ExtractorMode Mode { get; }
|
||||
public string OutputPath { get; }
|
||||
|
||||
/// <summary>
|
||||
/// Creates a new extractor instance for one compilation unit.
|
||||
/// </summary>
|
||||
/// <param name="logger">The object used for logging.</param>
|
||||
/// <param name="pathTransformer">The object used for path transformations.</param>
|
||||
protected Extractor(string outputPath, ILogger logger, PathTransformer pathTransformer)
|
||||
protected Extractor(ILogger logger, PathTransformer pathTransformer)
|
||||
{
|
||||
OutputPath = outputPath;
|
||||
Logger = logger;
|
||||
PathTransformer = pathTransformer;
|
||||
}
|
||||
|
||||
@@ -11,7 +11,7 @@ namespace Semmle.Extraction
|
||||
/// </summary>
|
||||
/// <param name="logger">The object used for logging.</param>
|
||||
/// <param name="pathTransformer">The object used for path transformations.</param>
|
||||
public StandaloneExtractor(string outputPath, ILogger logger, PathTransformer pathTransformer, CommonOptions options) : base(outputPath, logger, pathTransformer)
|
||||
public StandaloneExtractor(ILogger logger, PathTransformer pathTransformer, CommonOptions options) : base(logger, pathTransformer)
|
||||
{
|
||||
Mode = ExtractorMode.Standalone;
|
||||
if (options.QlTest)
|
||||
|
||||
@@ -5,6 +5,7 @@ namespace Semmle.Extraction
|
||||
public class TracingExtractor : Extractor
|
||||
{
|
||||
public override ExtractorMode Mode { get; }
|
||||
public string OutputPath { get; }
|
||||
|
||||
/// <summary>
|
||||
/// Creates a new extractor instance for one compilation unit.
|
||||
@@ -12,8 +13,9 @@ namespace Semmle.Extraction
|
||||
/// <param name="outputPath">The name of the output DLL/EXE, or null if not specified (standalone extraction).</param>
|
||||
/// <param name="logger">The object used for logging.</param>
|
||||
/// <param name="pathTransformer">The object used for path transformations.</param>
|
||||
public TracingExtractor(string outputPath, ILogger logger, PathTransformer pathTransformer, CommonOptions options) : base(outputPath, logger, pathTransformer)
|
||||
public TracingExtractor(string outputPath, ILogger logger, PathTransformer pathTransformer, CommonOptions options) : base(logger, pathTransformer)
|
||||
{
|
||||
OutputPath = outputPath;
|
||||
Mode = ExtractorMode.None;
|
||||
if (options.QlTest)
|
||||
{
|
||||
|
||||
@@ -143,37 +143,5 @@ namespace Semmle.Util
|
||||
}
|
||||
return nested;
|
||||
}
|
||||
|
||||
public static string GetTemporaryWorkingDirectory(out bool shouldCleanUp)
|
||||
{
|
||||
shouldCleanUp = false;
|
||||
var tempFolder = EnvironmentVariables.GetScratchDirectory();
|
||||
|
||||
if (string.IsNullOrEmpty(tempFolder))
|
||||
{
|
||||
var tempPath = Path.GetTempPath();
|
||||
var name = Guid.NewGuid().ToString("N").ToUpper();
|
||||
tempFolder = Path.Combine(tempPath, "GitHub", name);
|
||||
shouldCleanUp = true;
|
||||
}
|
||||
|
||||
return tempFolder;
|
||||
}
|
||||
|
||||
public static FileInfo CreateTemporaryFile(string extension, out bool shouldCleanUpContainingFolder)
|
||||
{
|
||||
var tempFolder = GetTemporaryWorkingDirectory(out shouldCleanUpContainingFolder);
|
||||
Directory.CreateDirectory(tempFolder);
|
||||
string outputPath;
|
||||
do
|
||||
{
|
||||
outputPath = Path.Combine(tempFolder, Path.GetRandomFileName() + extension);
|
||||
}
|
||||
while (File.Exists(outputPath));
|
||||
|
||||
File.Create(outputPath);
|
||||
|
||||
return new FileInfo(outputPath);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@@ -1,11 +1,3 @@
|
||||
## 1.6.5
|
||||
|
||||
No user-facing changes.
|
||||
|
||||
## 1.6.4
|
||||
|
||||
No user-facing changes.
|
||||
|
||||
## 1.6.3
|
||||
|
||||
No user-facing changes.
|
||||
|
||||
@@ -1,3 +0,0 @@
|
||||
## 1.6.4
|
||||
|
||||
No user-facing changes.
|
||||
@@ -1,3 +0,0 @@
|
||||
## 1.6.5
|
||||
|
||||
No user-facing changes.
|
||||
@@ -1,2 +1,2 @@
|
||||
---
|
||||
lastReleaseVersion: 1.6.5
|
||||
lastReleaseVersion: 1.6.3
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
name: codeql/csharp-solorigate-all
|
||||
version: 1.7.0-dev
|
||||
version: 1.6.4-dev
|
||||
groups:
|
||||
- csharp
|
||||
- solorigate
|
||||
- csharp
|
||||
- solorigate
|
||||
library: true
|
||||
dependencies:
|
||||
codeql/csharp-all: ${workspace}
|
||||
codeql/csharp-all: ${workspace}
|
||||
warnOnImplicitThis: true
|
||||
|
||||
@@ -1,11 +1,3 @@
|
||||
## 1.6.5
|
||||
|
||||
No user-facing changes.
|
||||
|
||||
## 1.6.4
|
||||
|
||||
No user-facing changes.
|
||||
|
||||
## 1.6.3
|
||||
|
||||
No user-facing changes.
|
||||
|
||||
@@ -1,3 +0,0 @@
|
||||
## 1.6.4
|
||||
|
||||
No user-facing changes.
|
||||
@@ -1,3 +0,0 @@
|
||||
## 1.6.5
|
||||
|
||||
No user-facing changes.
|
||||
@@ -1,2 +1,2 @@
|
||||
---
|
||||
lastReleaseVersion: 1.6.5
|
||||
lastReleaseVersion: 1.6.3
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
name: codeql/csharp-solorigate-queries
|
||||
version: 1.7.0-dev
|
||||
version: 1.6.4-dev
|
||||
groups:
|
||||
- csharp
|
||||
- solorigate
|
||||
- csharp
|
||||
- solorigate
|
||||
defaultSuiteFile: codeql-suites/solorigate.qls
|
||||
dependencies:
|
||||
codeql/csharp-all: ${workspace}
|
||||
codeql/csharp-solorigate-all: ${workspace}
|
||||
codeql/csharp-all: ${workspace}
|
||||
codeql/csharp-solorigate-all: ${workspace}
|
||||
warnOnImplicitThis: true
|
||||
|
||||
@@ -1,13 +1,3 @@
|
||||
## 0.7.5
|
||||
|
||||
No user-facing changes.
|
||||
|
||||
## 0.7.4
|
||||
|
||||
### Minor Analysis Improvements
|
||||
|
||||
* The `--nostdlib` extractor option for the standalone extractor has been removed.
|
||||
|
||||
## 0.7.3
|
||||
|
||||
### Minor Analysis Improvements
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
## 0.7.4
|
||||
|
||||
### Minor Analysis Improvements
|
||||
|
||||
* The `--nostdlib` extractor option for the standalone extractor has been removed.
|
||||
---
|
||||
category: minorAnalysis
|
||||
---
|
||||
* The `--nostdlib` extractor option for the standalone extractor has been removed.
|
||||
@@ -1,3 +0,0 @@
|
||||
## 0.7.5
|
||||
|
||||
No user-facing changes.
|
||||
@@ -1,2 +1,2 @@
|
||||
---
|
||||
lastReleaseVersion: 0.7.5
|
||||
lastReleaseVersion: 0.7.3
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
name: codeql/csharp-all
|
||||
version: 0.8.0-dev
|
||||
version: 0.7.4-dev
|
||||
groups: csharp
|
||||
dbscheme: semmlecode.csharp.dbscheme
|
||||
extractor: csharp
|
||||
|
||||
@@ -1,11 +1,3 @@
|
||||
## 0.7.5
|
||||
|
||||
No user-facing changes.
|
||||
|
||||
## 0.7.4
|
||||
|
||||
No user-facing changes.
|
||||
|
||||
## 0.7.3
|
||||
|
||||
No user-facing changes.
|
||||
|
||||
@@ -1,3 +0,0 @@
|
||||
## 0.7.4
|
||||
|
||||
No user-facing changes.
|
||||
@@ -1,3 +0,0 @@
|
||||
## 0.7.5
|
||||
|
||||
No user-facing changes.
|
||||
@@ -1,2 +1,2 @@
|
||||
---
|
||||
lastReleaseVersion: 0.7.5
|
||||
lastReleaseVersion: 0.7.3
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
name: codeql/csharp-queries
|
||||
version: 0.8.0-dev
|
||||
groups:
|
||||
version: 0.7.4-dev
|
||||
groups:
|
||||
- csharp
|
||||
- queries
|
||||
suites: codeql-suites
|
||||
|
||||
@@ -1,35 +1,4 @@
|
||||
compilationMessages
|
||||
| errors.cs:6:1:6:22 | CS8019: Unnecessary using directive. |
|
||||
| errors.cs:6:7:6:21 | CS0246: The type or namespace name 'NoSuchAssembly1' could not be found (are you missing a using directive or an assembly reference?) |
|
||||
| errors.cs:7:1:7:41 | CS8019: Unnecessary using directive. |
|
||||
| errors.cs:7:14:7:28 | CS0246: The type or namespace name 'NoSuchAssembly2' could not be found (are you missing a using directive or an assembly reference?) |
|
||||
| errors.cs:16:9:16:17 | CS0246: The type or namespace name 'ErrorType' could not be found (are you missing a using directive or an assembly reference?) |
|
||||
| errors.cs:16:19:16:20 | CS0649: Field 'C1.f1' is never assigned to, and will always have its default value null |
|
||||
| errors.cs:25:18:25:17 | CS1002: ; expected |
|
||||
| errors.cs:30:3:30:3 | CS1022: Type or namespace definition, or end-of-file expected |
|
||||
| errors.cs:33:9:33:10 | CS0101: The namespace 'ErrorRecovery' already contains a definition for 'C1' |
|
||||
| errors.cs:50:12:50:13 | CS0169: The field 'C2.c1' is never used |
|
||||
| errors.cs:51:21:51:22 | CS1729: 'C2' does not contain a constructor that takes 1 arguments |
|
||||
| errors.cs:53:9:53:17 | CS0246: The type or namespace name 'ErrorType' could not be found (are you missing a using directive or an assembly reference?) |
|
||||
| errors.cs:53:21:53:29 | CS0246: The type or namespace name 'ErrorType' could not be found (are you missing a using directive or an assembly reference?) |
|
||||
| errors.cs:59:21:59:20 | CS1026: ) expected |
|
||||
| errors.cs:67:22:67:22 | CS0621: 'C3.M()': virtual or abstract members cannot be private |
|
||||
| errors.cs:72:22:72:22 | CS0621: 'C4.M(int, string, bool, bool)': virtual or abstract members cannot be private |
|
||||
| errors.cs:74:17:74:17 | CS0219: The variable 'x' is assigned but its value is never used |
|
||||
| errors.cs:75:17:75:17 | CS0128: A local variable or function named 'x' is already defined in this scope |
|
||||
| errors.cs:79:11:79:12 | CS0263: Partial declarations of 'C5' must not specify different base classes |
|
||||
| errors.cs:82:13:82:13 | CS0414: The field 'C5.F' is assigned but its value is never used |
|
||||
| errors.cs:83:23:83:23 | CS0547: 'C5.M': property or indexer cannot have void type |
|
||||
| errors.cs:83:23:83:23 | CS0548: 'C5.M': property or indexer must have at least one accessor |
|
||||
| errors.cs:83:23:83:23 | CS0621: 'C5.M': virtual or abstract members cannot be private |
|
||||
| errors.cs:86:11:86:12 | CS0101: The namespace 'ErrorRecovery' already contains a definition for 'C5' |
|
||||
| errors.cs:89:13:89:13 | CS0414: The field 'C5.F' is assigned but its value is never used |
|
||||
| errors.cs:90:22:90:22 | CS0547: 'C5.M': property or indexer cannot have void type |
|
||||
| errors.cs:90:22:90:22 | CS0548: 'C5.M': property or indexer must have at least one accessor |
|
||||
| errors.cs:90:22:90:22 | CS0621: 'C5.M': virtual or abstract members cannot be private |
|
||||
| errors.cs:91:45:91:45 | CS0103: The name 'x' does not exist in the current context |
|
||||
| errors.cs:92:45:92:45 | CS0103: The name 'y' does not exist in the current context |
|
||||
| file://:0:0:0:0 | CS5001: Program does not contain a static 'Main' method suitable for an entry point |
|
||||
extractorMessages
|
||||
| errors.cs:6:1:6:22 | Namespace not found |
|
||||
| errors.cs:22:31:22:32 | Failed to determine type |
|
||||
|
||||
@@ -37,10 +37,7 @@ The CodeQL extension for Visual Studio Code adds rich language support for CodeQ
|
||||
CodeQL queries using the Visual Studio Code extension.
|
||||
|
||||
- :doc:`Working with CodeQL packs in Visual Studio Code
|
||||
<working-with-codeql-packs-in-visual-studio-code>`: You can view, create, and edit all types of CodeQL pack in Visual Studio Code.
|
||||
|
||||
- :doc:`Using the CodeQL model editor
|
||||
<using-the-codeql-model-editor>`: You can view, create, and edit CodeQL model packs using a dedicated editor.
|
||||
<working-with-codeql-packs-in-visual-studio-code>`: You can view and edit CodeQL packs in Visual Studio Code.
|
||||
|
||||
- :doc:`Customizing settings
|
||||
<customizing-settings>`: You can edit the settings for the
|
||||
@@ -70,7 +67,6 @@ The CodeQL extension for Visual Studio Code adds rich language support for CodeQ
|
||||
running-codeql-queries-at-scale-with-mrva
|
||||
testing-codeql-queries-in-visual-studio-code
|
||||
working-with-codeql-packs-in-visual-studio-code
|
||||
using-the-codeql-model-editor
|
||||
customizing-settings
|
||||
troubleshooting-codeql-for-visual-studio-code
|
||||
troubleshooting-variant-analysis
|
||||
|
||||
@@ -74,8 +74,6 @@ To use the starter workspace:
|
||||
|
||||
#. In VS Code, use the **File** > **Open Workspace** option to open the ``vscode-codeql-starter.code-workspace`` file from your checkout of the workspace repository.
|
||||
|
||||
Remember to update the ``ql`` submodule in the starter workspace periodically to ensure that it remains compatible with newer versions of the VS Code extension and the CodeQL CLI.
|
||||
|
||||
.. _existing-workspace:
|
||||
|
||||
Updating an existing workspace for CodeQL
|
||||
|
||||
@@ -1,139 +0,0 @@
|
||||
:tocdepth: 1
|
||||
|
||||
.. _using-the-codeql-model-editor:
|
||||
|
||||
Using the CodeQL model editor
|
||||
=============================
|
||||
|
||||
.. include:: ../reusables/beta-note-model-pack-editor-vsc.rst
|
||||
|
||||
You can view, write, and edit CodeQL packs in Visual Studio Code using the CodeQL extension. The model editor is designed to help you model external dependencies of your codebase that are not supported by the standard CodeQL Libraries.
|
||||
|
||||
About the CodeQL model editor
|
||||
-----------------------------
|
||||
|
||||
The CodeQL model editor guides you through modeling the calls to external dependencies in your application or fully modeling all the public entry and exit points in an external dependency.
|
||||
|
||||
When you open the model editor, it analyzes the currently selected CodeQL database and identifies where the application uses external APIs and all public methods. An external (or third party) API is any API that is not part of the CodeQL database you have selected.
|
||||
|
||||
The model editor has two different modes:
|
||||
|
||||
- Application mode (default view): The editor lists each external framework used by the selected CodeQL database. When you expand a framework, a list of all calls to and from the external API is shown with the options available to model dataflow through each call. This mode is most useful for improving the CodeQL results for the specific codebase.
|
||||
|
||||
- Dependency mode: The editor identifies all of the publicly accessible APIs in the selected CodeQL database. This view guides you through modeling each public API that the codebase makes available. When you have finished modeling the entire API, you can save the model and use it to improve the CodeQL analysis for all codebases that use the dependency.
|
||||
|
||||
Displaying the CodeQL model editor
|
||||
----------------------------------
|
||||
|
||||
#. Open your CodeQL workspace in VS Code, for example, the ``vscode-codeql-starter`` workspace.
|
||||
If you haven't updated the ``ql`` submodule for a while, update it from ``main`` to ensure that you have the queries used to gather data for the model editor.
|
||||
#. Open the CodeQL extension and select the CodeQL database that you want to model from the "Databases" section of the left side pane.
|
||||
#. Use the command palette to run the “CodeQL: Open Model Editor (Beta)” command.
|
||||
#. The CodeQL model editor will open in a new tab and run a series of telemetry queries to identify APIs in the code.
|
||||
#. When the queries are complete, the APIs that have been identified are shown in the editor.
|
||||
|
||||
Modeling the calls your codebase makes to external APIs
|
||||
-------------------------------------------------------
|
||||
|
||||
You typically use this approach when you are looking at a specific codebase where you want to improve the precision of CodeQL results. This is usually when the codebase uses frameworks or libraries that are not supported by CodeQL and if the source code of the framework or library is not included in the analysis.
|
||||
|
||||
#. Select the CodeQL database that you want to improve CodeQL coverage for.
|
||||
#. Display the CodeQL model editor. By default the editor runs in application mode, so the list of external APIs used by the selected codebase is shown.
|
||||
|
||||
.. image:: ../images/codeql-for-visual-studio-code/model-application-mode.png
|
||||
:width: 800
|
||||
:alt: Screenshot of the "Application mode" view of the CodeQL model pack editor in Visual Studio Code showing three of the external frameworks used by the "sofa-jraft" codebase.
|
||||
|
||||
#. Click to expand an external API and view the list of calls from the codebase to the external dependency.
|
||||
#. Click **View** associated with an API call or method to show where it is used in your codebase.
|
||||
|
||||
.. image:: ../images/codeql-for-visual-studio-code/model-application-mode-expanded.png
|
||||
:width: 800
|
||||
:alt: Screenshot of the "Application mode" view of the CodeQL model pack editor in Visual Studio Code showing the calls to the "rocksdbjni" framework ready for modeling. The "View" option for the first call is highlighted with a dark orange outline.
|
||||
|
||||
#. When you have determined how to model the call or method, define the **Model type**.
|
||||
#. The remaining fields are updated with available options:
|
||||
|
||||
- **Source**: choose the **Output** element to model.
|
||||
- **Sink**: choose the **Input** element to model.
|
||||
- **Flow summary**: choose the **Input** and **Output** elements to model.
|
||||
|
||||
#. Define the **Kind** of dataflow for the model.
|
||||
#. When you have finished modeling, click **Save all** or **Save** (shown at the bottom right of each expanded list of calls). The percentage of calls modeled in the editor is updated.
|
||||
|
||||
The models are stored in your workspace at ``.github/codeql/extensions/<codeql-model-pack>``, where ``<codeql-model-pack>`` is the name of the CodeQL database that you selected. That is, the name of the repository, hyphen, the language analyzed by CodeQL.
|
||||
|
||||
The models are stored in a series of YAML data extension files, one for each external API. For example:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
.github/codeql/extensions/sofa-jraft-java # the model pack directory
|
||||
models
|
||||
jmh-core.model.yml # models calls to jmh-core@1.20
|
||||
rocksdbjni.model.yml # models calls to rocksdbjni@7.7.3
|
||||
|
||||
Modeling the public API of a codebase
|
||||
-------------------------------------
|
||||
|
||||
You typically use this method when you want to model a framework or library that your organization uses in more than one codebase. Once you have finished creating and testing the model, you can publish the CodeQL model pack to the GitHub Container Registry for your whole organization to use.
|
||||
|
||||
#. Select the CodeQL database that you want to model.
|
||||
#. Display the CodeQL model editor. By default the editor runs in application mode. Click **Model as dependency** to display dependency mode. The screen changes to show the public API of the framework or library.
|
||||
|
||||
.. image:: ../images/codeql-for-visual-studio-code/model-dependency-mode.png
|
||||
:width: 800
|
||||
:alt: Screenshot of the "Dependency mode" view of the CodeQL model pack editor in Visual Studio Code showing three of the packages published by the "sofa-jraft" codebase.
|
||||
|
||||
#. Click to expand a package and view the list of available methods.
|
||||
#. Click **View** associated with a method to show its definition.
|
||||
|
||||
.. image:: ../images/codeql-for-visual-studio-code/model-dependency-mode-expanded.png
|
||||
:width: 800
|
||||
:alt: Screenshot of the "Dependency mode" view of the CodeQL model pack editor in Visual Studio Code showing the public methods available in the "com.alipay.soft.jraft.option" package ready for modeling. The "View" option for the first method is highlighted with a dark orange outline.
|
||||
|
||||
#. When you have determined how to model the method, define the **Model type**.
|
||||
#. The remaining fields are updated with available options:
|
||||
|
||||
- **Source**: choose the **Output** element to model.
|
||||
- **Sink**: choose the **Input** element to model.
|
||||
- **Flow summary**: choose the **Input** and **Output** elements to model.
|
||||
|
||||
#. Define the **Kind** of dataflow for the model.
|
||||
#. When you have finished modeling, click **Save all** or **Save** (shown at the bottom right of each expanded list of calls). The percentage of calls modeled in the editor is updated.
|
||||
|
||||
The models are stored in your workspace at ``.github/codeql/extensions/<codeql-model-pack>``, where ``<codeql-model-pack>`` is the name of the CodeQL database that you selected. That is, the name of the repository, hyphen, the language analyzed by CodeQL.
|
||||
|
||||
The models are stored in a series of YAML data extension files, one for each public method. For example:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
.github/codeql/extensions/sofa-jraft-java # the model pack directory
|
||||
models
|
||||
com.alipay.sofa.jraft.option.model.yml # models public methods in package
|
||||
com.alipay.sofa.jraft.rhea.options.model.yml # models public methods in package
|
||||
|
||||
The editor will create a separate model file for each package that you model.
|
||||
|
||||
Testing CodeQL model packs
|
||||
--------------------------
|
||||
|
||||
You can test any CodeQL model packs you create in VS Code by toggling the "use model packs" setting on and off. This method works for both databases and for variant analysis repositories.
|
||||
|
||||
- To run queries on a CodeQL database with any model packs that are stored within the ``.github/codeql/extensions`` directory of the workspace, update your ``settings.json`` file with: ``"codeQL.runningQueries.useModelPacks": all,``
|
||||
- To run queries on a CodeQL database without using model packs, update your ``settings.json`` file with: ``"codeQL.runningQueries.useModelPacks": none,``
|
||||
|
||||
If your model is working well, you should see a difference in the results of the two different runs. If you don't see any differences in results, you may need to introduce a known bug to verify that the model behaves as expected.
|
||||
|
||||
Using CodeQL model packs with code scanning
|
||||
-------------------------------------------
|
||||
|
||||
There are two methods for using CodeQL model packs with code scanning:
|
||||
|
||||
#. Copy the model pack directory into the ``.github/codeql/extensions`` directory of the repository. It will automatically be used by all future code scanning analysis for the repository (default setup or advanced setup).
|
||||
#. Publish the model pack to the GitHub Container Registry as a CodeQL model pack. This can be downloaded and used by advanced setup for code scanning or by the CodeQL CLI running in an external CI system.
|
||||
|
||||
For more information, see the following articles on the GitHub Docs site:
|
||||
|
||||
- Default setup of code scanning: `Extending CodeQL coverage with CodeQL model packs in default setup <https://docs.github.com/en/code-security/code-scanning/managing-your-code-scanning-configuration/editing-your-configuration-of-default-setup#extending-codeql-coverage-with-codeql-model-packs-in-default-setup>`__
|
||||
- Advanced setup of code scanning: `Extending CodeQL coverage with CodeQL model packs <https://docs.github.com//en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning#extending-codeql-coverage-with-codeql-model-packs>`__
|
||||
- CodeQL CLI setup in external CI system: `Using model packs to analyze calls to custom dependencies <https://docs.github.com/en/code-security/code-scanning/using-codeql-code-scanning-with-your-existing-ci-system/configuring-codeql-cli-in-your-ci-system#using-model-packs-to-analyze-calls-to-custom-dependencies>`__
|
||||
@@ -7,49 +7,33 @@ Working with CodeQL packs in Visual Studio Code
|
||||
|
||||
.. include:: ../reusables/beta-note-package-management.rst
|
||||
|
||||
You can view, write, and edit all types of CodeQL packs in Visual Studio Code using the CodeQL extension.
|
||||
You can view CodeQL packs and write and edit queries for them in Visual Studio Code.
|
||||
|
||||
About CodeQL packs
|
||||
------------------
|
||||
You use CodeQL packs to share your expertise in query writing, CodeQL library development, and modeling dependencies with other users. The CodeQL package management system ensures that when you publish a CodeQL pack it is ready to use, without any compilation. Anything the CodeQL pack depends on is explicitly defined within the pack. You can publish your own CodeQL packs and download packs created by others. For more information, see "`About CodeQL packs <https://docs.github.com/en/code-security/codeql-cli/codeql-cli-reference/about-codeql-packs>`__."
|
||||
CodeQL packs are used to create, share, depend on, and run CodeQL queries and libraries. You can publish your own CodeQL packs and download packs created by others. For more information, see "`About CodeQL packs <https://docs.github.com/en/code-security/codeql-cli/codeql-cli-reference/about-codeql-packs>`__."
|
||||
|
||||
There are three types of CodeQL packs, each with a specific purpose.
|
||||
|
||||
- Query packs are designed to be run. When a query pack is published, the bundle includes all the transitive dependencies and pre-compiled representations of each query, in addition to the query sources. This ensures consistent and efficient execution of the queries in the pack.
|
||||
- Model packs are used to model dependencies that are not supported by the standard CodeQL libraries. When you add a model pack to your analysis, all relevant queries also recognize the sources, sinks and flow steps of the dependencies defined in the pack.
|
||||
- Library packs are designed to be used by query packs (or other library packs) and do not contain queries themselves. The libraries are not compiled separately.
|
||||
|
||||
Using the CodeQL packs shipped with the CLI in Visual Studio Code
|
||||
-----------------------------------------------------------------
|
||||
Using standard CodeQL packs in Visual Studio Code
|
||||
--------------------------------------------------------------
|
||||
To install dependencies for a CodeQL pack in your Visual Studio Code workspace, run the **CodeQL: Install Pack Dependencies** command from the Command Palette and select the packs you want to install dependencies for.
|
||||
|
||||
You can write and run query packs that depend on the CodeQL standard libraries, without needing to check out the standard libraries in your workspace. Instead, you can install only the dependencies required by the query packs you want to use.
|
||||
|
||||
Working with CodeQL query packs
|
||||
-------------------------------
|
||||
|
||||
One of the main benefits of working with a CodeQL query pack is that all dependencies are resolved, not just those defined within the query and standard libraries.
|
||||
|
||||
Creating and editing CodeQL query packs
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
To create a new query pack, you will need to use the CodeQL CLI from a terminal, which you can do within Visual Studio Code or outside of it with the ``codeql pack init`` command. Once you create an empty pack, you can edit the ``qlpack.yml`` file or run the ``codeql pack add`` command to add dependencies or change the name or version. For detailed information, see "`Creating and working with CodeQL packs <https://docs.github.com/en/code-security/codeql-cli/using-the-codeql-cli/creating-and-working-with-codeql-packs>`__."
|
||||
Creating and editing CodeQL packs in Visual Studio Code
|
||||
-------------------------------------------------------
|
||||
To create a new CodeQL pack, you will need to use the CodeQL CLI from a terminal, which you can do within Visual Studio Code or outside of it with the ``codeql pack init`` command. Once you create an empty pack, you can edit the ``qlpack.yml`` file or run the ``codeql pack add`` command to add dependencies or change the name or version. For more information, see "`Creating and working with CodeQL packs <https://docs.github.com/en/code-security/codeql-cli/using-the-codeql-cli/creating-and-working-with-codeql-packs>`__."
|
||||
|
||||
You can create or edit queries in a CodeQL pack in Visual Studio Code as you would with any CodeQL query, using the standard code editing features such as autocomplete suggestions to find elements to use from the pack's dependencies.
|
||||
|
||||
You can then use the CodeQL CLI to publish your pack to share with others. For detailed information, see "`Publishing and using CodeQL packs <https://docs.github.com/en/code-security/codeql-cli/using-the-codeql-cli/publishing-and-using-codeql-packs>`__."
|
||||
You can then use the CodeQL CLI to publish your pack to share with others. For more information, see "`Publishing and using CodeQL packs <https://docs.github.com/en/code-security/codeql-cli/using-the-codeql-cli/publishing-and-using-codeql-packs>`__."
|
||||
|
||||
Viewing CodeQL query packs and their dependencies
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
To download a query pack that someone else has created, run the **CodeQL: Download Packs** command from the Command Palette.
|
||||
You can download all the core query packs, or enter the full name of a specific pack to download. For example, to download the core queries for analyzing Java and Kotlin, enter ``codeql/java-queries``.
|
||||
Viewing CodeQL packs and their dependencies in Visual Studio Code
|
||||
-----------------------------------------------------------------
|
||||
To download a CodeQL pack that someone else has created, run the **CodeQL: Download Packs** command from the Command Palette.
|
||||
You can download all the core CodeQL query packs, or enter the full name of a specific pack to download. For example, to download the core queries for analyzing Java or Kotlin, enter ``codeql/java-queries``.
|
||||
|
||||
Whether you have downloaded a CodeQL pack or created your own, you can open the ``qlpack.yml`` file in the root of a CodeQL pack directory in Visual Studio Code and view the dependencies section to see what libraries the pack depends on.
|
||||
|
||||
If you want to understand a query in a CodeQL pack better, you can open the query file and view the code, using the IntelliSense code editing features of Visual Studio Code. For example, if you hover over an element from a library depended on by the pack, Visual Studio Code will resolve it so you can see documentation about the element.
|
||||
|
||||
To view the full definition of an element of a query, you can right-click and choose **Go to Definition**. If the library pack is present within the same Visual Studio Code workspace, this will take you to the definition within the workspace. Otherwise it will take you to the definition within your package cache, the shared location where downloaded dependencies are stored, which is in your home directory by default.
|
||||
|
||||
Working with CodeQL model packs
|
||||
-------------------------------
|
||||
|
||||
The CodeQL extension for Visual Studio Code includes a dedicated editor for creating and editing model packs. For information on using the model editor, see ":ref:`Using the CodeQL model editor <using-the-codeql-model-editor>`."
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
.. _abstract-syntax-tree-classes-for-working-with-java-programs:
|
||||
|
||||
Abstract syntax tree classes for working with Java and Kotlin programs
|
||||
======================================================================
|
||||
Abstract syntax tree classes for working with Java programs
|
||||
===========================================================
|
||||
|
||||
CodeQL has a large selection of classes for representing the abstract syntax tree of Java and Kotlin programs.
|
||||
CodeQL has a large selection of classes for representing the abstract syntax tree of Java programs.
|
||||
|
||||
.. include:: ../reusables/abstract-syntax-tree.rst
|
||||
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
.. _analyzing-data-flow-in-java:
|
||||
|
||||
Analyzing data flow in Java and Kotlin
|
||||
======================================
|
||||
Analyzing data flow in Java
|
||||
===========================
|
||||
|
||||
You can use CodeQL to track the flow of data through a Java/Kotlin program to its use.
|
||||
You can use CodeQL to track the flow of data through a Java program to its use.
|
||||
|
||||
.. include:: ../reusables/kotlin-beta-note.rst
|
||||
|
||||
@@ -12,7 +12,7 @@ You can use CodeQL to track the flow of data through a Java/Kotlin program to it
|
||||
About this article
|
||||
------------------
|
||||
|
||||
This article describes how data flow analysis is implemented in the CodeQL libraries for Java/Kotlin and includes examples to help you write your own data flow queries.
|
||||
This article describes how data flow analysis is implemented in the CodeQL libraries for Java and includes examples to help you write your own data flow queries.
|
||||
The following sections describe how to use the libraries for local data flow, global data flow, and taint tracking.
|
||||
|
||||
For a more general introduction to modeling data flow, see ":ref:`About data flow analysis <about-data-flow-analysis>`."
|
||||
|
||||
@@ -1,11 +1,9 @@
|
||||
.. _annotations-in-java:
|
||||
|
||||
Annotations in Java and Kotlin
|
||||
==============================
|
||||
Annotations in Java
|
||||
===================
|
||||
|
||||
CodeQL databases of Java/Kotlin projects contain information about all annotations attached to program elements.
|
||||
|
||||
.. include:: ../reusables/kotlin-beta-note.rst
|
||||
CodeQL databases of Java projects contain information about all annotations attached to program elements.
|
||||
|
||||
About working with annotations
|
||||
------------------------------
|
||||
@@ -17,7 +15,7 @@ Annotations are represented by these CodeQL classes:
|
||||
- The class ``AnnotationElement`` represents an annotation element, that is, a member of an annotation type.
|
||||
- The class ``Annotation`` represents an annotation such as ``@Override``; annotation values can be accessed through member predicate ``getValue``.
|
||||
|
||||
For example, the Java/Kotlin standard library defines an annotation ``SuppressWarnings`` that instructs the compiler not to emit certain kinds of warnings:
|
||||
For example, the Java standard library defines an annotation ``SuppressWarnings`` that instructs the compiler not to emit certain kinds of warnings:
|
||||
|
||||
.. code-block:: java
|
||||
|
||||
@@ -103,7 +101,7 @@ As a first step, let's write a query that finds all ``@Override`` annotations. A
|
||||
where ann.getType().hasQualifiedName("java.lang", "Override")
|
||||
select ann
|
||||
|
||||
As always, it is a good idea to try this query on a CodeQL database for a Java/Kotlin project to make sure it actually produces some results. On the earlier example, it should find the annotation on ``Sub1.m``. Next, we encapsulate the concept of an ``@Override`` annotation as a CodeQL class:
|
||||
As always, it is a good idea to try this query on a CodeQL database for a Java project to make sure it actually produces some results. On the earlier example, it should find the annotation on ``Sub1.m``. Next, we encapsulate the concept of an ``@Override`` annotation as a CodeQL class:
|
||||
|
||||
::
|
||||
|
||||
@@ -187,7 +185,7 @@ For more information about the class ``Call``, see ":doc:`Navigating the call gr
|
||||
Improvements
|
||||
~~~~~~~~~~~~
|
||||
|
||||
The Java/Kotlin standard library provides another annotation type ``java.lang.SupressWarnings`` that can be used to suppress certain categories of warnings. In particular, it can be used to turn off warnings about calls to deprecated methods. Therefore, it makes sense to improve our query to ignore calls to deprecated methods from inside methods that are marked with ``@SuppressWarnings("deprecation")``.
|
||||
The Java standard library provides another annotation type ``java.lang.SupressWarnings`` that can be used to suppress certain categories of warnings. In particular, it can be used to turn off warnings about calls to deprecated methods. Therefore, it makes sense to improve our query to ignore calls to deprecated methods from inside methods that are marked with ``@SuppressWarnings("deprecation")``.
|
||||
|
||||
For instance, consider this slightly updated example:
|
||||
|
||||
|
||||
@@ -133,7 +133,7 @@ Further reading
|
||||
|
||||
.. Article-specific substitutions for the reusables used in docs/codeql/reusables/vs-code-basic-instructions
|
||||
|
||||
.. |language-text| replace:: Java/Kotlin
|
||||
.. |language-text| replace:: Java
|
||||
|
||||
.. |language-code| replace:: ``java``
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
.. _basic-query-for-javascript-code:
|
||||
|
||||
Basic query for JavaScript and TypeScript code
|
||||
===============================================
|
||||
Basic query for JavaScript code
|
||||
===============================
|
||||
|
||||
Learn to write and run a simple CodeQL query using Visual Studio Code with the CodeQL extension.
|
||||
|
||||
@@ -10,7 +10,7 @@ Learn to write and run a simple CodeQL query using Visual Studio Code with the C
|
||||
About the query
|
||||
---------------
|
||||
|
||||
In JavaScript and TypeScript, any expression can be turned into an expression statement. While this is sometimes convenient, it can be dangerous. For example, imagine a programmer wants to assign a new value to a variable ``x`` by means of an assignment ``x = 42``. However, they accidentally type two equals signs, producing the comparison statement ``x == 42``. This is valid JavaScript, so no error is generated. The statement simply compares ``x`` to ``42``, and then discards the result of the comparison.
|
||||
In JavaScript, any expression can be turned into an expression statement. While this is sometimes convenient, it can be dangerous. For example, imagine a programmer wants to assign a new value to a variable ``x`` by means of an assignment ``x = 42``. However, they accidentally type two equals signs, producing the comparison statement ``x == 42``. This is valid JavaScript, so no error is generated. The statement simply compares ``x`` to ``42``, and then discards the result of the comparison.
|
||||
|
||||
The query you will run finds instances of this problem. The query searches for expressions ``e`` that are pure—that is, their evaluation does not lead to any side effects—but appear as an expression statement.
|
||||
|
||||
@@ -50,7 +50,7 @@ After the initial ``import`` statement, this simple query comprises three parts
|
||||
+---------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------+
|
||||
| Query part | Purpose | Details |
|
||||
+===============================================================+===================================================================================================================+========================================================================================================================+
|
||||
| ``import javascript`` | Imports the standard CodeQL libraries for JavaScript and TypeScript. | Every query begins with one or more ``import`` statements. |
|
||||
| ``import javascript`` | Imports the standard CodeQL libraries for JavaScript. | Every query begins with one or more ``import`` statements. |
|
||||
+---------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------+
|
||||
| ``from Expr e`` | Defines the variables for the query. | ``e`` is declared as a variable that ranges over expressions. |
|
||||
| | Declarations are of the form: | |
|
||||
|
||||
@@ -10,7 +10,7 @@ Experiment and learn how to write effective and efficient queries for CodeQL dat
|
||||
|
||||
.. pull-quote:: Enabling Kotlin support
|
||||
|
||||
CodeQL treats Java and Kotlin as parts of the same language, so to enable Kotlin support you should enable ``java-kotlin`` as a language.
|
||||
CodeQL treats Java and Kotlin as parts of the same language, so to enable Kotlin support you should enable ``java`` as a language.
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
@@ -25,26 +25,23 @@ Experiment and learn how to write effective and efficient queries for CodeQL dat
|
||||
javadoc
|
||||
working-with-source-locations
|
||||
abstract-syntax-tree-classes-for-working-with-java-programs
|
||||
customizing-library-models-for-java-and-kotlin
|
||||
|
||||
- :doc:`Basic query for Java and Kotlin code <basic-query-for-java-code>`: Learn to write and run a simple CodeQL query.
|
||||
- :doc:`Basic query for Java code <basic-query-for-java-code>`: Learn to write and run a simple CodeQL query.
|
||||
|
||||
- :doc:`CodeQL library for Java and Kotlin <codeql-library-for-java>`: When analyzing Java/Kotlin code, you can use the large collection of classes in the CodeQL library for Java/Kotlin.
|
||||
- :doc:`CodeQL library for Java <codeql-library-for-java>`: When analyzing Java code, you can use the large collection of classes in the CodeQL library for Java.
|
||||
|
||||
- :doc:`Analyzing data flow in Java and Kotlin <analyzing-data-flow-in-java>`: You can use CodeQL to track the flow of data through a Java/Kotlin program to its use.
|
||||
- :doc:`Analyzing data flow in Java <analyzing-data-flow-in-java>`: You can use CodeQL to track the flow of data through a Java program to its use.
|
||||
|
||||
- :doc:`Java and Kotlin types <types-in-java>`: You can use CodeQL to find out information about data types used in Java/Kotlin code. This allows you to write queries to identify specific type-related issues.
|
||||
- :doc:`Java types <types-in-java>`: You can use CodeQL to find out information about data types used in Java code. This allows you to write queries to identify specific type-related issues.
|
||||
|
||||
- :doc:`Overflow-prone comparisons in Java and Kotlin <overflow-prone-comparisons-in-java>`: You can use CodeQL to check for comparisons in Java/Kotlin code where one side of the comparison is prone to overflow.
|
||||
- :doc:`Overflow-prone comparisons in Java <overflow-prone-comparisons-in-java>`: You can use CodeQL to check for comparisons in Java code where one side of the comparison is prone to overflow.
|
||||
|
||||
- :doc:`Navigating the call graph <navigating-the-call-graph>`: CodeQL has classes for identifying code that calls other code, and code that can be called from elsewhere. This allows you to find, for example, methods that are never used.
|
||||
|
||||
- :doc:`Annotations in Java and Kotlin <annotations-in-java>`: CodeQL databases of Java/Kotlin projects contain information about all annotations attached to program elements.
|
||||
- :doc:`Annotations in Java <annotations-in-java>`: CodeQL databases of Java projects contain information about all annotations attached to program elements.
|
||||
|
||||
- :doc:`Javadoc <javadoc>`: You can use CodeQL to find errors in Javadoc comments in Java code.
|
||||
|
||||
- :doc:`Working with source locations <working-with-source-locations>`: You can use the location of entities within Java/Kotlin code to look for potential errors. Locations allow you to deduce the presence, or absence, of white space which, in some cases, may indicate a problem.
|
||||
- :doc:`Working with source locations <working-with-source-locations>`: You can use the location of entities within Java code to look for potential errors. Locations allow you to deduce the presence, or absence, of white space which, in some cases, may indicate a problem.
|
||||
|
||||
- :doc:`Abstract syntax tree classes for working with Java and Kotlin programs <abstract-syntax-tree-classes-for-working-with-java-programs>`: CodeQL has a large selection of classes for representing the abstract syntax tree of Java/Kotlin programs.
|
||||
|
||||
- :doc:`Customizing library models for Java and Kotlin <customizing-library-models-for-java-and-kotlin>`: You can model frameworks and libraries that your code base depends on using data extensions and publish them as CodeQL model packs.
|
||||
- :doc:`Abstract syntax tree classes for working with Java programs <abstract-syntax-tree-classes-for-working-with-java-programs>`: CodeQL has a large selection of classes for representing the abstract syntax tree of Java programs.
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
.. _codeql-for-javascript:
|
||||
|
||||
CodeQL for JavaScript and TypeScript
|
||||
====================================
|
||||
CodeQL for JavaScript
|
||||
=====================
|
||||
|
||||
Experiment and learn how to write effective and efficient queries for CodeQL databases generated from JavaScript and TypeScript codebases.
|
||||
Experiment and learn how to write effective and efficient queries for CodeQL databases generated from JavaScript codebases.
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
@@ -18,7 +18,7 @@ Experiment and learn how to write effective and efficient queries for CodeQL dat
|
||||
abstract-syntax-tree-classes-for-working-with-javascript-and-typescript-programs
|
||||
data-flow-cheat-sheet-for-javascript
|
||||
|
||||
- :doc:`Basic query for JavaScript and TypeScript code <basic-query-for-javascript-code>`: Learn to write and run a simple CodeQL query.
|
||||
- :doc:`Basic query for JavaScript code <basic-query-for-javascript-code>`: Learn to write and run a simple CodeQL query.
|
||||
|
||||
- :doc:`CodeQL library for JavaScript <codeql-library-for-javascript>`: When you're analyzing a JavaScript program, you can make use of the large collection of classes in the CodeQL library for JavaScript.
|
||||
|
||||
|
||||
@@ -1,16 +1,14 @@
|
||||
.. _codeql-library-for-java:
|
||||
|
||||
CodeQL library for Java and Kotlin
|
||||
==================================
|
||||
CodeQL library for Java
|
||||
=======================
|
||||
|
||||
When you're analyzing a Java/Kotlin program, you can make use of the large collection of classes in the CodeQL library for Java/Kotlin.
|
||||
When you're analyzing a Java program, you can make use of the large collection of classes in the CodeQL library for Java.
|
||||
|
||||
.. include:: ../reusables/kotlin-beta-note.rst
|
||||
About the CodeQL library for Java
|
||||
---------------------------------
|
||||
|
||||
About the CodeQL library for Java and Kotlin
|
||||
--------------------------------------------
|
||||
|
||||
There is an extensive library for analyzing CodeQL databases extracted from Java/Kotlin projects. The classes in this library present the data from a database in an object-oriented form and provide abstractions and predicates to help you with common analysis tasks.
|
||||
There is an extensive library for analyzing CodeQL databases extracted from Java projects. The classes in this library present the data from a database in an object-oriented form and provide abstractions and predicates to help you with common analysis tasks.
|
||||
|
||||
The library is implemented as a set of QL modules, that is, files with the extension ``.qll``. The module ``java.qll`` imports all the core Java library modules, so you can include the complete library by beginning your query with:
|
||||
|
||||
@@ -29,7 +27,7 @@ The rest of this article briefly summarizes the most important classes and predi
|
||||
Summary of the library classes
|
||||
------------------------------
|
||||
|
||||
The most important classes in the standard Java/Kotlin library can be grouped into five main categories:
|
||||
The most important classes in the standard Java library can be grouped into five main categories:
|
||||
|
||||
#. Classes for representing program elements (such as classes and methods)
|
||||
#. Classes for representing AST nodes (such as statements and expressions)
|
||||
@@ -194,7 +192,7 @@ The wildcards ``? extends Number`` and ``? super Float`` are represented by clas
|
||||
|
||||
For dealing with generic methods, there are classes ``GenericMethod``, ``ParameterizedMethod`` and ``RawMethod``, which are entirely analogous to the like-named classes for representing generic types.
|
||||
|
||||
For more information on working with types, see the :doc:`Types in Java and Kotlin <types-in-java>`.
|
||||
For more information on working with types, see the :doc:`Types in Java <types-in-java>`.
|
||||
|
||||
Variables
|
||||
~~~~~~~~~
|
||||
@@ -208,7 +206,7 @@ Class ``Variable`` represents a variable `in the Java sense <https://docs.oracle
|
||||
Abstract syntax tree
|
||||
--------------------
|
||||
|
||||
Classes in this category represent abstract syntax tree (AST) nodes, that is, statements (class ``Stmt``) and expressions (class ``Expr``). For a full list of expression and statement types available in the standard QL library, see ":doc:`Abstract syntax tree classes for working with Java and Kotlin programs <abstract-syntax-tree-classes-for-working-with-java-programs>`."
|
||||
Classes in this category represent abstract syntax tree (AST) nodes, that is, statements (class ``Stmt``) and expressions (class ``Expr``). For a full list of expression and statement types available in the standard QL library, see ":doc:`Abstract syntax tree classes for working with Java programs <abstract-syntax-tree-classes-for-working-with-java-programs>`."
|
||||
|
||||
Both ``Expr`` and ``Stmt`` provide member predicates for exploring the abstract syntax tree of a program:
|
||||
|
||||
@@ -256,12 +254,12 @@ Finally, here is a query that finds method bodies:
|
||||
|
||||
As these examples show, the parent node of an expression is not always an expression: it may also be a statement, for example, an ``IfStmt``. Similarly, the parent node of a statement is not always a statement: it may also be a method or a constructor. To capture this, the QL Java library provides two abstract class ``ExprParent`` and ``StmtParent``, the former representing any node that may be the parent node of an expression, and the latter any node that may be the parent node of a statement.
|
||||
|
||||
For more information on working with AST classes, see the :doc:`article on overflow-prone comparisons in Java and Kotlin <overflow-prone-comparisons-in-java>`.
|
||||
For more information on working with AST classes, see the :doc:`article on overflow-prone comparisons in Java <overflow-prone-comparisons-in-java>`.
|
||||
|
||||
Metadata
|
||||
--------
|
||||
|
||||
Java/Kotlin programs have several kinds of metadata, in addition to the program code proper. In particular, there are `annotations <https://docs.oracle.com/javase/tutorial/java/annotations/>`__ and `Javadoc <https://en.wikipedia.org/wiki/Javadoc>`__ comments. Since this metadata is interesting both for enhancing code analysis and as an analysis subject in its own right, the QL library defines classes for accessing it.
|
||||
Java programs have several kinds of metadata, in addition to the program code proper. In particular, there are `annotations <https://docs.oracle.com/javase/tutorial/java/annotations/>`__ and `Javadoc <https://en.wikipedia.org/wiki/Javadoc>`__ comments. Since this metadata is interesting both for enhancing code analysis and as an analysis subject in its own right, the QL library defines classes for accessing it.
|
||||
|
||||
For annotations, class ``Annotatable`` is a superclass of all program elements that can be annotated. This includes packages, reference types, fields, methods, constructors, and local variable declarations. For every such element, its predicate ``getAnAnnotation`` allows you to retrieve any annotations the element may have. For example, the following query finds all annotations on constructors:
|
||||
|
||||
@@ -346,7 +344,7 @@ Most large projects include some methods with a very high cyclomatic complexity.
|
||||
Call graph
|
||||
----------
|
||||
|
||||
CodeQL databases generated from Java and Kotlin code bases include precomputed information about the program's call graph, that is, which methods or constructors a given call may dispatch to at runtime.
|
||||
CodeQL databases generated from Java code bases include precomputed information about the program's call graph, that is, which methods or constructors a given call may dispatch to at runtime.
|
||||
|
||||
The class ``Callable``, introduced above, includes both methods and constructors. Call expressions are abstracted using class ``Call``, which includes method calls, ``new`` expressions, and explicit constructor calls using ``this`` or ``super``.
|
||||
|
||||
|
||||
@@ -1,293 +0,0 @@
|
||||
.. _customizing-library-models-for-java-and-kotlin:
|
||||
|
||||
Customizing library models for Java and Kotlin
|
||||
==============================================
|
||||
|
||||
You can model the methods and callables that control data flow in any framework or library. This is especially useful for custom frameworks or niche libraries, that are not supported by the standard CodeQL libraries.
|
||||
|
||||
.. include:: ../reusables/kotlin-beta-note.rst
|
||||
|
||||
.. include:: ../reusables/beta-note-model-packs-java.rst
|
||||
|
||||
About this article
|
||||
------------------
|
||||
|
||||
This article contains reference material about how to define custom models for sources, sinks and flow summaries for Java dependencies in data extension files.
|
||||
|
||||
The best way to create your own models is using the CodeQL model editor in the CodeQL extension for Visual Studio Code. The model editor automatically guides you through the process of defining models, displaying the properties you need to define and the options available. You can save the resulting models as data extension files in CodeQL model packs and use them without worrying about the syntax.
|
||||
|
||||
For more information, see ":ref:`Using the CodeQL model editor <using-the-codeql-model-editor>`."
|
||||
|
||||
About data extensions
|
||||
---------------------
|
||||
|
||||
You can customize analysis by defining models (summaries, sinks, and sources) of your code's dependencies in data extension files. Each model defines the behavior of one or more elements of your library or framework, such as methods and callables. When you run dataflow analysis, these models expand the potential sources and sinks tracked by dataflow analysis and improve the precision of results.
|
||||
|
||||
Most of the security queries search for paths from a source of untrusted input to a sink that represents a vulnerability. This is known as taint tracking. Each source is a starting point for dataflow analysis to track tainted data and each sink is an end point.
|
||||
|
||||
Taint tracking queries also need to know how data can flow through elements that are not included in the source code. These are modeled as summaries. A summary model enables queries to synthesize the flow behavior through elements in dependency code that is not stored in your repository.
|
||||
|
||||
Syntax used to define an element in an extension file
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Each model of an element is defined using a data extension where each tuple constitutes a model.
|
||||
A data extension file to extend the standard Java queries included with CodeQL is a YAML file with the form:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
extensions:
|
||||
- addsTo:
|
||||
pack: codeql/java-all
|
||||
extensible: <name of extensible predicate>
|
||||
data:
|
||||
- <tuple1>
|
||||
- <tuple2>
|
||||
- ...
|
||||
|
||||
Each YAML file may contain one or more top-level extensions.
|
||||
|
||||
- ``addsTo`` defines the CodeQL pack name and extensible predicate that the extension is injected into.
|
||||
- ``data`` defines one or more rows of tuples that are injected as values into the extensible predicate. The number of columns and their types must match the definition of the extensible predicate.
|
||||
|
||||
Data extensions use union semantics, which means that the tuples of all extensions for a single extensible predicate are combined, duplicates are removed, and all of the remaining tuples are queryable by referencing the extensible predicate.
|
||||
|
||||
Publish data extension files in a CodeQL model pack to share
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You can group one or more data extention files into a CodeQL model pack and publish it to the GitHub Container Registry. This makes it easy for anyone to download the model pack and use it to extend their analysis. For more information, see "`Creating a CodeQL model pack <https://docs.github.com/en/code-security/codeql-cli/using-the-advanced-functionality-of-the-codeql-cli/creating-and-working-with-codeql-packs#creating-a-codeql-model-pack/>`__ and `Publishing and using CodeQL packs <https://docs.github.com/en/code-security/codeql-cli/using-the-advanced-functionality-of-the-codeql-cli/publishing-and-using-codeql-packs/>`__ in the CodeQL CLI documentation.
|
||||
|
||||
Extensible predicates used to create custom models in Java and Kotlin
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The CodeQL library for Java and Kotlin analysis exposes the following extensible predicates:
|
||||
|
||||
- ``sourceModel(package, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model sources of potentially tainted data.
|
||||
- ``sinkModel(package, type, subtypes, name, signature, ext, input, kind, provenance)``. This is used to model sinks where tainted data maybe used in a way that makes the code vulnerable.
|
||||
- ``summaryModel(package, type, subtypes, name, signature, ext, input, output, kind, provenance)``. This is used to model flow through elements.
|
||||
- ``neutralModel(package, type, name, signature, kind, provenance)``. This is similar to a summary model but used to model the flow of values that have only a minor impact on the dataflow analysis.
|
||||
|
||||
The extensible predicates are populated using the models defined in data extension files.
|
||||
|
||||
Examples of custom model definitions
|
||||
------------------------------------
|
||||
|
||||
The examples in this section are taken from the standard CodeQL Java query pack published by GitHub. They demonstrate how to add tuples to extend extensible predicates that are used by the standard queries.
|
||||
|
||||
Example: Taint sink in the ``java.sql`` package
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This example shows how the Java query pack models the argument of the ``execute`` method as a SQL injection sink.
|
||||
This is the ``execute`` method in the ``Statement`` class, which is located in the ``java.sql`` package.
|
||||
|
||||
.. code-block:: java
|
||||
|
||||
public static void taintsink(Connection conn, String query) throws SQLException {
|
||||
Statement stmt = conn.createStatement();
|
||||
stmt.execute(query); // The argument to this method is a SQL injection sink.
|
||||
}
|
||||
|
||||
We need to add a tuple to the ``sinkModel``\(package, type, subtypes, name, signature, ext, input, kind, provenance) extensible predicate by updating a data extension file.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
extensions:
|
||||
- addsTo:
|
||||
pack: codeql/java-all
|
||||
extensible: sinkModel
|
||||
data:
|
||||
- ["java.sql", "Statement", True, "execute", "(String)", "", "Argument[0]", "sql-injection", "manual"]
|
||||
|
||||
|
||||
Since we want to add a new sink, we need to add a tuple to the ``sinkModel`` extensible predicate.
|
||||
The first five values identify the callable (in this case a method) to be modeled as a sink.
|
||||
|
||||
- The first value ``java.sql`` is the package name.
|
||||
- The second value ``Statement`` is the name of the class (type) that contains the method.
|
||||
- The third value ``True`` is a flag that indicates whether or not the sink also applies to all overrides of the method.
|
||||
- The fourth value ``execute`` is the method name.
|
||||
- The fifth value ``(String)`` is the method input type signature.
|
||||
|
||||
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-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
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
This example shows how the Java query pack models the return value from the ``getInputStream`` method as a ``remote`` source.
|
||||
This is the ``getInputStream`` method in the ``Socket`` class, which is located in the ``java.net`` package.
|
||||
|
||||
.. code-block:: java
|
||||
|
||||
public static void tainted(Socket socket) throws IOException {
|
||||
InputStream stream = socket.getInputStream(); // The return value of this method is a remote source of taint.
|
||||
...
|
||||
}
|
||||
|
||||
We need to add a tuple to the ``sourceModel``\(package, type, subtypes, name, signature, ext, output, kind, provenance) extensible predicate by updating a data extension file.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
extensions:
|
||||
- addsTo:
|
||||
pack: codeql/java-all
|
||||
extensible: sourceModel
|
||||
data:
|
||||
- ["java.net", "Socket", False, "getInputStream", "()", "", "ReturnValue", "remote", "manual"]
|
||||
|
||||
|
||||
Since we are adding a new source, we need to add a tuple to the ``sourceModel`` extensible predicate.
|
||||
The first five values identify the callable (in this case a method) to be modeled as a source.
|
||||
|
||||
- The first value ``java.net`` is the package name.
|
||||
- The second value ``Socket`` is the name of the class (type) that contains the source.
|
||||
- The third value ``False`` is a flag that indicates whether or not the source also applies to all overrides of the method.
|
||||
- The fourth value ``getInputStream`` is the method name.
|
||||
- The fifth value ``()`` is the method input type signature.
|
||||
|
||||
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 source.
|
||||
|
||||
- The seventh value ``ReturnValue`` is the access path to the return of the method, which means that it is the return value that should be considered a source of tainted input.
|
||||
- The eighth value ``remote`` is the kind of the source. The source kind is used to define the queries where the source is in scope. ``remote`` applies to many of the security related queries as it means a remote source of untrusted data. As an example the SQL injection query uses ``remote`` sources.
|
||||
- The ninth value ``manual`` is the provenance of the source, which is used to identify the origin of the source.
|
||||
|
||||
Example: Add flow through the ``concat`` method
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
This example shows how the Java query pack models flow through a method for a simple case.
|
||||
This pattern covers many of the cases where we need to summarize flow through a method that is stored in a library or framework outside the repository.
|
||||
|
||||
.. code-block:: java
|
||||
|
||||
public static void taintflow(String s1, String s2) {
|
||||
String t = s1.concat(s2); // There is taint flow from s1 and s2 to t.
|
||||
...
|
||||
}
|
||||
|
||||
We need to add tuples to the ``summaryModel``\(package, type, subtypes, name, signature, ext, input, output, kind, provenance) extensible predicate by updating a data extension file:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
extensions:
|
||||
- addsTo:
|
||||
pack: codeql/java-all
|
||||
extensible: summaryModel
|
||||
data:
|
||||
- ["java.lang", "String", False, "concat", "(String)", "", "Argument[this]", "ReturnValue", "taint", "manual"]
|
||||
- ["java.lang", "String", False, "concat", "(String)", "", "Argument[0]", "ReturnValue", "taint", "manual"]
|
||||
|
||||
Since we are adding flow through a method, we need to add tuples to the ``summaryModel`` extensible predicate.
|
||||
Each tuple defines flow from one argument to the return value.
|
||||
The first row defines flow from the qualifier (``s1`` in the example) to the return value (``t`` in the example) and the second row defines flow from the first argument (``s2`` in the example) to the return value (``t`` in the example).
|
||||
|
||||
The first five values identify the callable (in this case a method) to be modeled as a summary.
|
||||
These are the same for both of the rows above as we are adding two summaries for the same method.
|
||||
|
||||
- The first value ``java.lang`` is the package name.
|
||||
- The second value ``String`` is the class (type) name.
|
||||
- The third value ``False`` is a flag that indicates whether or not the summary also applies to all overrides of the method.
|
||||
- The fourth value ``concat`` is the method name.
|
||||
- The fifth value ``(String)`` is the method input type signature.
|
||||
|
||||
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 summary.
|
||||
|
||||
- The seventh value is the access path to the input (where data flows from). ``Argument[this]`` is the access path to the qualifier (``s1`` in the example) and ``Argument[0]`` is the access path to the first argument (``s2`` in the example).
|
||||
- The eighth value ``ReturnValue`` is the access path to the output (where data flows to), in this case ``ReturnValue``, which means that the input flows to the return value.
|
||||
- The ninth value ``taint`` is the kind of the flow. ``taint`` means that taint is propagated through the call.
|
||||
- The tenth value ``manual`` is the provenance of the summary, which is used to identify the origin of the summary.
|
||||
|
||||
Example: Add flow through the ``map`` method
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
This example shows how the Java query pack models a more complex flow through a method.
|
||||
Here we model flow through higher order methods and collection types.
|
||||
|
||||
.. code-block:: java
|
||||
|
||||
public static void taintflow(Stream<String> s) {
|
||||
Stream<String> l = s.map(e -> e.concat("\n"));
|
||||
...
|
||||
}
|
||||
|
||||
We need to add tuples to the ``summaryModel``\(package, type, subtypes, name, signature, ext, input, output, kind, provenance) extensible predicate by updating a data extension file:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
extensions:
|
||||
- addsTo:
|
||||
pack: codeql/java-all
|
||||
extensible: summaryModel
|
||||
data:
|
||||
- ["java.util.stream", "Stream", True, "map", "(Function)", "", "Argument[this].Element", "Argument[0].Parameter[0]", "value", "manual"]
|
||||
- ["java.util.stream", "Stream", True, "map", "(Function)", "", "Argument[0].ReturnValue", "ReturnValue.Element", "value", "manual"]
|
||||
|
||||
|
||||
Since we are adding flow through a method, we need to add tuples to the ``summaryModel`` extensible predicate.
|
||||
Each tuple defines part of the flow that comprises the total flow through the ``map`` method.
|
||||
The first five values identify the callable (in this case a method) to be modeled as a summary.
|
||||
These are the same for both of the rows above as we are adding two summaries for the same method.
|
||||
|
||||
- The first value ``java.util.stream`` is the package name.
|
||||
- The second value ``Stream`` is the class (type) name.
|
||||
- The third value ``True`` is a flag that indicates whether or not the summary also applies to all overrides of the method.
|
||||
- The fourth value ``map`` is the method name.
|
||||
- The fifth value ``Function`` is the method input type signature.
|
||||
|
||||
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 summary definition.
|
||||
|
||||
- The seventh value is the access path to the ``input`` (where data flows from).
|
||||
- The eighth value is the access path to the ``output`` (where data flows to).
|
||||
|
||||
For the first row:
|
||||
|
||||
- The seventh value is ``Argument[this].Element``, which is the access path to the elements of the qualifier (the elements of the stream ``s`` in the example).
|
||||
- The eight value is ``Argument[0].Parameter[0]``, which is the access path to the first parameter of the ``Function`` argument of ``map`` (the lambda parameter ``e`` in the example).
|
||||
|
||||
For the second row:
|
||||
|
||||
- The seventh value is ``Argument[0].ReturnValue``, which is the access path to the return value of the ``Function`` argument of ``map`` (the return value of the lambda in the example).
|
||||
- The eighth value is ``ReturnValue.Element``, which is the access path to the elements of the return value of ``map`` (the elements of the stream ``l`` in the example).
|
||||
|
||||
For the remaining values for both rows:
|
||||
|
||||
- The ninth value ``value`` is the kind of the flow. ``value`` means that the value is preserved.
|
||||
- The tenth value ``manual`` is the provenance of the summary, which is used to identify the origin of the summary.
|
||||
|
||||
That is, the first row specifies that values can flow from the elements of the qualifier stream into the first argument of the function provided to ``map``. The second row specifies that values can flow from the return value of the function to the elements of the stream returned from ``map``.
|
||||
|
||||
Example: Add a ``neutral`` method
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
This example shows how the Java query pack models the ``now`` method as being neutral with respect to flow.
|
||||
A neutral model is used to define that there is no flow through a method.
|
||||
|
||||
.. code-block:: java
|
||||
|
||||
public static void taintflow() {
|
||||
Instant t = Instant.now(); // There is no flow from now to t.
|
||||
...
|
||||
}
|
||||
|
||||
We need to add a tuple to the ``neutralModel``\(package, type, name, signature, kind, provenance) extensible predicate by updating a data extension file.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
extensions:
|
||||
- addsTo:
|
||||
pack: codeql/java-all
|
||||
extensible: neutralModel
|
||||
data:
|
||||
- ["java.time", "Instant", "now", "()", "summary", "manual"]
|
||||
|
||||
|
||||
Since we are adding a neutral model, we need to add tuples to the ``neutralModel`` extensible predicate.
|
||||
The first four values identify the callable (in this case a method) to be modeled as a neutral, the fifth value is the kind, and the sixth value is the provenance (origin) of the neutral.
|
||||
|
||||
- The first value ``java.time`` is the package name.
|
||||
- The second value ``Instant`` is the class (type) name.
|
||||
- The third value ``now`` is the method name.
|
||||
- The fourth value ``()`` is the method input type signature.
|
||||
- The fifth value ``summary`` is the kind of the neutral.
|
||||
- The sixth value ``manual`` is the provenance of the neutral.
|
||||
@@ -0,0 +1,435 @@
|
||||
.. _customizing-library-models-for-java:
|
||||
|
||||
:orphan:
|
||||
:nosearch:
|
||||
|
||||
Customizing Library Models for Java
|
||||
===================================
|
||||
|
||||
.. include:: ../reusables/beta-note-customizing-library-models.rst
|
||||
|
||||
The Java analysis can be customized by adding library models (summaries, sinks and sources) in data extension files.
|
||||
A model is a definition of a behavior of a library element, such as a method, that is used to improve the data flow analysis precision by identifying more results.
|
||||
Most of the security related queries are taint tracking queries that try to find paths from a source of untrusted input to a sink that represents a vulnerability. Sources are the starting points of a taint tracking data flow analysis, and sinks are the end points of a taint tracking data flow analysis.
|
||||
|
||||
Furthermore, the taint tracking queries also need to know how data can flow through elements that are not included in the source code. These are named summaries: they are models of elements that allow us to synthesize the elements flow behavior without having them in the source code. This is especially helpful when using a third party (or the standard) library.
|
||||
|
||||
The models are defined using data extensions where each tuple constitutes a model.
|
||||
A data extension file for Java is a YAML file in the form:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
extensions:
|
||||
- addsTo:
|
||||
pack: codeql/java-all
|
||||
extensible: <name of extensible predicate>
|
||||
data:
|
||||
- <tuple1>
|
||||
- <tuple2>
|
||||
- ...
|
||||
|
||||
Data extensions contribute to the extensible predicates defined in the CodeQL library. For more information on how to define data extensions and extensible predicates as well as how to wire them up, see the :ref:`data-extensions` documentation.
|
||||
|
||||
The CodeQL library for Java exposes the following extensible predicates:
|
||||
|
||||
- **sourceModel**\(package, type, subtypes, name, signature, ext, output, kind, provenance). This is used for **source** models.
|
||||
- **sinkModel**\(package, type, subtypes, name, signature, ext, input, kind, provenance). This is used for **sink** models.
|
||||
- **summaryModel**\(package, type, subtypes, name, signature, ext, input, output, kind, provenance). This is used for **summary** models.
|
||||
- **neutralModel**\(package, type, name, signature, kind, provenance). This is used for **neutral** models, which only have minor impact on the data flow analysis.
|
||||
|
||||
The extensible predicates are populated using data extensions specified in YAML files.
|
||||
|
||||
In the sections below, we will provide examples of how to add tuples to the different extensible predicates.
|
||||
The extensible predicates are used to customize and improve the existing data flow queries, by providing sources, sinks, and flow through (summaries) for library elements.
|
||||
The :ref:`reference-material` section will provide details on the *mini DSLs* that define models for each extensible predicate.
|
||||
|
||||
Example: Taint sink in the **java.sql** package
|
||||
------------------------------------------------
|
||||
|
||||
In this example we will show how to model the argument of the **execute** method as a SQL injection sink.
|
||||
This is the **execute** method in the **Statement** class, which is located in the **java.sql** package.
|
||||
Note that this sink is already added to the CodeQL Java analysis.
|
||||
|
||||
.. code-block:: java
|
||||
|
||||
public static void taintsink(Connection conn, String query) throws SQLException {
|
||||
Statement stmt = conn.createStatement();
|
||||
stmt.execute(query); // The argument to this method is a SQL injection sink.
|
||||
}
|
||||
|
||||
We need to add a tuple to the **sinkModel**\(package, type, subtypes, name, signature, ext, input, kind, provenance) extensible predicate. To do this, add the following to a data extension file:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
extensions:
|
||||
- addsTo:
|
||||
pack: codeql/java-all
|
||||
extensible: sinkModel
|
||||
data:
|
||||
- ["java.sql", "Statement", True, "execute", "(String)", "", "Argument[0]", "sql", "manual"]
|
||||
|
||||
|
||||
Since we are adding a new sink, we need to add a tuple to the **sinkModel** extensible predicate.
|
||||
The first five values identify the callable (in this case a method) to be modeled as a sink.
|
||||
|
||||
- The first value **java.sql** is the package name.
|
||||
- The second value **Statement** is the name of the class (type) that contains the method.
|
||||
- The third value **True** is a flag that indicates whether or not the sink also applies to all overrides of the method.
|
||||
- The fourth value **execute** is the method name.
|
||||
- The fifth value **(String)** is the method input type signature.
|
||||
|
||||
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 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
|
||||
----------------------------------------------------
|
||||
In this example we show how to model the return value from the **getInputStream** method as a **remote** source.
|
||||
This is the **getInputStream** method in the **Socket** class, which is located in the **java.net** package.
|
||||
Note that this source is already added to the CodeQL Java analysis.
|
||||
|
||||
.. code-block:: java
|
||||
|
||||
public static void tainted(Socket socket) throws IOException {
|
||||
InputStream stream = socket.getInputStream(); // The return value of this method is a remote source of taint.
|
||||
...
|
||||
}
|
||||
|
||||
We need to add a tuple to the **sourceModel**\(package, type, subtypes, name, signature, ext, output, kind, provenance) extensible predicate. To do this, add the following to a data extension file:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
extensions:
|
||||
- addsTo:
|
||||
pack: codeql/java-all
|
||||
extensible: sourceModel
|
||||
data:
|
||||
- ["java.net", "Socket", False, "getInputStream", "()", "", "ReturnValue", "remote", "manual"]
|
||||
|
||||
|
||||
Since we are adding a new source, we need to add a tuple to the **sourceModel** extensible predicate.
|
||||
The first five values identify the callable (in this case a method) to be modeled as a source.
|
||||
|
||||
- The first value **java.net** is the package name.
|
||||
- The second value **Socket** is the name of the class (type) that contains the source.
|
||||
- The third value **False** is a flag that indicates whether or not the source also applies to all overrides of the method.
|
||||
- The fourth value **getInputStream** is the method name.
|
||||
- The fifth value **()** is the method input type signature.
|
||||
|
||||
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 source.
|
||||
|
||||
- The seventh value **ReturnValue** is the access path to the return of the method, which means that it is the return value that should be considered a source of tainted input.
|
||||
- The eighth value **remote** is the kind of the source. The source kind is used to define the queries where the source is in scope. **remote** applies to many of the security related queries as it means a remote source of untrusted data. As an example the SQL injection query uses **remote** sources.
|
||||
- The ninth value **manual** is the provenance of the source, which is used to identify the origin of the source.
|
||||
|
||||
Example: Add flow through the **concat** method
|
||||
------------------------------------------------
|
||||
In this example we show how to model flow through a method for a simple case.
|
||||
This pattern covers many of the cases where we need to define flow through a method.
|
||||
Note that the flow through the **concat** method is already added to the CodeQL Java analysis.
|
||||
|
||||
.. code-block:: java
|
||||
|
||||
public static void taintflow(String s1, String s2) {
|
||||
String t = s1.concat(s2); // There is taint flow from s1 and s2 to t.
|
||||
...
|
||||
}
|
||||
|
||||
We need to add tuples to the **summaryModel**\(package, type, subtypes, name, signature, ext, input, output, kind, provenance) extensible predicate. To do this, add the following to a data extension file:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
extensions:
|
||||
- addsTo:
|
||||
pack: codeql/java-all
|
||||
extensible: summaryModel
|
||||
data:
|
||||
- ["java.lang", "String", False, "concat", "(String)", "", "Argument[this]", "ReturnValue", "taint", "manual"]
|
||||
- ["java.lang", "String", False, "concat", "(String)", "", "Argument[0]", "ReturnValue", "taint", "manual"]
|
||||
|
||||
Reasoning:
|
||||
|
||||
Since we are adding flow through a method, we need to add tuples to the **summaryModel** extensible predicate.
|
||||
Each tuple defines flow from one argument to the return value.
|
||||
The first row defines flow from the qualifier (**s1** in the example) to the return value (**t** in the example) and the second row defines flow from the first argument (**s2** in the example) to the return value (**t** in the example).
|
||||
|
||||
The first five values identify the callable (in this case a method) to be modeled as a summary.
|
||||
These are the same for both of the rows above as we are adding two summaries for the same method.
|
||||
|
||||
- The first value **java.lang** is the package name.
|
||||
- The second value **String** is the class (type) name.
|
||||
- The third value **False** is a flag that indicates whether or not the summary also applies to all overrides of the method.
|
||||
- The fourth value **concat** is the method name.
|
||||
- The fifth value **(String)** is the method input type signature.
|
||||
|
||||
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 summary.
|
||||
|
||||
- The seventh value is the access path to the input (where data flows from). **Argument[this]** is the access path to the qualifier (**s1** in the example) and **Argument[0]** is the access path to the first argument (**s2** in the example).
|
||||
- The eighth value **ReturnValue** is the access path to the output (where data flows to), in this case **ReturnValue**, which means that the input flows to the return value.
|
||||
- The ninth value **taint** is the kind of the flow. **taint** means that taint is propagated through the call.
|
||||
- The tenth value **manual** is the provenance of the summary, which is used to identify the origin of the summary.
|
||||
|
||||
Example: Add flow through the **map** method
|
||||
---------------------------------------------
|
||||
In this example, we will see a more complex example of modeling flow through a method.
|
||||
This pattern shows how to model flow through higher order methods and collection types.
|
||||
Note that the flow through the **map** method is already added to the CodeQL Java analysis.
|
||||
|
||||
.. code-block:: java
|
||||
|
||||
public static void taintflow(Stream<String> s) {
|
||||
Stream<String> l = s.map(e -> e.concat("\n"));
|
||||
...
|
||||
}
|
||||
|
||||
To do this, add the following to a data extension file:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
extensions:
|
||||
- addsTo:
|
||||
pack: codeql/java-all
|
||||
extensible: summaryModel
|
||||
data:
|
||||
- ["java.util.stream", "Stream", True, "map", "(Function)", "", "Argument[this].Element", "Argument[0].Parameter[0]", "value", "manual"]
|
||||
- ["java.util.stream", "Stream", True, "map", "(Function)", "", "Argument[0].ReturnValue", "ReturnValue.Element", "value", "manual"]
|
||||
|
||||
|
||||
Since we are adding flow through a method, we need to add tuples to the **summaryModel** extensible predicate.
|
||||
Each tuple defines part of the flow that comprises the total flow through the **map** method.
|
||||
The first five values identify the callable (in this case a method) to be modeled as a summary.
|
||||
These are the same for both of the rows above as we are adding two summaries for the same method.
|
||||
|
||||
- The first value **java.util.stream** is the package name.
|
||||
- The second value **Stream** is the class (type) name.
|
||||
- The third value **True** is a flag that indicates whether or not the summary also applies to all overrides of the method.
|
||||
- The fourth value **map** is the method name.
|
||||
- The fifth value **Function** is the method input type signature.
|
||||
|
||||
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 summary definition.
|
||||
|
||||
- The seventh value is the access path to the **input** (where data flows from).
|
||||
- The eighth value is the access path to the **output** (where data flows to).
|
||||
|
||||
For the first row:
|
||||
|
||||
- The seventh value is **Argument[this].Element**, which is the access path to the elements of the qualifier (the elements of the stream **s** in the example).
|
||||
- The eight value is **Argument[0].Parameter[0]**, which is the access path to the first parameter of the **Function** argument of **map** (the lambda parameter **e** in the example).
|
||||
|
||||
For the second row:
|
||||
|
||||
- The seventh value is **Argument[0].ReturnValue**, which is the access path to the return value of the **Function** argument of **map** (the return value of the lambda in the example).
|
||||
- The eighth value is **ReturnValue.Element**, which is the access path to the elements of the return value of **map** (the elements of the stream **l** in the example).
|
||||
|
||||
For the remaining values for both rows:
|
||||
|
||||
- The ninth value **value** is the kind of the flow. **value** means that the value is preserved.
|
||||
- The tenth value **manual** is the provenance of the summary, which is used to identify the origin of the summary.
|
||||
|
||||
That is, the first row models that there is value flow from the elements of the qualifier stream into the first argument of the function provided to **map** and the second row models that there is value flow from the return value of the function to the elements of the stream returned from **map**.
|
||||
|
||||
Example: Add a **neutral** method
|
||||
----------------------------------
|
||||
In this example we will show how to model the **now** method as being neutral with respect to flow.
|
||||
A neutral model is used to define that there is no flow through a method.
|
||||
Note that the neutral model for the **now** method is already added to the CodeQL Java analysis.
|
||||
|
||||
.. code-block:: java
|
||||
|
||||
public static void taintflow() {
|
||||
Instant t = Instant.now(); // There is no flow from now to t.
|
||||
...
|
||||
}
|
||||
|
||||
We need to add a tuple to the **neutralModel**\(package, type, name, signature, kind, provenance) extensible predicate. To do this, add the following to a data extension file:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
extensions:
|
||||
- addsTo:
|
||||
pack: codeql/java-all
|
||||
extensible: neutralModel
|
||||
data:
|
||||
- ["java.time", "Instant", "now", "()", "summary", "manual"]
|
||||
|
||||
|
||||
Since we are adding a neutral model, we need to add tuples to the **neutralModel** extensible predicate.
|
||||
The first four values identify the callable (in this case a method) to be modeled as a neutral, the fifth value is the kind, and the sixth value is the provenance (origin) of the neutral.
|
||||
|
||||
- The first value **java.time** is the package name.
|
||||
- The second value **Instant** is the class (type) name.
|
||||
- The third value **now** is the method name.
|
||||
- The fourth value **()** is the method input type signature.
|
||||
- The fifth value **summary** is the kind of the neutral.
|
||||
- The sixth value **manual** is the provenance of the neutral.
|
||||
|
||||
.. _reference-material:
|
||||
|
||||
Reference material
|
||||
------------------
|
||||
|
||||
The following sections provide reference material for extensible predicates.
|
||||
This includes descriptions of each of the arguments (e.g. access paths, kinds and provenance).
|
||||
|
||||
Extensible predicates
|
||||
---------------------
|
||||
|
||||
Below is a description of the columns for each extensible predicate.
|
||||
Sources, sinks, summaries and neutrals are commonly known as models.
|
||||
The semantics of many of the columns of the extensible predicates are shared.
|
||||
|
||||
The shared columns are:
|
||||
|
||||
- **package**: Name of the package containing the element(s) to be modeled.
|
||||
- **type**: Name of the type containing the element(s) to be modeled.
|
||||
- **subtypes**: A boolean flag indicating whether the model should also apply to all overrides of the selected element(s).
|
||||
- **name**: Name of the element (optional). If this is left blank, it means all elements matching the previous selection criteria.
|
||||
- **signature**: Type signature of the selected element (optional). If this is left blank, it means all elements matching the previous selection criteria.
|
||||
- **ext**: Specifies additional API-graph-like edges (mostly empty) and out of scope for this document.
|
||||
- **provenance**: Provenance (origin) of the model definition.
|
||||
|
||||
The columns **package**, **type**, **subtypes**, **name**, and **signature** are used to select the element(s) that the model applies to.
|
||||
|
||||
The :ref:`access-paths` section describes how access paths are composed.
|
||||
This is the most complicated part of the extensible predicates and the **mini DSL** for access paths is shared across all extensible predicates.
|
||||
|
||||
sourceModel(package, type, subtypes, name, signature, ext, output, kind, provenance)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Taint source. Most taint tracking queries will use all sources added to this extensible predicate regardless of their kind.
|
||||
|
||||
- **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:
|
||||
|
||||
- **remote**: A remote source of possibly tainted data. This is the most common kind for a source. Sources of this kind are used for almost all taint tracking queries.
|
||||
|
||||
Below is an enumeration of the remaining source kinds, but they are out of scope for this documentation:
|
||||
|
||||
- **contentprovider**, **android-external-storage-dir**.
|
||||
|
||||
sinkModel(package, type, subtypes, name, signature, ext, input, kind, provenance)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Taint sink. As opposed to source kinds, there are many different kinds of sinks as these tend to be more query specific.
|
||||
|
||||
- **input**: Access path to the sink, where we want to check if tainted data can flow into.
|
||||
- **kind**: Kind of the sink.
|
||||
|
||||
The following sink kinds are supported:
|
||||
|
||||
- **bean-validation**: A sink that can be used for insecure bean validation, such as in calls to **ConstraintValidatorContext.buildConstraintViolationWithTemplate**.
|
||||
- **command-injection**: A sink that can be used to inject shell commands, such as in calls to **Runtime.exec**.
|
||||
- **file-content-store**: A sink that can be used to control the contents of a file, such as in a **Files.write** call.
|
||||
- **fragment-injection**: A sink that can be used for Android fragment injection, such as in a **FragmentTransaction.replace** call.
|
||||
- **groovy-injection**: A sink that can be used for Groovy injection, such as in a **GroovyShell.evaluate** call.
|
||||
- **hostname-verification**: A sink that can be used for unsafe hostname verification, such as in calls to **HttpsURLConnection.setHostnameVerifier**.
|
||||
- **html-injection**: A sink that can be used for XSS via HTML injection, such as in a **ResponseStream.write** call.
|
||||
- **information-leak**: A sink that can be used to leak information to an HTTP response, such as in calls to **HttpServletResponse.sendError**.
|
||||
- **intent-redirection**: A sink that can be used for Android intent redirection, such as in a **Context.startActivity** call.
|
||||
- **jexl-injection**: A sink that can be used for JEXL expression injection, such as in a **JexlExpression.evaluate** call.
|
||||
- **jndi-injection**: A sink that can be used for JNDI injection, such as in a **Context.lookup** call.
|
||||
- **js-injection**: A sink that can be used for XSS via JavaScript injection, such as in a **Webview.evaluateJavaScript** call.
|
||||
- **ldap-injection**: A sink that can be used for LDAP injection, such as in a **DirContext.search** call.
|
||||
- **log-injection**: A sink that can be used for log injection, such as in a **Logger.warn** call.
|
||||
- **mvel-injection**: A sink that can be used for MVEL expression injection, such as in a **MVEL.eval** call.
|
||||
- **ognl-injection**: A sink that can be used for OGNL injection, such as in an **Ognl.getValue** call.
|
||||
- **path-injection**: A sink that can be used for path injection in a file system access, such as in calls to **new FileReader**.
|
||||
- **pending-intents**: A sink that can be used to send an implicit and mutable `PendingIntent` to a third party, such as in an **Activity.setResult** call.
|
||||
- **request-forgery**: A sink that controls the URL of a request, such as in an **HttpRequest.newBuilder** call.
|
||||
- **response-splitting**: A sink that can be used for HTTP response splitting, such as in calls to **HttpServletResponse.setHeader**.
|
||||
- **sql-injection**: A sink that can be used for SQL injection, such as in a **Statement.executeQuery** call.
|
||||
- **template-injection**: A sink that can be used for server side template injection, such as in a **Velocity.evaluate** call.
|
||||
- **trust-boundary-violation**: A sink that can be used to cross a trust boundary, such as in a **HttpSession.setAttribute** call.
|
||||
- **url-redirection**: A sink that can be used to redirect the user to a malicious URL, such as in a **Response.temporaryRedirect** call.
|
||||
- **xpath-injection**: A sink that can be used for XPath injection, such as in a **XPath.evaluate** call.
|
||||
- **xslt-injection**: A sink that can be used for XSLT injection, such as in a **Transformer.transform** call.
|
||||
|
||||
summaryModel(package, type, subtypes, name, signature, ext, input, output, kind, provenance)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Flow through (summary). This extensible predicate is used to model flow through elements.
|
||||
|
||||
- **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:
|
||||
|
||||
- **taint**: This means the output is not necessarily equal to the input, but it was derived from the input in an unrestrictive way. An attacker who controls the input will have significant control over the output as well.
|
||||
- **value**: This means that the output equals the input or a copy of the input such that all of its properties are preserved.
|
||||
|
||||
neutralModel(package, type, name, signature, kind, provenance)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This extensible predicate is not typically needed externally, but included here for completeness.
|
||||
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:
|
||||
|
||||
Access paths
|
||||
------------
|
||||
The **input**, and **output** columns consist of a **.**-separated list of components, which is evaluated from left to right, with each step selecting a new set of values derived from the previous set of values.
|
||||
|
||||
The following components are supported:
|
||||
|
||||
- **Argument[**\ `n`\ **]** selects the argument at index `n` (zero-indexed).
|
||||
- **Argument[**\ `this`\ **]** selects the qualifier (instance parameter).
|
||||
- **Argument[**\ `n1..n2`\ **]** selects the arguments in the given range (both ends included).
|
||||
- **Parameter[**\ `n`\ **]** selects the parameter at index `n` (zero-indexed).
|
||||
- **Parameter[**\ `n1..n2`\ **]** selects the parameters in the given range (both ends included).
|
||||
- **ReturnValue** selects the return value.
|
||||
- **Field[**\ `name`\ **]** selects the field with the fully qualified name `name`.
|
||||
- **SyntheticField[**\ `name`\ **]** selects the synthetic field with name `name`.
|
||||
- **SyntheticGlobal[**\ `name`\ **]** selects the synthetic global with name `name`.
|
||||
- **ArrayElement** selects the elements of an array.
|
||||
- **Element** selects the elements of a collection-like container.
|
||||
- **WithoutElement** selects a collection-like container without its elements. This is for input only.
|
||||
- **WithElement** selects the elements of a collection-like container, but points to the container itself. This is for input only.
|
||||
- **MapKey** selects the element keys of a map.
|
||||
- **MapValue** selects the element values of a map.
|
||||
|
||||
Provenance
|
||||
----------
|
||||
|
||||
The **provenance** column is used to specify the provenance (origin) of the model definition and how the model was verified.
|
||||
The following values are supported:
|
||||
|
||||
- **manual**: The model was manually created and added to the extensible predicate.
|
||||
|
||||
or values in the form **origin-verification**, where origin is one of:
|
||||
|
||||
- **ai**: The model was generated by AI.
|
||||
- **df**: The model was generated by the dataflow model generator.
|
||||
- **tb**: The model was generated by the type based model generator.
|
||||
- **hq**: The model was generated using a heuristic query.
|
||||
|
||||
and verification is one of:
|
||||
|
||||
- **manual**: The model was verified by a human.
|
||||
- **generated**: The model was generated, but not verified by a human.
|
||||
|
||||
The provenance is used to distinguish between models that are manually added (or verified) to the extensible predicate and models that are automatically generated.
|
||||
Furthermore, it impacts the data flow analysis in the following way:
|
||||
|
||||
- A **manual** model takes precedence over **generated** models. If a **manual** model exists for an element then all **generated** models are ignored.
|
||||
- A **generated** model is ignored during analysis, if the source code of the element it is modeling is available.
|
||||
|
||||
That is, generated models are less trusted than manual models and only used if neither source code nor a manual model is available.
|
||||
|
||||
|
||||
.. include:: ../reusables/data-extensions.rst
|
||||
@@ -1,183 +0,0 @@
|
||||
.. _extensible-predicates:
|
||||
|
||||
:orphan:
|
||||
:nosearch:
|
||||
|
||||
Extensible predicates and their interaction with data extensions
|
||||
================================================================
|
||||
|
||||
You can use data extensions to model the methods and callables that control dataflow in any framework or library. This is especially useful for custom frameworks or niche libraries, that are not supported by the standard CodeQL libraries.
|
||||
|
||||
.. include:: ../reusables/beta-note-model-packs-java.rst
|
||||
|
||||
About this article
|
||||
------------------
|
||||
|
||||
This reference article describes the available inputs for the extensible predicates, including access paths, kinds, and provenance.
|
||||
|
||||
Sources, sinks, summaries, and neutrals are commonly known as models. These models support several shared arguments and a few model-specific arguments. The arguments populate a series of columns for each extensible predicate.
|
||||
|
||||
About extensible predicates
|
||||
---------------------------
|
||||
|
||||
At a high level, there are two main components to using data extensions. The query writer defines one or more extensible predicates in their query libraries. CLI and code scanning users who want to augment these predicates supply one or more extension files whose data gets injected into the extensible predicate during evaluation. The extension files are either stored directly in the repository where the codebase to be analyzed is hosted, or downloaded as CodeQL model packs.
|
||||
|
||||
This example of an extensible predicate for a source is taken from the core Java libraries https://github.com/github/codeql/blob/main/java/ql/lib/semmle/code/java/dataflow/ExternalFlowExtensions.qll#L8-L11
|
||||
|
||||
.. code-block:: ql
|
||||
|
||||
extensible predicate sourceModel(
|
||||
string package, string type, boolean subtypes, string name,
|
||||
string signature, string ext, string output, string kind,
|
||||
string provenance
|
||||
);
|
||||
|
||||
An extensible predicate is a CodeQL predicate with the following restrictions:
|
||||
|
||||
- It uses the ``extensible`` keyword.
|
||||
- It has no body.
|
||||
- All predicate parameters have primitive types.
|
||||
- It is not in a module.
|
||||
|
||||
Columns shared by all extensible predicates
|
||||
-------------------------------------------
|
||||
|
||||
The semantics of many of the columns of the extensible predicates are shared. The columns ``package``, ``type``, ``subtypes``, ``name``, and ``signature`` define which element(s) the model applies to.
|
||||
|
||||
- ``package``: Name of the package containing the element(s) to be modeled.
|
||||
- ``type``: Name of the type containing the element(s) to be modeled.
|
||||
- ``subtypes``: A boolean flag indicating whether the model should also apply to all overrides of the selected element(s).
|
||||
- ``name``: Name of the element (optional). If this is left blank, it means all elements matching the previous selection criteria.
|
||||
- ``signature``: Type signature of the selected element (optional). If this is left blank, it means all elements matching the previous selection criteria.
|
||||
- ``ext``: Specifies additional API-graph-like edges (mostly empty) and out of scope for this document.
|
||||
- ``provenance``: Provenance (origin) of the model definition. For more information, see ":ref:`provenance`."
|
||||
|
||||
The sematics for access paths are also common to all extensible predicates. For more information, see ":ref:`access-paths`."
|
||||
|
||||
sourceModel(package, type, subtypes, name, signature, ext, output, kind, provenance)
|
||||
------------------------------------------------------------------------------------
|
||||
|
||||
Taint source. Most taint tracking queries will use all sources added to this extensible predicate regardless of their kind.
|
||||
|
||||
- ``output``: Access path to the source, where the possibly tainted data flows from.
|
||||
- ``kind``: Kind of the source.
|
||||
|
||||
As most sources are used by all taint tracking queries there are only a few different source kinds.
|
||||
The following source kinds are supported:
|
||||
|
||||
- ``remote``: A remote source of possibly tainted data. This is the most common kind for a source. Sources of this kind are used for almost all taint tracking queries.
|
||||
- ``contentprovider``, ``android-external-storage-dir``: These kinds are also supported but usage is advanced.
|
||||
|
||||
sinkModel(package, type, subtypes, name, signature, ext, input, kind, provenance)
|
||||
---------------------------------------------------------------------------------
|
||||
|
||||
Taint sink. As opposed to source kinds, there are many different kinds of sinks as these tend to be more query specific.
|
||||
|
||||
- ``input``: Access path to the sink, where we want to check if tainted data can flow into.
|
||||
- ``kind``: Kind of the sink.
|
||||
|
||||
The following sink kinds are supported:
|
||||
|
||||
- ``bean-validation``: A sink that can be used for insecure bean validation, such as in calls to ``ConstraintValidatorContext.buildConstraintViolationWithTemplate``.
|
||||
- ``command-injection``: A sink that can be used to inject shell commands, such as in calls to ``Runtime.exec``.
|
||||
- ``file-content-store``: A sink that can be used to control the contents of a file, such as in a ``Files.write`` call.
|
||||
- ``fragment-injection``: A sink that can be used for Android fragment injection, such as in a ``FragmentTransaction.replace`` call.
|
||||
- ``groovy-injection``: A sink that can be used for Groovy injection, such as in a ``GroovyShell.evaluate`` call.
|
||||
- ``hostname-verification``: A sink that can be used for unsafe hostname verification, such as in calls to ``HttpsURLConnection.setHostnameVerifier``.
|
||||
- ``html-injection``: A sink that can be used for XSS via HTML injection, such as in a ``ResponseStream.write`` call.
|
||||
- ``information-leak``: A sink that can be used to leak information to an HTTP response, such as in calls to ``HttpServletResponse.sendError``.
|
||||
- ``intent-redirection``: A sink that can be used for Android intent redirection, such as in a ``Context.startActivity`` call.
|
||||
- ``jexl-injection``: A sink that can be used for JEXL expression injection, such as in a ``JexlExpression.evaluate`` call.
|
||||
- ``jndi-injection``: A sink that can be used for JNDI injection, such as in a ``Context.lookup`` call.
|
||||
- ``js-injection``: A sink that can be used for XSS via JavaScript injection, such as in a ``Webview.evaluateJavaScript`` call.
|
||||
- ``ldap-injection``: A sink that can be used for LDAP injection, such as in a ``DirContext.search`` call.
|
||||
- ``log-injection``: A sink that can be used for log injection, such as in a ``Logger.warn`` call.
|
||||
- ``mvel-injection``: A sink that can be used for MVEL expression injection, such as in a ``MVEL.eval`` call.
|
||||
- ``ognl-injection``: A sink that can be used for OGNL injection, such as in an ``Ognl.getValue`` call.
|
||||
- ``path-injection``: A sink that can be used for path injection in a file system access, such as in calls to ``new FileReader``.
|
||||
- ``pending-intents``: A sink that can be used to send an implicit and mutable `PendingIntent` to a third party, such as in an ``Activity.setResult`` call.
|
||||
- ``request-forgery``: A sink that controls the URL of a request, such as in an ``HttpRequest.newBuilder`` call.
|
||||
- ``response-splitting``: A sink that can be used for HTTP response splitting, such as in calls to ``HttpServletResponse.setHeader``.
|
||||
- ``sql-injection``: A sink that can be used for SQL injection, such as in a ``Statement.executeQuery`` call.
|
||||
- ``template-injection``: A sink that can be used for server-side template injection, such as in a ``Velocity.evaluate`` call.
|
||||
- ``trust-boundary-violation``: A sink that can be used to cross a trust boundary, such as in a ``HttpSession.setAttribute`` call.
|
||||
- ``url-redirection``: A sink that can be used to redirect the user to a malicious URL, such as in a ``Response.temporaryRedirect`` call.
|
||||
- ``xpath-injection``: A sink that can be used for XPath injection, such as in a ``XPath.evaluate`` call.
|
||||
- ``xslt-injection``: A sink that can be used for XSLT injection, such as in a ``Transformer.transform`` call.
|
||||
|
||||
summaryModel(package, type, subtypes, name, signature, ext, input, output, kind, provenance)
|
||||
--------------------------------------------------------------------------------------------
|
||||
|
||||
Flow through (summary). This extensible predicate is used to model flow through elements.
|
||||
|
||||
- ``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.
|
||||
|
||||
The following kinds are supported:
|
||||
|
||||
- ``taint``: This means the output is not necessarily equal to the input, but it was derived from the input in an unrestrictive way. An attacker who controls the input will have significant control over the output as well.
|
||||
- ``value``: This means that the output equals the input or a copy of the input such that all of its properties are preserved.
|
||||
|
||||
neutralModel(package, type, name, signature, kind, provenance)
|
||||
--------------------------------------------------------------
|
||||
|
||||
This extensible predicate is not typically needed externally, but is included here for completeness.
|
||||
It has limited impact on dataflow analysis.
|
||||
Manual neutrals are considered high-confidence dispatch call targets and can reduce the number of dispatch call targets during dataflow 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).
|
||||
|
||||
.. _access-paths:
|
||||
|
||||
Access paths
|
||||
------------
|
||||
The ``input``, and ``output`` columns consist of a ``.``-separated list of components, which is evaluated from left to right, with each step selecting a new set of values derived from the previous set of values.
|
||||
|
||||
The following components are supported:
|
||||
|
||||
- ``Argument[``\ `n`\ ``]`` selects the argument at index `n` (zero-indexed).
|
||||
- ``Argument[``\ `this`\ ``]`` selects the qualifier (instance parameter).
|
||||
- ``Argument[``\ `n1..n2`\ ``]`` selects the arguments in the given range (both ends included).
|
||||
- ``Parameter[``\ `n`\ ``]`` selects the parameter at index `n` (zero-indexed).
|
||||
- ``Parameter[``\ `n1..n2`\ ``]`` selects the parameters in the given range (both ends included).
|
||||
- ``ReturnValue`` selects the return value.
|
||||
- ``Field[``\ `name`\ ``]`` selects the field with the fully qualified name `name`.
|
||||
- ``SyntheticField[``\ `name`\ ``]`` selects the synthetic field with name `name`.
|
||||
- ``SyntheticGlobal[``\ `name`\ ``]`` selects the synthetic global with name `name`.
|
||||
- ``ArrayElement`` selects the elements of an array.
|
||||
- ``Element`` selects the elements of a collection-like container.
|
||||
- ``WithoutElement`` selects a collection-like container without its elements. This is for input only.
|
||||
- ``WithElement`` selects the elements of a collection-like container, but points to the container itself. This is for input only.
|
||||
- ``MapKey`` selects the element keys of a map.
|
||||
- ``MapValue`` selects the element values of a map.
|
||||
|
||||
.. _provenance:
|
||||
|
||||
Provenance
|
||||
----------
|
||||
|
||||
The ``provenance`` column is used to specify the provenance (origin) of the model definition and how the model was verified.
|
||||
The following values are supported.
|
||||
|
||||
- ``manual``: The model was manually created and added to the extensible predicate.
|
||||
|
||||
Values can also take the form ``ORIGIN-VERIFICATION``, where ``ORIGIN`` is one of:
|
||||
|
||||
- ``ai``: The model was generated by artificial intelligence (AI).
|
||||
- ``df``: The model was generated by the dataflow model generator.
|
||||
- ``tb``: The model was generated by the type based model generator.
|
||||
- ``hq``: The model was generated using a heuristic query.
|
||||
|
||||
And ``VERIFICATION`` is one of:
|
||||
|
||||
- ``manual``: The model was verified by a human.
|
||||
- ``generated``: The model was generated, but not verified by a human.
|
||||
|
||||
The provenance is used to distinguish between models that are manually added (or verified) to the extensible predicate and models that are automatically generated.
|
||||
Furthermore, it impacts the dataflow analysis in the following way:
|
||||
|
||||
- A ``manual`` model takes precedence over ``generated`` models. If a ``manual`` model exists for an element then all ``generated`` models are ignored.
|
||||
- A ``generated`` model is ignored during analysis, if the source code of the element it is modeling is available.
|
||||
|
||||
That is, generated models are less trusted than manual models and only used if neither source code nor a manual model is available.
|
||||
@@ -8,7 +8,7 @@ CodeQL has classes for identifying code that calls other code, and code that can
|
||||
Call graph classes
|
||||
------------------
|
||||
|
||||
The CodeQL library for Java/Kotlin provides two abstract classes for representing a program's call graph: ``Callable`` and ``Call``. The former is simply the common superclass of ``Method`` and ``Constructor``, the latter is a common superclass of ``MethodAccess``, ``ClassInstanceExpression``, ``ThisConstructorInvocationStmt`` and ``SuperConstructorInvocationStmt``. Simply put, a ``Callable`` is something that can be invoked, and a ``Call`` is something that invokes a ``Callable``.
|
||||
The CodeQL library for Java provides two abstract classes for representing a program's call graph: ``Callable`` and ``Call``. The former is simply the common superclass of ``Method`` and ``Constructor``, the latter is a common superclass of ``MethodAccess``, ``ClassInstanceExpression``, ``ThisConstructorInvocationStmt`` and ``SuperConstructorInvocationStmt``. Simply put, a ``Callable`` is something that can be invoked, and a ``Call`` is something that invokes a ``Callable``.
|
||||
|
||||
For example, in the following program all callables and calls have been annotated with comments:
|
||||
|
||||
@@ -88,7 +88,7 @@ This simple query typically returns a large number of results.
|
||||
|
||||
We have to use ``polyCalls`` instead of ``calls`` here: we want to be reasonably sure that ``callee`` is not called, either directly or via overriding.
|
||||
|
||||
Running this query on a typical Java/Kotlin project results in lots of hits in the Java/Kotlin standard library. This makes sense, since no single client program uses every method of the standard library. More generally, we may want to exclude methods and constructors from compiled libraries. We can use the predicate ``fromSource`` to check whether a compilation unit is a source file, and refine our query:
|
||||
Running this query on a typical Java project results in lots of hits in the Java standard library. This makes sense, since no single client program uses every method of the standard library. More generally, we may want to exclude methods and constructors from compiled libraries. We can use the predicate ``fromSource`` to check whether a compilation unit is a source file, and refine our query:
|
||||
|
||||
.. code-block:: ql
|
||||
|
||||
|
||||
@@ -1,11 +1,9 @@
|
||||
.. _overflow-prone-comparisons-in-java:
|
||||
|
||||
Overflow-prone comparisons in Java and Kotlin
|
||||
=============================================
|
||||
Overflow-prone comparisons in Java
|
||||
==================================
|
||||
|
||||
You can use CodeQL to check for comparisons in Java/Kotlin code where one side of the comparison is prone to overflow.
|
||||
|
||||
.. include:: ../reusables/kotlin-beta-note.rst
|
||||
You can use CodeQL to check for comparisons in Java code where one side of the comparison is prone to overflow.
|
||||
|
||||
About this article
|
||||
------------------
|
||||
|
||||
@@ -1,11 +1,9 @@
|
||||
.. _types-in-java:
|
||||
|
||||
Types in Java and Kotlin
|
||||
========================
|
||||
Types in Java
|
||||
=============
|
||||
|
||||
You can use CodeQL to find out information about data types used in Java/Kotlin code. This allows you to write queries to identify specific type-related issues.
|
||||
|
||||
.. include:: ../reusables/kotlin-beta-note.rst
|
||||
You can use CodeQL to find out information about data types used in Java code. This allows you to write queries to identify specific type-related issues.
|
||||
|
||||
About working with Java types
|
||||
-----------------------------
|
||||
|
||||
@@ -3,9 +3,7 @@
|
||||
Working with source locations
|
||||
=============================
|
||||
|
||||
You can use the location of entities within Java/Kotlin code to look for potential errors. Locations allow you to deduce the presence, or absence, of white space which, in some cases, may indicate a problem.
|
||||
|
||||
.. include:: ../reusables/kotlin-beta-note.rst
|
||||
You can use the location of entities within Java code to look for potential errors. Locations allow you to deduce the presence, or absence, of white space which, in some cases, may indicate a problem.
|
||||
|
||||
About source locations
|
||||
----------------------
|
||||
@@ -177,7 +175,7 @@ Now we can extend our query to discard results where the outer and the inner exp
|
||||
wsinner > wsouter
|
||||
select outer, "Whitespace around nested operators contradicts precedence."
|
||||
|
||||
Notice that we again use ``getOp``, this time to determine whether two binary expressions have the same operator. Running our improved query now finds the Java/Kotlin standard library bug described in the Overview. It also flags up the following suspicious code in `Hadoop HBase <https://hbase.apache.org/>`__:
|
||||
Notice that we again use ``getOp``, this time to determine whether two binary expressions have the same operator. Running our improved query now finds the Java standard library bug described in the Overview. It also flags up the following suspicious code in `Hadoop HBase <https://hbase.apache.org/>`__:
|
||||
|
||||
.. code-block:: java
|
||||
|
||||
|
||||
@@ -34,19 +34,6 @@ A database (or CodeQL database) is a directory containing:
|
||||
- log files generated during database creation, query
|
||||
execution, and other operations.
|
||||
|
||||
.. _codeql-packs:
|
||||
|
||||
CodeQL packs
|
||||
------------
|
||||
|
||||
CodeQL packs are used to create, share, depend on, and run CodeQL queries, libraries, and models. You can publish your own CodeQL packs and download packs created by others. CodeQL query packs may contain queries, library files, query suites, and metadata. CodeQL library packs include one or more CodeQL libraries. CodeQL model packs include one or more data extension files that extend the core libraries by modeling additional libraries and frameworks (dependencies of your code base).
|
||||
|
||||
.. _data-extensions:
|
||||
|
||||
Data extensions
|
||||
---------------
|
||||
When you want to model the sources and sinks of a custom dependency, you can create a CodeQL library (``.qll`` file) and write queries that use it, but it's usually much simpler to create a data extension file. If you model the sources and sinks in data extension, you can use this information to expand the standard queries to cover your custom dependencies. You don't need to write any new queries.
|
||||
|
||||
.. _dil:
|
||||
|
||||
DIL
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 149 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 99 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 74 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 88 KiB |
@@ -1,4 +1,4 @@
|
||||
# CWE coverage for Java and Kotlin
|
||||
# CWE coverage for Java
|
||||
|
||||
An overview of CWE coverage for Java in the latest release of CodeQL.
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
CodeQL query help for Java and Kotlin
|
||||
=====================================
|
||||
CodeQL query help for Java
|
||||
==========================
|
||||
|
||||
.. include:: ../reusables/query-help-overview.rst
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# CWE coverage for JavaScript and TypeScript
|
||||
# CWE coverage for JavaScript
|
||||
|
||||
An overview of CWE coverage for JavaScript and TypeScript in the latest release of CodeQL.
|
||||
An overview of CWE coverage for JavaScript in the latest release of CodeQL.
|
||||
|
||||
## Overview
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
CodeQL query help for JavaScript and TypeScript
|
||||
===============================================
|
||||
CodeQL query help for JavaScript
|
||||
================================
|
||||
|
||||
.. include:: ../reusables/query-help-overview.rst
|
||||
|
||||
|
||||
@@ -1,5 +0,0 @@
|
||||
.. pull-quote::
|
||||
|
||||
Note
|
||||
|
||||
The CodeQL model editor and CodeQL model packs are currently in beta and subject to change. During the beta, model packs are supported only by Java/Kotlin analysis. To use this beta functionality, install the latest version of the CodeQL extension for Visual Studio Code.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user