@@ -20,7 +20,13 @@ or prepared statements.
20
20
<p >
21
21
For NoSQL queries, make use of an operator like MongoDB's <code >$eq</code >
22
22
to ensure that untrusted data is interpreted as a literal value and not as
23
- a query object.
23
+ a query object. Alternatively, check that the untrusted data is a literal
24
+ value and not a query object before using it in a query.
25
+ </p >
26
+ <p >
27
+ For SQL queries, use query parameters or prepared statements to
28
+ embed untrusted data into the query string, or use a library like
29
+ <code >sqlstring</code > to escape untrusted data.
24
30
</p >
25
31
</recommendation >
26
32
@@ -32,31 +38,47 @@ an HTTP request handler in a web application, whose parameter
32
38
</p >
33
39
34
40
<p >
35
- The handler constructs two copies of the same SQL query involving
36
- user input taken from the request object, once unsafely using
37
- string concatenation, and once safely using query parameters.
41
+ The handler constructs constructs an SQL query string from user input
42
+ and executes it as a database query using the <code >pg</code > library.
43
+ THe user input may contain quote characters, so this code is vulnerable
44
+ to a SQL injection attack.
38
45
</p >
39
46
40
- <p >
41
- In the first case, the query string <code >query1</code > is built by
42
- directly concatenating a user-supplied request parameter with some
43
- string literals. The parameter may include quote characters, so this
44
- code is vulnerable to a SQL injection attack.
45
- </p >
47
+ <sample src =" examples/SqlInjection.js" />
46
48
47
49
<p >
48
- In the second case, the parameter is embedded into the query string
49
- < code >query2</ code > using query parameters . In this example, we use
50
+ To fix this vulnerability, we can use query parameters to embed the
51
+ user input into the query string . In this example, we use
50
52
the API offered by the <code >pg</code > Postgres database connector
51
53
library, but other libraries offer similar features. This version is
52
54
immune to injection attacks.
53
55
</p >
54
56
55
- <sample src =" examples/SqlInjection.js" />
57
+ <sample src =" examples/SqlInjectionFix.js" />
58
+ </example >
59
+
60
+ <example >
61
+ <p >
62
+ In the following example an express handler attempts to delete
63
+ a single document from a MongoDB collection. The document to be
64
+ deleted is identified by its <code >_id</code > field, which is
65
+ constructed from user input. The user input may contain a query
66
+ object, so this code is vulnerable to a NoSQL injection attack.
67
+ </p >
68
+
69
+ <sample src =" examples/NoSqlInjection.js" />
70
+
71
+ <p >
72
+ To fix this vulnerability, we can check that the user input is a
73
+ literal value and not a query object before using it in a query.
74
+ </p >
75
+
76
+ <sample src =" examples/NoSqlInjectionFix.js" />
56
77
</example >
57
78
58
79
<references >
59
80
<li >Wikipedia: <a href =" https://en.wikipedia.org/wiki/SQL_injection" >SQL injection</a >.</li >
60
81
<li >MongoDB: <a href =" https://docs.mongodb.com/manual/reference/operator/query/eq" >$eq operator</a >.</li >
82
+ <li >OWASP: <a href =" https://owasp.org/www-pdf-archive/GOD16-NOSQL.pdf" >NoSQL injection</a >.</li >
61
83
</references >
62
84
</qhelp >
0 commit comments