You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This pull request introduces a Go-based static analysis checker designed to detect potential SQL injection vulnerabilities in JavaScript code.
Injection is the 3rd most critical web security risk in the OWASP Top 10. Among 94% of tested applications, it had a maximum incidence rate of 19% and an average of 3%. SQL injection remains a key pentesting target, making proper query sanitization essential to prevent unauthorized access and data loss.
Detection Logic
The scanner works in two phases, during the first phase, it goes through and creates a map of all known variables in a file. This allows it to track where each variable is assigned a value, this is needed later on for detecting SQL injection vulnerabilities.
During the second phase, the scanner finds all function calls that are used to execute raw SQL queries. A variable named vulnerableFunctions is maintained for this purpose and it includes calls from Supported ORM's. After this, it follows the below flow:
It inspects the first argument of the SQL-executing function.
If the argument is a variable, it looks up its definition in the map created during the first phase.
If the argument (or variable) involves string concatenation (with a variable) or template literals with interpolation, it is flagged as vulnerable.
A recursive call is used to track chained concatenations (+) in order to detect indirect vulnerabilities.
Supported ORMs
The checker currently covers five widely used ORMs in the JavaScript ecosystem:
Sequelize -> .query()
TypeORM -> .query()
Prisma -> $queryRawUnsafe() and $executeRawUnsafe()
Knex.js -> .raw()
Objection.js -> .raw()
node-postgres -> .query() [Not an ORM but a popular interface nonetheless]
These ORMs are extensively used in projects, ensuring broad vulnerability detection.
Note
I'm still new to Go and the initial version of the checker was written by Claude. However, I did personally go through and verify each line and make modifications to improve the overall flow and reduce redundancies. I believe the logic is sound, but please let me know if any changes are required.
I have also tested the checker using the new Go-based rules introduced in #123. Though i believe there is a bug with it (which is why the action fails)
Hi @hrideshmg — thanks for your contribution! We've made some changes to our Go interface for writing checkers, so this PR will need to be updated. Please see the reference here and this guide.
Hi @hrideshmg — thanks for your contribution! We've made some changes to our Go interface for writing checkers, so this PR will need to be updated. Please see the reference here and this guide.
I've adapted the PR to use the new interface, please take a look. Thanks!
Hi @hrideshmg — thanks for your contribution! We've made some changes to our Go interface for writing checkers, so this PR will need to be updated. Please see the reference here and this guide.
I've adapted the PR to use the new interface, please take a look. Thanks!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
hrideshmg
force-pushed
the
node_injection
branch
from
Summary
This pull request introduces a Go-based static analysis checker designed to detect potential SQL injection vulnerabilities in JavaScript code.
Injection is the 3rd most critical web security risk in the OWASP Top 10. Among 94% of tested applications, it had a maximum incidence rate of 19% and an average of 3%. SQL injection remains a key pentesting target, making proper query sanitization essential to prevent unauthorized access and data loss.
Detection Logic
The scanner works in two phases, during the first phase, it goes through and creates a map of all known variables in a file. This allows it to track where each variable is assigned a value, this is needed later on for detecting SQL injection vulnerabilities.
During the second phase, the scanner finds all function calls that are used to execute raw SQL queries. A variable named
vulnerableFunctionsis maintained for this purpose and it includes calls from Supported ORM's. After this, it follows the below flow:Supported ORMs
The checker currently covers five widely used ORMs in the JavaScript ecosystem:
.query().query()$queryRawUnsafe()and$executeRawUnsafe().raw().raw().query()[Not an ORM but a popular interface nonetheless]These ORMs are extensively used in projects, ensuring broad vulnerability detection.
Note
I'm still new to Go and the initial version of the checker was written by Claude. However, I did personally go through and verify each line and make modifications to improve the overall flow and reduce redundancies. I believe the logic is sound, but please let me know if any changes are required.
I have also tested the checker using the new Go-based rules introduced in #123. Though i believe there is a bug with it (which is why the action fails)