Update SQL_Injection_Prevention_Cheat_Sheet.md #1228
Conversation
Major cleanup
more lint cleanup
lint cleanup
more delinting
de-emphasizing ESAPI
more delinting
|
Thank you to Robert Thornton for this work! |
|
|
||
| This article provides a set of simple techniques for preventing SQL Injection vulnerabilities by avoiding these two problems. These techniques can be used with practically any kind of programming language with any type of database. There are other types of databases, like XML databases, which can have similar problems (e.g., XPath and XQuery injection) and these techniques can be used to protect them as well. | ||
| Attackers can use SQL injection on an application if it has dynamic database queries that use string concatenation and user supplied input. To avoid SQL injection flaws, developers need to: |
There was a problem hiding this comment.
Feel that "What is a SQL Injection attack" should not be followed with - Attacker can use SQL injection . My proposal below
SQL injection is an attack in which malicious code is inserted into strings that are later passed to the database server. The malicious code is parsed and executed by the database server which could cause destruction or leakage of data.
|
|
||
| **Primary Defenses:** |
There was a problem hiding this comment.
Defense Principles for SQL injection:
- Stop writing dynamic queries with string concatenation and
- Prevent malicious SQL input from being included in executed queries.
There was a problem hiding this comment.
In the SQL example below - #1201 you can see SQL injection is possible even without dynamic queries .
The wrapper libraries internally escape the inputs provided.
There was a problem hiding this comment.
The example in 1201 points to a dynamic query in a stored procedure if I am looking at the right code. I cant accept this PR as is, its a big change to a CS that we just made big updates on. Can you perhaps drop this PR and maybe give me several small PR's?
|
|
||
| When we say "implemented safely," the stored procedure does not include any unsafe dynamic SQL generation. Developers do not usually generate dynamic SQL inside stored procedures. However, it can be done, but should be avoided. | ||
|
|
||
| If it can't be avoided, the stored procedure must use input validation or proper escaping as described in this article to make sure that all user supplied input to the stored procedure can't be used to inject SQL code into the dynamically generated query. Auditors should always look for uses of `sp_execute`, `execute` or `exec` within SQL Server stored procedures. Similar audit guidelines are necessary for similar functions for other vendors. |
| - Hibernate - use `createQuery()` with bind variables (called named parameters in Hibernate) | ||
| - SQLite - use `sqlite3_prepare()` to create a [statement object](http://www.sqlite.org/c3ref/stmt.html) | ||
| If database queries use this coding style, the database will always distinguish between code and data, regardless of what user input is supplied. | ||
| Also, prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker. |
There was a problem hiding this comment.
By escaping malicious user input provided
There was a problem hiding this comment.
Parameterized queries do not escape under the hood, its about the ordering of query plan construction.
Major cleanup
Thank you for submitting a Pull Request (PR) to the Cheat Sheet Series.
Please make sure that for your contribution:
If your PR is related to an issue, please finish your PR text with the following line:
This PR covers issue #.
Thank you again for your contribution 馃槂