-
Notifications
You must be signed in to change notification settings - Fork 1.8k
C#: Refactor C# queries to use ThreatModelFlowSource
instead of RemoteFlowSource
#15419
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
C#: Refactor C# queries to use ThreatModelFlowSource
instead of RemoteFlowSource
#15419
Conversation
30fd992
to
d347967
Compare
DCA seems fine. |
d347967
to
1789d26
Compare
--- | ||
category: minorAnalysis | ||
--- | ||
* Most data flow queries that track flow from *remote* flow sources now use the current *threat model* configuration instead. This doesn't lead to any changes in the produced alerts (as the default configuration is *remote* flow sources) unless the threat model configuration is changed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is worth mentioning the specific queries that also included local sources as default no longer does so under the default threat model configuration (e.g cs/code-injection
). It is also worth bringing this up in the C# slack channel to make sure that product is informed about this change. IMO this should be perfectly fine as we don't have that many local sources defined in C# as it is - but we need to make sure that this is properly communicated both to product and via the change note. Also, it would be great to streamline this with java and furthermore it seems rather ad hoc that some queries use them while others don't. With the threat models - this will be streamlined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is starting to look good @egregius313 !
Some actionable feedback that we need to consider as a part of this PR:
XMLInjection.ql
,ExternalAPIsQuery.qll
needs to be re-factored to use threat models as well.- In
InsecureDirectObjectReferenceQuery.qll
we need to replaceRemoteFlowSource
withThreatModelFlowSource
inhasIdParameter
. - In
SqlInjection.ql
,UncontrolledFormatString.ql
thegetSourceType
predicate needs to be updated as well <— This probably requires that we lift the abstractgetSourceType
predicate to theSourceNode
class instead (which will require that some further source node descriptions are provided). - Import alerts need to be cleaned up.
There is also an open question
|
1789d26
to
6dd50b3
Compare
@michaelnebel thanks for the review!
I have added a commit d48235d which moves
I'm not sure about the deletions (I would like product's opinion on that before going through with deleting a query), but something about how to opt into the stored sources might be helpful. As I understand it, one of the things which makes things trickier in C# than Java is that the way the threat model hierarchy is setup by default, the classes which are But that means that in the long run the stored queries become largely redundant. Especially if we transition to |
Great, I will take a look! Yes, you are absolutely right - the "open" question needs to be aligned with product. We need to ask, what they think, before deleting any of those. I would recommend asking the the C# slack channel. If we only want to use stored flow sources for a query execution it is still possible using threat models, as threat models supports priorities (it is possible to enable a category of threat models, but disable certain sub categories). |
csharp/ql/lib/semmle/code/csharp/security/dataflow/flowsources/Stored.qll
Outdated
Show resolved
Hide resolved
csharp/ql/lib/semmle/code/csharp/security/dataflow/ExternalAPIsQuery.qll
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The failing test can be fixed by adding data extension file that enables local
threat models for that test.
We probably need to run DCA again after fixing the last minor changes and then get a second review as well (in case I missed something).
Furthermore, we need to have "approval" from product on the change of semantics (removing the local sources as the default for a set of queries).
3e358f3
to
6abc86a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Let's wait with merging until the discussion with product has finished.
After discussion with product, this is currently on hold until the release model for the threat model release. |
771bfba
to
11d43c0
Compare
11d43c0
to
20daa89
Compare
csharp/ql/lib/semmle/code/csharp/security/dataflow/CodeInjectionQuery.qll
Outdated
Show resolved
Hide resolved
csharp/ql/lib/semmle/code/csharp/security/dataflow/CodeInjectionQuery.qll
Outdated
Show resolved
Hide resolved
20daa89
to
dbad866
Compare
@@ -22,7 +22,7 @@ import AssemblyPathInjection::PathGraph | |||
*/ | |||
module AssemblyPathInjectionConfig implements DataFlow::ConfigSig { | |||
predicate isSource(DataFlow::Node source) { | |||
source instanceof RemoteFlowSource or | |||
source instanceof ThreatModelFlowSource or | |||
source.asExpr() = any(MainMethod main).getParameter(0).getAnAccess() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is basically a local source (we shouldn't do anything in this PR), but if main parameters are modelled generally and being "configurable" via threat models then we should consider to remove the hardcoding of main parameters here.
csharp/ql/src/Security Features/CWE-134/UncontrolledFormatString.ql
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few more minor changes and then run DCA again :-)
Since `FlowSources` now re-exports `Remote`, these can be safely removed.
…irectly. Since `ThreatModelFlowSource` contains `RemoteFlowSource` by default, we can safely remove the `RemoteSource` from the default of the queries.
1. Change `LocalSource` to extend `DataFlow::Node`, thus removed from the definiton of `Source` 2. Add a private class `AddLocalSource` which extends `Source`. This allows us to currently preserve the inclusion of local sources, while making it easier to remove it in the future.
Co-authored-by: Michael Nebel <michaelnebel@github.com>
0e16ebb
to
f488f23
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
I will start a DCA run and if that is uneventful then we merge.
DCA looks good. |
Follow up to #15359.
Refactors C# queries to use
ThreatModelFlowSource
instead ofRemoteFlowSource
.Since most of the C# queries define their sources with public classes like
I cannot remove the classes without changing the public API. Therefore, I have marked the existing
RemoteSource
classes asdeprecated
, and added a new implementation based onThreatModelFlowSource
. Since threat modeling includesremote
sources by default, I think this is a reasonable trade-off.Folllow-up PRs
Stored
variants of queries #15629AddLocalSource
classes from queries #15756