Skip to content

[javascript] CodeQL query to detect Log Injection #3734

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

Merged
merged 6 commits into from
Jun 25, 2020
Merged

[javascript] CodeQL query to detect Log Injection #3734

merged 6 commits into from
Jun 25, 2020

Conversation

dellalibera
Copy link
Contributor

@dellalibera dellalibera commented Jun 17, 2020

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:

const http = require('http');
const url = require('url');

const server = http.createServer((req, res) => {
    let q = url.parse(req.url, true);

    let username = q.query.username;
    console.info(`[INFO] User: ${username}`); // BAD

})

or

const http = require('http');
const url = require('url');

const logger = {
    log: console.log
}

const another_logger = console.log

const server = http.createServer((req, res) => {
    let q = url.parse(req.url, true);

    let username = q.query.username;
    logger.log('[INFO] User:', username); // BAD
    another_logger('[INFO] User:', username); // BAD
})

Any feedback is welcome.
I hope this will help.

@asgerf
Copy link
Contributor

asgerf commented Jun 18, 2020

Hi @dellalibera, thanks for the contribution! We'll take a closer look at the query next week.

@esbena esbena self-assigned this Jun 22, 2020
Copy link
Contributor

@esbena esbena left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is mostly a comment.

This last conjunct should cover the two cases above if

this = console().getAMethodCall(name)
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).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

@dellalibera dellalibera Jun 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@esbena esbena left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I will merge when the tests go green.

@dellalibera
Copy link
Contributor Author

Thanks @esbena. I am really happy that this PR is merged!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants