ZipSlip can be avoided by checking that the combined and resolved
path `StartsWith` the appropriate destination directory. Refine the
`StartsWith` sanitizer to:
* Consider expressions guarded by an appropriate StartsWith check to be
sanitized.
* Consider a StartsWith check to be inappropriate if it is checking the
result of `Path.Combine`, as that has not been appropriately resolved.
Tests have been updated to reflect this refinement.
Use the GetFileName call as a sanitizer, rather than an argument to that
call. It is the _result_ of the GetFileName call which should be
considered sanitized. By using the argument, we can spuriously suppress
use-use flow. Consider:
```
var path = Path.Combine(destDir, entry.GetFullName());
var fileName = Path.GetFileName(path);
log("Extracting " + fileName);
entry.ExtractToFile(path);
```
Previously, the `ExtractToFile(path)` call would not have been flagged,
because the `path` argument to `GetFileName` was considered sanitized,
and that argument formed a use-use pair with the `path` argument to
`ExtractToFile`. Now, this result would be flagged because only the
result of the `GetFileName` call is considered sanitized.
The `definitelyHandles()` predicate calculates the relation for all exception
types, not just the ones that can actually be thrown (no automatic magic).
This commit inlines the definition of `definitelyHandles()` to get the proper
context (manual magic).
The Metrics folder has a queries.xml file which is required when
building a full distribution, as the Metrics folder gets copied into
odasa-csharp-metrics directory. However, in QL for Eclipse this doesn't
compile because it prevents import lookup at the top level. Modifying
the qlpath file to include the top-level directory on the library path
fixes the problem.
Use generic CFG splitting to add a new type of split for exception handlers,
`ExceptionHandlerSplit`, which tags eachs node belonging to a `catch` clause
with the type of exception being caught. This allows for a more accurate CFG
for `try-catch` statements, where exception filters are handled properly.
Refactor existing logic for splitting control flow nodes belonging to a `finally`
block. A `Split` defines (1) when to enter the split, (2) when to stay in the split,
and (3) when to leave the split. With only these definitions, control flow splitting
is achieved by tagging each control flow element with the set of splits that apply
to it.
