We don't actually need it for anything right now, but I have plans for the
future where would need it.
Although it would be nice to have it as an `API::Node`, and we could re-write
implementations so we could provide it in this instance, I'm not convinced we
can do that in general right now.
For example, if <n'th> parameter of a function has to be modeled as belonging to
a certain type, I don't see any way to specify that as an API::Node.
For me, that's ok. Until we _can_ specify things like this as API::Nodes in the
future, I would like to keep things consistent, and use `DataFlow::Node` as the
result type.
This was a good time to do this, so we don't have 2 different ways of doing the
same thing.
I needed to do this to figure out if we should expose
`API::moduleImport("flask").getMember("request")` in a helper predicate or
not. I think I ended up using more refenreces to this in the end. Although it's
not unreasonable to let someone do this themselves, I also think it's reasonable
that we provide a helper predicate for this.
This was raised as a question at review, and I don't really have a good enough
argument for moving it under POI. At the end of the day, they are _security_
related enough I guess :)
This makes collecting metrics on framework coverage a bit simpler (specifically
giving the RoutedParameter class a more descriptive result for getSourceType).
I guess it can also help a bit when trying to get an overview of a new DB, but
making metrics collection easier is my main motivation for this.
One minor change to the tests results needed: there is no longer local
flow going into the `ModuleVariableNode` for `attr_ref` in the
`moduleattr.ql` test, but I think this is reasonable.
This fixes some spurious results that occurred when we considered
_any_ use of `request.something` to be a source, even ones we had
tracked into other functions. To prevent this, using
`getAnImmediateUse` better captures the fact that we want the source
to be just the actual attribute access.
Reported in https://github.com/github/codeql/issues/2650
I found this during a bit of spring cleaning in my working
directory. As this doesn't have any immediate security implications, I
don't know when we'll get round to fixing it, but it can't hurt to
have the test case checked in.
In general, if there is _some_ decorator on a function, it might not be safe to
track content out of it (since the decorator could do anything), but in this
case, we can see what the decorator does, so we should be able to handle it (but
we don't right now).
By my understanding of how type-tracking works, if we track content through
`my_decorator`, then we would also track content to the result of
`unrelated_func()`, which I wanted to make sure our tests would catch.
I found out the core of the problem seems to come from our lack of being able to
track to the inner scope, and added an explicit test for that.
