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
Copy file name to clipboardexpand all lines: files/en-us/learn_web_development/extensions/server-side/first_steps/website_security/index.md
+9-11
Original file line number
Diff line number
Diff line change
@@ -69,7 +69,7 @@ SQL injection types include Error-based SQL injection, SQL injection based on bo
69
69
70
70
This vulnerability is present if user input that is passed to an underlying SQL statement can change the meaning of the statement. For example, the following code is intended to list all users with a particular name (`userName`) that has been supplied from an HTML form:
71
71
72
-
```sql
72
+
```python
73
73
statement ="SELECT * FROM users WHERE name = '"+ userName +"';"
74
74
```
75
75
@@ -81,21 +81,19 @@ SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WH
81
81
82
82
The modified statement creates a valid SQL statement that deletes the `users` table and selects all data from the `userinfo` table (which reveals the information of every user). This works because the first part of the injected text (`a';`) completes the original statement.
83
83
84
-
To avoid this sort of attack, you must ensure that any user data that is passed to an SQL query cannot change the nature of the query. One way to do this is to [escape](https://en.wikipedia.org/wiki/Escape_character) all the characters in the user input that have a special meaning in SQL.
85
-
86
-
> [!NOTE]
87
-
> The SQL statement treats the **'** character as the beginning and end of a string literal. By putting a backslash in front of this character (**\\'**), we escape the symbol, and tell SQL to instead treat it as a character (just a part of the string).
88
-
89
-
In the following statement, we escape the **'** character. The SQL will now interpret the name as the whole string in bold (which is a very odd name indeed, but not harmful).
84
+
To avoid such attacks, the best practice is to use parameterized queries (prepared statements). This approach ensures that the user input is treated as a string of data rather than executable SQL, so that the user cannot abuse special SQL syntax characters to generate unintended SQL statements. The following is an example:
90
85
91
86
```sql
92
-
SELECT*FROM users WHERE name ='a\';DROP TABLE users; SELECT * FROM userinfo WHERE \'t\' = \'t';
87
+
SELECT*FROM users WHERE name =? AND password = ?;
93
88
```
94
89
95
-
Web frameworks will often take care of the character escaping for you. Django, for example, ensures that any user-data passed to querysets (model queries) is escaped.
90
+
When executing the above query, for example, in Python, we pass the `name` and `password` as parameters, as shown below.
96
91
97
-
> [!NOTE]
98
-
> This section draws heavily on the information in [Wikipedia here](https://en.wikipedia.org/wiki/SQL_injection).
92
+
```python
93
+
cursor.execute("SELECT * FROM users WHERE name = ? AND password = ?", (name, password))
94
+
```
95
+
96
+
Libraries often provide well-abstracted APIs that handle SQL injection protection for the developer, such as Django's models. You can avoid SQL injection by using encapsulated APIs rather than directly writing raw SQL.
0 commit comments