JSSecurity SQL Injection Analysis

Hi,

we have found several cases of possible SQL Injections in our JavaScript application by manual testing, but none of these were caught by our SonarCloud security rules.
Sadly I cannot share the source code, just describe that we use koa.js with a controller and data-layer (repository) pattern with Sequelize queries.

We have enabled the following rules for detecting SQL injections for Javascript apps:

  • Rule jssecurity:S3649
  • Rule javascript:S2077 (non-taint analysis)

Here is a snippet of our scanner log output for the jssecuritysensor:
Scanner: SonarScanner 5.0.1.3006

build 26-Jan-2024 09:42:22 INFO: Sensor JsSecuritySensor [security]
build 26-Jan-2024 09:42:22 INFO: Enabled taint analysis rules: S6096, S5144, S6350, S5147, S5146, S2076, S2631, S5131, S3649, S2083, S5696, S5334, S5883, S6105, S6287
build 26-Jan-2024 09:42:22 INFO: Load type hierarchy and UCFGs: Starting
build 26-Jan-2024 09:42:22 INFO: Load type hierarchy: Starting
build 26-Jan-2024 09:42:22 INFO: Reading type hierarchy from: /opt/nodeapp/.scannerwork/ucfg2/js
build 26-Jan-2024 09:42:22 INFO: Read 0 type definitions
build 26-Jan-2024 09:42:22 INFO: Load type hierarchy: Time spent was 00:00:00.000
build 26-Jan-2024 09:42:22 INFO: Load UCFGs: Starting
build 26-Jan-2024 09:42:22 INFO: Load UCFGs: Time spent was 00:00:00.000
build 26-Jan-2024 09:42:22 INFO: Load type hierarchy and UCFGs: Time spent was 00:00:00.000
build 26-Jan-2024 09:42:22 INFO: No UCFGs have been included for analysis.
build 26-Jan-2024 09:42:22 INFO: js security sensor: Time spent was 00:00:00.000
build 26-Jan-2024 09:42:22 INFO: Sensor JsSecuritySensor [security] (done) | time=2ms

We did not find any info on how the analysis identifies user input flows and what UCFGs are.
Do we need to add any other configuration for the taint analysis to work?
Is the security engine custom configuration available for Javascript and SonarCloud?

If you need more information we can try providing it.

Thanks,
M

Hi M,

Can you provide a compact reproducer? Unfortunately, there’s not a lot to go on here, and thus little to help us understand the situation.

 
Ann

Hi Ann,

In the meantime we got the SecuritySensor working, but it still does not find any vulnerabilities.

18:15:48.584 INFO: Analyzing 2835 UCFGs to detect vulnerabilities.

I will write up a short koa-based example with an sql injection that is similar to the example in the rule.
Thanks!

M

1 Like

Hi Ann,

here is the compact example.
A nodejs app with two routes GET /hello and GET /hello/s
The latter contains the sql injection using a query parameter which can be set to ‘foo' OR 1=1 --’.

I am also attaching the debug logs from the JsSecuritySensor

KoaApp examle:
koaSQLInjection.zip (12.4 KB)
Debug Logs:
security-debug.log (46.3 KB)

If there are any questions, I am happy to help.

Thank you very much,
M

2 Likes

Hi,

Could you provide the full code of your compact example? It’s not clear to me that what you’ve provided so far is enough to reproduce.

 
Thx,
Ann

Hi,

the code I provided in the zip is a very small backend server and is almost complete except:

  • the node_modules that can be installed via npm ci (node 18)
  • the setup of a postgres db with a table called SequelizeMeta and one string column called name
  • configuration of sequelize to connect to the db (in hello.controller.js)
  • sonar-project.properties which are only contain the basic default properties like sources=.

I was just under the impression that you need code to debug the analysis part, but if you want to make the app run, you can follow these steps (the Readme.md is not complete, im sorry):

  • install node 18
  • install packages with npm ci
  • setup a postgres db, create a table SequelizeMeta with a name column and add some rows
  • configure dbName, user, pass and the other options in new Sequelize( in hello.controller.js.
  • run node app.js
  • use curl or postman to run:
    • GET localhost:3000/hello or GET localhost:3000/hello/s?name=foo
    • trigger the sql injection via GET localhost:3000/hello/s?name=foo' OR 1=1 --

I can also supply the .scannerwork files containing the ucfg2/js files if you need them.

Thanks,
M

1 Like

Hi,

Sorry, I didn’t open the zip because I misunderstood what it was. :flushed:

I’ll flag this for the language experts.

 
Ann

Ah, no problem!

Thanks for your help!

Hello @pazeltma, thanks for reaching out with an in-depth description of the situation and what you are looking for.

As you correctly discovered, something was going wrong on your first try, but you managed to find a solution. The line you mentioned in your second post is definitely a good sign that we do analyze your code. “UCFGs” are an intermediate representation used internally to perform the analysis, it is not required to understand exactly what it is about.

To come back to the initial question, the reason we do not detect the vulnerabilities is mainly due to the fact that we do not support KoaApp. In addition, it is unfortunately not possible to provide a “custom configuration”.

We are aware that the situation has some limitations for the detection of taint vulnerabilities on JS, and we are currently investigating how we can improve.

This also means that, while we take note of your interest for Koa, and will definitely keep with the sample you provided, we don’t plan to work on it in the near future.

Thanks again for your interest in the topic.
I hope this clarifies the situation.

Best,
Quentin

Thanks Quentin for this insightful feedback.

While its unfortunate that koaApp won’t be supported in the near future, I understand that supporting many frameworks is not scalable.

Maybe the customization could help us and is added to sonar cloud in the future.

Thanks again for your insights

Best M

2 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.