-
Notifications
You must be signed in to change notification settings - Fork 8
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
[Lab] Test after deploy ENG-766 #155
Conversation
✨ Amplify has finished checking this pull requestSecurity Pipeline
Vulnerabilities Detected
Note To ignore a finding, append |
|
||
// vuln-code-snippet start unionSqlInjectionChallenge dbSchemaChallenge | ||
module.exports = function searchProducts() { | ||
return (req: Request, res: Response, next: NextFunction) => { | ||
let criteria: any = req.query.q === 'undefined' ? '' : req.query.q ?? '' | ||
criteria = (criteria.length <= 200) ? criteria : criteria.substring(0, 200) | ||
console.log(criteria) | ||
models.sequelize.query(`SELECT * FROM Products WHERE ((name LIKE '%${criteria}%' OR description LIKE '%${criteria}%') AND deletedAt IS NULL) ORDER BY name`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Warning
Amplify has been notified that this line contains a vulnerability 🕷️.
Vulnerability: CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Impact: HIGH
Code Fix: ✅
Amplify Security has prepared an automated remediation for review. Click here to review and commit the code fix.
models.sequelize.query(`SELECT * FROM Products WHERE ((name LIKE '%${criteria}%' OR description LIKE '%${criteria}%') AND deletedAt IS NULL) ORDER BY name`) | |
models.sequelize.query(`SELECT * FROM Products WHERE ((name LIKE :criteria OR description LIKE :criteria) AND deletedAt IS NULL) ORDER BY name`, { | |
replacements: { criteria: `%${criteria}%` } | |
}) |
The code change addresses the SQL Injection vulnerability by implementing parameterized queries instead of directly interpolating user input into the SQL command. Here's how this change mitigates the risk:
Explanation of the Vulnerability
SQL Injection occurs when an attacker is able to manipulate a SQL query by injecting malicious SQL code through user inputs. In the original code, the criteria
variable is directly concatenated into the SQL query string. This means that if a user inputs a specially crafted string, they could alter the intended SQL command, potentially allowing them to access or manipulate the database in unauthorized ways.
How the Code Change Fixes the Vulnerability
-
Use of Parameterized Queries: The modified code uses a parameterized query by employing the
replacements
option. Instead of directly embedding the user input into the SQL string, it uses a placeholder (:criteria
) which is then safely replaced with the actual value. This ensures that the input is treated strictly as data, not executable code. -
Input Sanitization: By using the
replacements
object, the framework automatically handles the necessary escaping of special characters in the user input. This means that even if a user tries to inject SQL code through thecriteria
, it will be treated as a string literal rather than executable SQL. -
Limiting Input Length: The original code already had a safeguard to limit the length of the
criteria
to 200 characters. This is a good practice as it reduces the risk of overly long inputs that could be used in an attack.
Conclusion
By switching to a parameterized query, the code change effectively neutralizes the risk of SQL Injection. This approach not only enhances security but also improves the maintainability of the code by separating SQL logic from data handling. For more information on preventing SQL Injection, you can refer to the OWASP SQL Injection Prevention Cheat Sheet.
Note
Have a question or concern about this vulnerability fix? Get an answer within seconds by asking our Concierge 🤖 with @amplify-security
.
i.e. @amplify-security are there known performance issues resulting from this fix?
|
||
// vuln-code-snippet start unionSqlInjectionChallenge dbSchemaChallenge | ||
module.exports = function searchProducts() { | ||
return (req: Request, res: Response, next: NextFunction) => { | ||
let criteria: any = req.query.q === 'undefined' ? '' : req.query.q ?? '' | ||
criteria = (criteria.length <= 200) ? criteria : criteria.substring(0, 200) | ||
console.log(criteria) | ||
models.sequelize.query(`SELECT * FROM Products WHERE ((name LIKE '%${criteria}%' OR description LIKE '%${criteria}%') AND deletedAt IS NULL) ORDER BY name`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Warning
Amplify has been notified that this line contains a vulnerability 🕷️.
Vulnerability: CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Impact: MEDIUM
Code Fix: ✅
Amplify Security has prepared an automated remediation for review. Click here to review and commit the code fix.
models.sequelize.query(`SELECT * FROM Products WHERE ((name LIKE '%${criteria}%' OR description LIKE '%${criteria}%') AND deletedAt IS NULL) ORDER BY name`) | |
models.sequelize.query(`SELECT * FROM Products WHERE ((name LIKE :criteria OR description LIKE :criteria) AND deletedAt IS NULL) ORDER BY name`, { | |
replacements: { criteria: `%${criteria}%` } | |
}) |
The code change addresses the SQL Injection vulnerability by implementing parameterized queries, which are a best practice for safely executing SQL commands. Here's how the change improves security:
Explanation of the Fix
-
Parameterized Queries: The original code directly interpolated user input (
criteria
) into the SQL query string. This practice can lead to SQL Injection, where an attacker can manipulate the input to execute arbitrary SQL commands. The modified code uses a parameterized query, which separates the SQL logic from the data. By using placeholders (in this case,:criteria
), the database engine can safely handle the input. -
Input Sanitization: The change also includes a
replacements
object that safely binds the user input to the query. This means that the input is treated strictly as data, not executable code. The database will handle the input in a way that prevents any malicious SQL from being executed. -
Length Limitation: Although the original code already limited the length of the
criteria
to 200 characters, the new implementation ensures that even if an attacker tries to input a long string, it will be truncated before being processed. This adds an additional layer of defense against potential attacks.
Benefits
- Prevention of SQL Injection: By using parameterized queries, the risk of SQL Injection is significantly reduced, as the input cannot alter the structure of the SQL command.
- Improved Code Readability and Maintenance: Parameterized queries often lead to cleaner and more maintainable code, as the SQL logic is clearly separated from the data being processed.
Documentation
For more information on preventing SQL Injection and using parameterized queries, you can refer to the following resources:
By adopting these practices, the code not only becomes more secure but also aligns with industry standards for database interactions.
Note
Have a question or concern about this vulnerability fix? Get an answer within seconds by asking our Concierge 🤖 with @amplify-security
.
i.e. @amplify-security are there known performance issues resulting from this fix?
Description
A clear and concise summary of the change and which issue (if any) it fixes. Should also include relevant motivation and context.
Resolved or fixed issue:
Affirmation