Improve iast mongodb nosql detection removing some false positives

[uurien]

What does this PR do?

• Does not detect a vulnerability when the tainted string is detected in a known safe mongodb query property, like $eq or $in
• Tainted value should be the same received from the query parameter or request body, if it has been modified, it is not vulnerable, because query syntax can't be modified.
• Fix some tests that weren't not executed before.

Motivation

Reduce the false positives detected for mongodb databases.

Additional Notes

APPSEC-56443

[github-actions]

Overall package size

Self size: 9.24 MB
Deduped: 101.54 MB
No deduping: 102.06 MB

Dependency sizes

| name | version | self size | total size | |------|---------|-----------|------------| | @datadog/libdatadog | 0.5.0 | 29.83 MB | 29.83 MB | | @datadog/native-appsec | 8.5.1 | 19.26 MB | 19.27 MB | | @datadog/native-iast-taint-tracking | 3.3.0 | 13.77 MB | 13.78 MB | | @datadog/pprof | 5.6.0 | 9.79 MB | 10.16 MB | | @opentelemetry/core | 1.30.1 | 908.66 kB | 7.16 MB | | protobufjs | 7.4.0 | 2.77 MB | 5.42 MB | | @datadog/wasm-js-rewriter | 3.1.0 | 2.37 MB | 2.52 MB | | @datadog/native-metrics | 3.1.0 | 1.06 MB | 1.46 MB | | @opentelemetry/api | 1.8.0 | 1.21 MB | 1.21 MB | | import-in-the-middle | 1.13.1 | 117.64 kB | 839.26 kB | | source-map | 0.7.4 | 226 kB | 226 kB | | opentracing | 0.14.7 | 194.81 kB | 194.81 kB | | lru-cache | 7.18.3 | 133.92 kB | 133.92 kB | | pprof-format | 2.1.0 | 111.69 kB | 111.69 kB | | @datadog/sketches-js | 2.1.1 | 109.9 kB | 109.9 kB | | lodash.sortby | 4.7.0 | 75.76 kB | 75.76 kB | | ignore | 5.3.2 | 53.63 kB | 53.63 kB | | istanbul-lib-coverage | 3.2.0 | 29.34 kB | 29.34 kB | | rfdc | 1.4.1 | 27.15 kB | 27.15 kB | | @isaacs/ttlcache | 1.4.1 | 25.2 kB | 25.2 kB | | tlhunter-sorted-set | 0.1.0 | 24.94 kB | 24.94 kB | | dc-polyfill | 0.1.6 | 24.56 kB | 24.56 kB | | shell-quote | 1.8.2 | 23.54 kB | 23.54 kB | | limiter | 1.1.5 | 23.17 kB | 23.17 kB | | retry | 0.13.1 | 18.85 kB | 18.85 kB | | semifies | 1.0.0 | 15.84 kB | 15.84 kB | | jest-docblock | 29.7.0 | 8.99 kB | 12.76 kB | | crypto-randomuuid | 1.0.0 | 11.18 kB | 11.18 kB | | ttl-set | 1.0.0 | 4.61 kB | 9.69 kB | | path-to-regexp | 0.1.12 | 6.6 kB | 6.6 kB | | koalas | 1.0.2 | 6.47 kB | 6.47 kB | | module-details-from-path | 1.0.3 | 4.47 kB | 4.47 kB |

_{🤖 This report was automatically generated by heaviest-objects-in-the-universe}

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.25%. Comparing base (21e0408) to head (c0bd49a).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5408      +/-   ##
==========================================
- Coverage   79.28%   79.25%   -0.04%     
==========================================
  Files         513      512       -1     
  Lines       23220    23161      -59     
==========================================
- Hits        18411    18356      -55     
+ Misses       4809     4805       -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[datadog-datadog-prod-us1]

Datadog Report

Branch report: ugaitz/reduce-mongodb-false-positive
Commit report: 54e37de
Test service: dd-trace-js-integration-tests

✅ 0 Failed, 929 Passed, 0 Skipped, 15m 45.35s Total Time

[pr-commenter]

Benchmarks

Benchmark execution time: 2025-04-03 15:31:02

Comparing candidate commit c0bd49a in PR branch ugaitz/reduce-mongodb-false-positive with baseline commit 21e0408 in branch master.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 947 metrics, 16 unstable metrics.

[CarlesDD]

There is no test (or I cannot find it) for this new check. We should add it.

[BridgeAR]

While a set seems the obvious thing to use here to limit the number of lookups, it's likely faster to use an array. The reason is that the default lookup will normally not reach a depth of 10. There is probably a break even point somewhere in-between and it might be interesting to check for that.

Allocating a set and creating the hash is just more expensive than allocating an array and iterating over very few entries.

This will however only work in case we also release the values when moving up. Do we actually have to match all former entries or only only ones that are available in the current leaf?

[uurien]

You mean using [].includes(target) instead of Set.has(target)? Yeah, it should work also, I dunno if the difference will be noticed, but I think that we can change it...

This will however only work in case we also release the values when moving up. Do we actually have to match all former entries or only only ones that are available in the current leaf?

I'm not sure if I understand, the goal of this is to prevent circular dependencies, but also to prevent checking the same twice, with objects like:

{
  a: objectA,
  b: {
      a: objectA
  }
}

We don't need to iterate again in b.a: objectA

[CarlesDD]

LGTM