|
1 | 1 | /** |
2 | | - * The query detects cases where a user-controlled path is used in an unsafe manner, meaning it is not both normalized and _afterwards_ checked. |
| 2 | + * The query detects cases where a user-controlled path is used in an unsafe manner, |
| 3 | + * meaning it is not both normalized and _afterwards_ checked. |
3 | 4 | * |
4 | 5 | * It does so by dividing the problematic situation into two cases: |
5 | | - * 1. The path is never normalized. |
| 6 | + * 1. The file path is never normalized. |
6 | 7 | * This is easily detected by using normalization as a sanitizer. |
7 | 8 | * |
8 | | - * 2. The path is normalized at least once, but never checked afterwards. |
9 | | - * This is detected by finding the first normalization and then ensure that |
10 | | - * no checks happen after. Since we start from the first normalization, |
| 9 | + * 2. The file path is normalized at least once, but never checked afterwards. |
| 10 | + * This is detected by finding the earliest normalization and then ensure that |
| 11 | + * no checks happen later. Since we start from the earliest normalization, |
11 | 12 | * we know that the absence of checks means that no normalization has a |
12 | 13 | * chek after it. (No checks after a second normalization would be ok if |
13 | 14 | * there was a check between the first and the second.) |
14 | 15 | * |
15 | | - * Note that one could make the dual split on whether the path is ever checked. This does |
| 16 | + * Note that one could make the dual split on whether the file path is ever checked. This does |
16 | 17 | * not work as nicely, however, since checking is modelled as a `BarrierGuard` rather than |
17 | | - * as a `Sanitizer`. That means that only some paths out of a check will be removed, and so |
18 | | - * identifying the last check is not possible simply by finding a path from it to a sink. |
| 18 | + * as a `Sanitizer`. That means that only some dataflow paths out of a check will be removed, |
| 19 | + * and so identifying the last check is not possible simply by finding a dataflow path from it |
| 20 | + * to a sink. |
19 | 21 | * |
20 | 22 | * @name Uncontrolled data used in path expression |
21 | 23 | * @description Accessing paths influenced by users can allow an attacker to access unexpected resources. |
|
0 commit comments