-
Notifications
You must be signed in to change notification settings - Fork 1.7k
JS: add initial version of ServerCrash.ql #3672
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
JS: add initial version of ServerCrash.ql #3672
Conversation
(ping me if more context is needed, this query is not trivial) |
predicate isDangerousPropertyRead(DataFlow::PropRead read) { | ||
// TODO use flow labels | ||
exists(DataFlow::PropRead base | | ||
base = read.getBase() and |
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.
How about checking if the property-read is guarded.
E.g. the below is safe, and I think it will be flagged.
function handler(req, res) {
var foo = req.body && req.body.foo && req.body.foo.bar;
}
flow-labels can maybe be used in some fancy way to achieve this.
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.
I have removed that sink now, it was purely speculative. I have added a TODO note above.
class ServerCrasher extends ExprOrStmt { | ||
HTTP::RouteHandler routeHandler; | ||
DataFlow::FunctionNode asyncFunction; |
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.
Does this need to be a class? How about converting it to a predicate:
ExprOrStmt getAServerCrasherStmt(HTTP::RouteHandler routeHandler, DataFlow::FunctionNode asyncFunction)
Actually, how about spreading it into 2 predicates, the first returning Function throwingFunction
, and the second predicate returning a ExprOrStmt crasher
from that throwingFunction
.
Rename suggestion: asyncFunction
-> asyncCallback
?
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.
All done.
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.
You're missing some qldoc.
And the Configration
is hacky, but you've already noted that (maybe used type-tracking?).
But for the sprint: 👍
CVE-2019-10775: TP/FP
CVE-2017-16014: FN
The FP can be addressed when the (hacky)
Configuration
part of the query is polished.Generally, the alerts can be hard to understand since they talk about a (long) call chain from a route handler, to an asynchronous function invocation, to a line that causes an exception to be thrown. This can be remedied by presenting the remote flow path from the
Configuration
part of the query to the user, and then hacking up a pseudo path for thethrow
case.Polish for later:
JS: remove speculative property access sink from js/server-crash
)