|
1 |
| -<!DOCTYPE qhelp PUBLIC "-//Semmle//qhelp//EN" "qhelp.dtd"> |
| 1 | +<!DOCTYPE qhelp PUBLIC |
| 2 | + "-//Semmle//qhelp//EN" |
| 3 | + "qhelp.dtd"> |
2 | 4 | <qhelp>
|
3 | 5 |
|
| 6 | + |
4 | 7 | <overview>
|
5 |
| -<p> |
6 |
| -Directly incorporating user input into a URL redirect request without validating the input |
| 8 | +<p>Directly incorporating user input into a URL redirect request without validating the input |
7 | 9 | can facilitate phishing attacks. In these attacks, unsuspecting users can be redirected to a
|
8 | 10 | malicious site that looks very similar to the real site they intend to visit, but which is
|
9 |
| -controlled by the attacker. |
10 |
| -</p> |
11 |
| -</overview> |
| 11 | +controlled by the attacker.</p> |
12 | 12 |
|
| 13 | +</overview> |
13 | 14 | <recommendation>
|
14 |
| -<p> |
15 |
| -To guard against untrusted URL redirection, it is advisable to avoid putting user input |
| 15 | + |
| 16 | +<p>To guard against untrusted URL redirection, it is advisable to avoid putting user input |
16 | 17 | directly into a redirect URL. Instead, maintain a list of authorized
|
17 |
| -redirects on the server; then choose from that list based on the user input provided. |
| 18 | +redirects on the server; then choose from that list based on the user input provided.</p> |
| 19 | +<p> |
| 20 | +If this is not possible, then the user input should be validated in some other way, |
| 21 | +for example, by verifying that the target URL is on the same host as the current page. |
18 | 22 | </p>
|
19 | 23 | </recommendation>
|
20 | 24 |
|
| 25 | + |
21 | 26 | <example>
|
22 | 27 | <p>
|
23 | 28 | The following example shows an HTTP request parameter being used directly in a URL redirect
|
24 | 29 | without validating the input, which facilitates phishing attacks:
|
25 | 30 | </p>
|
26 | 31 |
|
27 |
| -<sample src="examples/redirect_bad.rb"/> |
| 32 | +<sample src="examples/url_redirect.rb"/> |
28 | 33 |
|
29 | 34 | <p>
|
30 |
| -One way to remedy the problem is to validate the user input against a known fixed string |
| 35 | +One way to remedy the problem is to validate the user input against a set of known fixed strings |
31 | 36 | before doing the redirection:
|
32 | 37 | </p>
|
33 | 38 |
|
34 |
| -<sample src="examples/redirect_good.rb"/> |
| 39 | +<sample src="examples/url_redirect_good.rb"/> |
| 40 | + |
| 41 | +<p> |
| 42 | +Alternatively, we can check that the target URL does not redirect to a different host |
| 43 | +by checking that the URL is either relative or on a known good host: |
| 44 | +</p> |
| 45 | + |
| 46 | +<sample src="examples/url_redirect_domain.rb"/> |
| 47 | + |
| 48 | +<p> |
| 49 | +Note that as written, the above code will allow redirects to URLs on <code>example.com</code>, |
| 50 | +which is harmless but perhaps not intended. You can substitute your own domain (if known) for |
| 51 | +<code>example.com</code> to prevent this. |
| 52 | +</p> |
| 53 | + |
35 | 54 | </example>
|
36 | 55 |
|
37 | 56 | <references>
|
38 |
| -<li>OWASP: <a href="https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html"> |
39 |
| - XSS Unvalidated Redirects and Forwards Cheat Sheet</a>.</li> |
40 |
| -<li>Rails Guides: <a href="https://guides.rubyonrails.org/security.html#redirection-and-files"> |
41 |
| - Redirection and Files</a>.</li> |
42 |
| -</references> |
43 | 57 |
|
| 58 | +<li> |
| 59 | +OWASP: |
| 60 | +<a href="https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html"> |
| 61 | +Unvalidated Redirects and Forwards Cheat Sheet</a>. |
| 62 | +</li> |
| 63 | +<li> |
| 64 | +Rails Guides: <a href="https://guides.rubyonrails.org/security.html#redirection-and-files">Redirection and Files</a>. |
| 65 | +</li> |
| 66 | + |
| 67 | +</references> |
44 | 68 | </qhelp>
|
0 commit comments