|
6 | 6 | <overview>
|
7 | 7 | <p>
|
8 | 8 |
|
9 |
| - Directly incorporating user input into an HTTP request |
10 |
| - without validating the input can facilitate different kinds of request |
11 |
| - forgery attacks, where the attacker essentially controls the request. |
| 9 | + Directly incorporating user input in the URL of an outgoing HTTP request |
| 10 | + can enable a request forgery attack, in which the request is altered to |
| 11 | + target an unintended API endpoint or resource. |
12 | 12 |
|
13 |
| - If the vulnerable request is in server-side code, then security |
14 |
| - mechanisms, such as external firewalls, can be bypassed. |
| 13 | + If the server performing the request is connected to an internal network, this can give an attacker |
| 14 | + the means to bypass the network boundary and make requests against internal services. |
15 | 15 |
|
16 |
| - If the vulnerable request is in client-side code, then unsuspecting |
17 |
| - users can send malicious requests to other servers, potentially |
18 |
| - resulting in a DDOS attack. |
| 16 | + A forged request may perform an unintended action on behalf of the attacker, or cause information |
| 17 | + leak if redirected to an external server or if the request response is fed back to the user. |
| 18 | + It may also compromise the server making the request, if the request response is handled in an unsafe way. |
19 | 19 |
|
20 | 20 | </p>
|
21 | 21 | </overview>
|
22 | 22 |
|
23 | 23 | <recommendation>
|
24 | 24 |
|
25 | 25 | <p>
|
26 |
| - |
27 |
| - To guard against request forgery, it is advisable to avoid |
28 |
| - putting user input directly into a network request. If a flexible |
29 |
| - network request mechanism is required, it is recommended to maintain a |
30 |
| - list of authorized request targets and choose from that list based on |
31 |
| - the user input provided. |
32 |
| - |
| 26 | + Restrict user inputs in the URL of an outgoing request, in particular: |
| 27 | + <ul> |
| 28 | + <li> |
| 29 | + Avoid user input in the hostname of the URL. |
| 30 | + Pick the hostname from an allow-list instead of constructing it directly from user input. |
| 31 | + </li> |
| 32 | + <li> |
| 33 | + Take care when user input is part of the pathname of the URL. |
| 34 | + Restrict the input so that path traversal ("<code>../<code>") |
| 35 | + cannot be used to redirect the request to an unintended endpoint. |
| 36 | + </li> |
| 37 | + </ul> |
33 | 38 | </p>
|
34 | 39 |
|
35 | 40 | </recommendation>
|
|
39 | 44 | <p>
|
40 | 45 |
|
41 | 46 | The following example shows an HTTP request parameter
|
42 |
| - being used directly in a URL request without validating the input, |
| 47 | + being used directly in the URL of a request without validating the input, |
43 | 48 | which facilitates an SSRF attack. The request
|
44 | 49 | <code>http.get(...)</code> is vulnerable since attackers can choose
|
45 | 50 | the value of <code>target</code> to be anything they want. For
|
|
0 commit comments