|
6 | 6 | <overview> |
7 | 7 | <p> |
8 | 8 | Dynamically computing object property names from untrusted input |
9 | | - may have multiple undesired consequences. For example, |
10 | | - if the property access is used as part of a write, an |
11 | | - attacker may overwrite vital properties of objects, such as |
12 | | - <code>__proto__</code>. This attack is known as <i>prototype |
13 | | - pollution attack</i> and may serve as a vehicle for denial-of-service |
14 | | - attacks. A similar attack vector, is to replace the |
15 | | - <code>toString</code> property of an object with a primitive. |
16 | | - Whenever <code>toString</code> is then called on that object, either |
17 | | - explicitly or implicitly as part of a type coercion, an exception |
| 9 | + may have multiple undesired consequences. For example, |
| 10 | + if the property access is used as part of a write, an |
| 11 | + attacker may overwrite vital properties of objects, such as |
| 12 | + <code>__proto__</code>. This attack is known as <i>prototype |
| 13 | + pollution attack</i> and may serve as a vehicle for denial-of-service |
| 14 | + attacks. A similar attack vector, is to replace the |
| 15 | + <code>toString</code> property of an object with a primitive. |
| 16 | + Whenever <code>toString</code> is then called on that object, either |
| 17 | + explicitly or implicitly as part of a type coercion, an exception |
18 | 18 | will be raised. |
19 | 19 | </p> |
20 | 20 |
|
21 | 21 | <p> |
22 | | - Moreover, if the dynamically computed property is |
23 | | - used as part of a method call, the attacker may trigger |
24 | | - the execution of unwanted functions such as the |
25 | | - <code>Function</code> constructor or the |
26 | | - <code>eval</code> method, which can be used |
27 | | - for code injection. |
28 | | - </p> |
29 | | - |
30 | | - <p> |
31 | | - Additionally, if the name of an HTTP header is user-controlled, |
32 | | - an attacker may exploit this to overwrite security-critical headers |
33 | | - such as <code>Access-Control-Allow-Origin</code> or |
| 22 | + Moreover, if the name of an HTTP header is user-controlled, |
| 23 | + an attacker may exploit this to overwrite security-critical headers |
| 24 | + such as <code>Access-Control-Allow-Origin</code> or |
34 | 25 | <code>Content-Security-Policy</code>. |
35 | 26 | </p> |
36 | 27 | </overview> |
37 | 28 |
|
38 | 29 | <recommendation> |
39 | 30 | <p> |
40 | 31 | The most common case in which prototype pollution vulnerabilities arise |
41 | | - is when JavaScript objects are used for implementing map data |
42 | | - structures. This case should be avoided whenever possible by using the |
43 | | - ECMAScript 2015 <code>Map</code> instead. When this is not possible, an |
44 | | - alternative fix is to prepend untrusted input with a marker character |
45 | | - such as <code>$</code>, before using it in properties accesses. In this way, |
46 | | - the attacker does not have access to built-in properties which do not |
47 | | - start with the chosen character. |
| 32 | + is when JavaScript objects are used for implementing map data |
| 33 | + structures. This case should be avoided whenever possible by using the |
| 34 | + ECMAScript 2015 <code>Map</code> instead. When this is not possible, an |
| 35 | + alternative fix is to prepend untrusted input with a marker character |
| 36 | + such as <code>$</code>, before using it in properties accesses. In this way, |
| 37 | + the attacker does not have access to built-in properties which do not |
| 38 | + start with the chosen character. |
48 | 39 | </p> |
49 | 40 | <p> |
50 | | - When using user input as part of header or method names, a sanitization |
51 | | - step should be performed on the input to ensure that the name does not |
52 | | - clash with existing property and header names such as |
53 | | - <code>__proto__</code> or <code>Content-Security-Policy</code>. |
| 41 | + When using user input as part of a header name, a sanitization |
| 42 | + step should be performed on the input to ensure that the name does not |
| 43 | + clash with existing header names such as |
| 44 | + <code>Content-Security-Policy</code>. |
54 | 45 | </p> |
55 | 46 | </recommendation> |
56 | 47 |
|
57 | 48 | <example> |
58 | 49 | <p> |
59 | | - In the example below, the dynamically computed property |
60 | | - <code>prop</code> is accessed on <code>myObj</code> using a |
| 50 | + In the example below, the dynamically computed property |
| 51 | + <code>prop</code> is accessed on <code>myObj</code> using a |
61 | 52 | user-controlled value. |
62 | 53 | </p> |
63 | 54 |
|
64 | 55 | <sample src="examples/RemotePropertyInjection.js"/> |
65 | 56 |
|
66 | 57 | <p> |
67 | | - This is not secure since an attacker may exploit this code to |
| 58 | + This is not secure since an attacker may exploit this code to |
68 | 59 | overwrite the property <code>__proto__</code> with an empty function. |
69 | | - If this happens, the concatenation in the <code>console.log</code> |
70 | | - argument will fail with a confusing message such as |
| 60 | + If this happens, the concatenation in the <code>console.log</code> |
| 61 | + argument will fail with a confusing message such as |
71 | 62 | "Function.prototype.toString is not generic". If the application does |
72 | 63 | not properly handle this error, this scenario may result in a serious |
73 | | - denial-of-service attack. The fix is to prepend the user-controlled |
74 | | - string with a marker character such as <code>$</code> which will |
75 | | - prevent arbitrary property names from being overwritten. |
| 64 | + denial-of-service attack. The fix is to prepend the user-controlled |
| 65 | + string with a marker character such as <code>$</code> which will |
| 66 | + prevent arbitrary property names from being overwritten. |
76 | 67 | </p> |
77 | 68 |
|
78 | 69 | <sample src="examples/RemotePropertyInjection_fixed.js"/> |
79 | 70 | </example> |
80 | 71 |
|
81 | 72 | <references> |
82 | | - <li>Prototype pollution attacks: |
| 73 | + <li>Prototype pollution attacks: |
83 | 74 | <a href="https://github.com/electron/electron/pull/9287">electron</a>, |
84 | 75 | <a href="https://hackerone.com/reports/310443">lodash</a>, |
85 | 76 | <a href="https://nodesecurity.io/advisories/566">hoek</a>. |
86 | 77 | </li> |
87 | | - <li> Penetration testing report: |
| 78 | + <li> Penetration testing report: |
88 | 79 | <a href="http://seclists.org/pen-test/2009/Mar/67"> |
89 | 80 | header name injection attack</a> |
90 | 81 | </li> |
91 | | - <li> npm blog post: |
| 82 | + <li> npm blog post: |
92 | 83 | <a href="https://blog.liftsecurity.io/2015/01/14/the-dangers-of-square-bracket-notation#lift-security"> |
93 | 84 | dangers of square bracket notation</a> |
94 | 85 | </li> |
|
0 commit comments