JS: model fastify #3527
JS: model fastify #3527
Conversation
esbena
added
JS
Awaiting evaluation
|
Evaluation: nothing of interest on a set of relatively small applications. |
There was a problem hiding this comment.
Very nice!
I'd like it if we could move towards the SourceNode chainable API over the calls/accesses predicates, and certainly away from Expr-based API when there is a data flow alternative (even though it's slightly less urgent after the recent PR).
Feel free to introduce RouteHandler.getARequestRef() and RouteHandler.getAResponseRef() if you feel the .ref() calls are a bit much.
I agree. I should have mentioned that this was a deliberate choice to match the existing code, I am sorry that I made you make the many suggestions. I have addressed all of the comments, except the one about user-controlled objects. I'll dig into how that works for this library... |
|
A simple |
| @@ -132,7 +132,9 @@ module Fastify { | |||
| string kind; | |||
|
|
|||
| RequestInputAccess() { | |||
| exists(string name | this.(DataFlow::PropRead).accesses(rh.getARequestExpr().flow(), name) | | |||
| exists(DataFlow::PropRead read, string name | | |||
| this = read and read = rh.getARequestSource().ref().getAPropertyRead(name) | |||
There was a problem hiding this comment.
Is there a need for the read variable here?
|
The dataflow-based evaluation is equally boring. |
|
All comments have been addressed. |
|
This is very nice work. The Fastify team appreciates it @esbena . If you ever need our input please feel free to reach out. |
|
Thanks @esbena! |
|
Rebased with updated expected output. |
Yet another minimal security-related model of a HTTP server implementation. The implementation is mostly boiler-plate for this kind of model. It would be nice if the already extensive HTTP.qll could recude the boiler-plate even more, but that can be done in a separate PR.
I am evaluating this on a collection of fastify dependents.
Addresses #3435.