It's really hard to audit that this is all good.. I tried my best with
`icdiff` though -- and there is a problem with
ql/src/experimental/Security/CWE-348/ClientSuppliedIpUsedInSecurityCheck.ql
that needs to be fixed in the next commit
The other callables return control flow nodes,
so it is slightly inconsistent for this to return a
data flow node, but it does make models based
on API graphs nicer.
to ensure that the call graph seen by type tracking
does not include summary calls resolved by type tracking.
(I tried inserting a similar test into the Ruby codebase,
and it still compiled)
To get this to compile, I had to move the resolution of summary calls
out of the data flow nodes and into the `viableCallable` predicate.
This means that we now have a potential summary call for each
cfg call node. (I tried using the base class, `DataFlowCall`, for this
but calls to `map` got identified as class calls and would no longer
be associated with a summary.)
It is possible that the "NonLIbrary"-layers the were inserted into the
hierarchy can be removed again.
This partly reverts the changes from https://github.com/github/codeql/pull/10252
Although consistency is nice, the new messages didn't sound as natural.
New alert message would read
> Insecure hashing algorithm (md5) depends on sensitive data (password). (...)
I'm not sure what it means that a hashing algorithm depends on data. So
for me, the original text below is much easier to understand.
> Sensitive data (password) is used in a hashing algorithm (md5) that is insecure (...)
Same goes for the other sensitive data queries.
As illustrated when running the python file, the non qualified reads in
the `use` method all refer to the global variables, whereas `ex =
func(baz)` are to the things defined on the class.
The important part of the .expected changes is that the _global_
variable `bar` is used inside the function, whereas it's the local
variable for `foo` (on class scope) that is used inside the function
(which is wrong).
since
- Python 3 is ok from 3.7 onwards
- support for Python 3.6 was just dropped
- we do not actually know the minor version of the analysed code
(only of the extractor)
