You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some limitations might be obvious, but we should state them nevertheless.
As a follow-up from #157, but also in relation to https://bugzilla.mozilla.org/show_bug.cgi?id=1701169, I think this project needs a good explanation of where we stop looking for what's being called when looking at a CallExpression.
Especially in contrast to looking at function parameters andassigment epxressions that we analyze to find safe/unsafe values when they flow into a sink.
E.g., this can't and won't be detected as we are unable to analyze what getwrite is and what it returns and that's probably OK.
We know that we can't ensure getwrite() isn't returning something potentially dangerous, but we shouldn't block it.
We might however throw a low-severity finding that can be disabled?
In the end, we need to acknowledge that we can't protect against malicious code authors and allow folks to customize checked/disallowed functions. For a codebase that uses wrappers on top of typical DOM APIs, it's reasonable to add these wrappers to the plugin configuration.
Some limitations might be obvious, but we should state them nevertheless.
As a follow-up from #157, but also in relation to https://bugzilla.mozilla.org/show_bug.cgi?id=1701169, I think this project needs a good explanation of where we stop looking for what's being called when looking at a CallExpression.
Especially in contrast to looking at function parameters andassigment epxressions that we analyze to find safe/unsafe values when they flow into a sink.
Example 1:
E.g., this can't and won't be detected as we are unable to analyze what
getwrite
is and what it returns and that's probably OK.We know that we can't ensure getwrite() isn't returning something potentially dangerous, but we shouldn't block it.
We might however throw a low-severity finding that can be disabled?
In the end, we need to acknowledge that we can't protect against malicious code authors and allow folks to customize checked/disallowed functions. For a codebase that uses wrappers on top of typical DOM APIs, it's reasonable to add these wrappers to the plugin configuration.
Example 2:
This should be disallowed. We can't really say what's being called here, but we do know it isn't a static literal or directly sanitized.
The text was updated successfully, but these errors were encountered: