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
Now that we've started printing the targets of `Call` instructions in the IR dumps, I figured I might as well print the names of the variable being loaded or stored as well. We could potentially extend this to match fields, array elements, etc., but that's quite a bit more work.
I've added one more property to the annotations provided by `PrintIRLocalFlow.qll`: The `pflow` property will now be emitted for any operand or instruction for which `configuration.hasPartialFlow` determines that there is partial flow to that node. This requires that partial flow be enabled via overriding `Configuration::explorationLimit()` in order to display. Otherwise, you'll still just get the local flow info as before.
