-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
Update: SQL_Injection_Prevention_Cheat_Sheet - SQL Injection #1201
Comments
Yes you are correct. Do you want to create a PR to address this? |
@szh I will be happy to work on the PR |
@rsrinivasanhome do you need any help on that? |
Later during further analysis I have out while performing Let me know your thoughts. |
I just submitted a major re-write of the SQL Injection cheatsheet where we heavily discouraged manual escaping. Can you review that please? |
I would be able to review . You can point me to the pull request |
https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
What is missing or needs to be updated?
(https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html#defense-option-4-escaping-all-user-supplied-input)
Defense Option1 and Defense Option 2 are not enough to prevent SQL injection . In addition to option 1 or option 2 option 4 is required.
Defense Option 4: Escaping All User-Supplied Input[¶]
This technique should only be used as a last resort, when none of the above are feasible. Input validation is probably a better choice as this methodology is frail compared to other defenses and we cannot guarantee it will prevent all SQL Injections in all situations.
How should this be resolved?
Defense Option 4: Escaping All User-Supplied Input¶
This technique must be used along with Option 1 and Option 2 . Input validation is probably a better choice as this methodology is frail compared to other defenses and we cannot guarantee it will prevent all SQL Injections in all situations however it may not always be practically feasible as end user(s) often require special characters
We need to explicitly mention Option 4 is also required as part of Option 1 and Option 2.
We have followed the usage of parametrized queries or sql stored procedure and still found application open to SQL injection related attacks. Here is an example how
SQL Server sample - We had also seen a similar issue with postgress also
In the sample above the sql version gets stored in column test can be retrieved .
The text was updated successfully, but these errors were encountered: