[javascript] CodeQL query to detect Log Injection#3734
Conversation
|
Hi @dellalibera, thanks for the contribution! We'll take a closer look at the query next week. |
Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com>
Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com>
esbena
left a comment
There was a problem hiding this comment.
Thank you for another contribution.
Since we already have the query for C#, I think this should be straight-forward to merge. I have two super-minor comments for you to consider.
| this = node.getAPropertyRead(propName).getACall() | ||
| ) | ||
| or | ||
| this = any(LoggerCall call) |
There was a problem hiding this comment.
This is mostly a comment.
This last conjunct should cover the two cases above if
was console().getAMemberCall(name).
(I think console.log used to require a binding with Function.prototype.bind in order for it to work when invoked as a non-method call, but that appears to have changed now).
There was a problem hiding this comment.
Thank you for your review and feedback.
Yes, if it would be console().getAMemberCall(name) I could avoid the first case
this = any(ConsoleSource console).getAMemberCall(getAStandardLoggerMethodName())
but not the second one.
The second check
exists(DataFlow::SourceNode node, string propName |
any(ConsoleSource console).getAPropertyRead() = node.getAPropertySource(propName) and
this = node.getAPropertyRead(propName).getACall()
)
detects cases where the console.log (for example) is assigned to a property of another object.
For example, consider the following case:
const my_logger = {
log: console.log
}
my_logger.log("hi")
Though the Logging.dll will be updated to console().getAMemberCall(name), I will still miss the above case (please, do not hesitate to correct me if I am wrong).
There was a problem hiding this comment.
I have opened #3767 to address the first case, so lets drop that case in this PR.
For the second case, we have a bit better machinery for tracking special values of interest through properties and even calls ("type tracking"), but lets just keep the second case as is.
Let me know if you want to try out the "type tracking" feature later.
There was a problem hiding this comment.
Sorry for the late reply and thank you again for your feedback.
I am really happy that I inspire the other PR. Since now it is merged, I remove the first case, and leave as is the second one.
Let me know if there is something else I can do.
About the "type tracking" feature is something that I will investigate.
Co-authored-by: Esben Sparre Andreasen <esbena@github.com>
esbena
left a comment
There was a problem hiding this comment.
Thanks. I will merge when the tests go green.
|
Thanks @esbena. I am really happy that this PR is merged! |
Log Injection query is available in c# query but it is not available in javascript query.
I created a query to detect a log injection vulnerability in javascript code.
This query addresses the scenario where user controlled input is logged-as is.
Examples of scenarios detected:
or
Any feedback is welcome.
I hope this will help.