In these cases the `return` might end up creating a new HTTP response, so they
need to be modeled as such.
Initially I created a very naive solution that didn't handle either
tricky_return1 or tricky_return2.
The interaction in tricky_return2/helper highlighted for me that to handle this
properly, due to the fact that the flow is across functions, we either need to
use a global dataflow/taint-tracking configuration, or some clever use of
type-trackers.
In the end, this extra effort for not modeling all returns in a flask route
handler as a creation of a HTTP response doesn't really seem to be worth it (at
least not right now). Sicne we use it with taint-tracking for the Reflected XSS
query, and use a HTTP response _creation_ as the sink (without propagating taint
to the HTTP response), we won't get into trouble where we report a path to BOTH
`make_response(...)` and the `return`
```
resp = make_response(...)
return resp
```
If we change this setup in the future, we will probably need to do something to
avoid this double-path reporting.
When dealing with
```
resp = make_response(...)
return resp
```
ideally we don't want to mark the return as a creation of a HTTP response. I'll
deal with this in a second commit, to show off how annoying it looks in the
tests right now :D
I'm not even trying to model it properly right now, and don't have a specific
use-case for it RIGHT NOW. I think we could want this in the future, but I think
it's probably better to model it when we know what we want to use it for.
Added it to the `testapp` so it's easy to run the server to SEE that it works.
Added it to `routing_test` so it's obvious this is supported by our modeling
when we _know_ it's running Django 2/3.
This required some thought for how to model that we're interested in subclasses
of `fabric.group.Group`, and not so much that class itself. Some thoughts:
---
After initially using this in `module Group`
/** A reference to a subclass of `fabric.group.Group` */
abstract class SubclassRef extends DataFlow::Node { }
private class SubclassInstantiation extends SubclassInstanceSource, DataFlow::CfgNode {
override CallNode node;
SubclassInstantiation() { node.getFunction() = any(SubclassRef ref).asCfgNode() }
}
with this in `module SerialGroup` and `module ThreadingGroup`:
class ClassRef extends DataFlow::Node, fabric::group::Group::SubclassRef {
ClassRef() { this = classRef(DataFlow::TypeTracker::end()) }
}
I wasn't too much of fan of that approach. Since we probably need the `SubclassInstanceSource` anyway, and don't really have a specific use for `SubclassRef`, I just went with concrete (QL) subclasses of `SubclassInstanceSource` in each of the modules for the Python subclasses.
I really don't know what the best approach is, so I'm very open to suggestions. I think we'll really have to flesh this out for handling Django responses, since we're interested in the fact that some subclasses provide default values for the content-type, and keeping track of that is important for XSS (since there is no XSS if response is `text/plain`)
For v1 tests, just extended with explicit calls that use keyword arguments.
For v2 tests, rewrote pretty much everything to what it 100% explicit what we support
