Skip to content
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: Make moduleImport() work for named imports #934

Merged
merged 3 commits into from
Feb 25, 2019

Conversation

asger-semmle
Copy link
Contributor

Fixes https://jira.semmle.com/browse/ODASA-6953, so QL like this

DataFlow::moduleImport("foo").getAPropertyRead("bar")

now matches code like this

import { bar } from "foo";

We're low on workers so I will start a full evaluation after reviews.

@asger-semmle asger-semmle requested a review from a team as a code owner February 12, 2019 17:42
@xiemaisi
Copy link

That looks refreshingly simple! It's unfortunate we still treat named imports and default imports differently (and the test failure looks like it might be related to that), but it's certainly a big step in the right direction. Modulo evaluation and remaining test failures, this lvgtm!

@asger-semmle
Copy link
Contributor Author

asger-semmle commented Feb 13, 2019

Right, I had forgotten about the ambiguous interpretation of default imports. Generalized it to default imports and checked that the test results are indeed to be expected and reasonable.

@@ -18,6 +18,7 @@
| global.js:5:22:5:35 | "also tainted" | global.js:9:13:9:22 | g(source1) |
| global.js:5:22:5:35 | "also tainted" | global.js:10:13:10:22 | g(source2) |
| nodeJsLib.js:1:15:1:23 | "tainted" | esClient.js:7:13:7:18 | nj.foo |
| nodeJsLib.js:1:15:1:23 | "tainted" | esClient.js:10:13:10:17 | njFoo |

Choose a reason for hiding this comment

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

Why do we get this flow?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For reference here's nodeJsLib.js

let source1 = "tainted";
let source2 = "tainted";

module.exports = source1;

exports.foo = source2;

The exported object itself is tainted, and we have a taint step through property reads, so there is a path step from source1 -> (exports object).foo. This PR models import {foo} from 'nodeJsLib' as a PropRead so that step is new.

It shouldn't matter in practice since module exports objects are never tainted.

@asger-semmle
Copy link
Contributor Author

Evaluation is uneventful.

@semmle-qlci semmle-qlci merged commit 014d4b9 into github:master Feb 25, 2019
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.

3 participants