forked from github/codeql
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathRequestForgery.qhelp
More file actions
48 lines (40 loc) · 1.49 KB
/
RequestForgery.qhelp
File metadata and controls
48 lines (40 loc) · 1.49 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
<!DOCTYPE qhelp PUBLIC
"-//Semmle//qhelp//EN"
"qhelp.dtd">
<qhelp>
<overview>
<p>
Directly incorporating user input into an HTTP request without validating the
input can facilitate server-side request forgery (SSRF) attacks. In these
attacks, the server may be tricked into making a request to an unintended API
endpoint or resource.
If the server is connected to an internal network, attackers can bypass security
boundaries to target internal services.
Forged requests can execute unintended actions, leak data if redirected to an
external server, or compromise the server if responses are handled insecurely.
</p>
</overview>
<recommendation>
<p>
To guard against SSRF attacks, you should avoid putting user-provided input
directly into a request URL. Instead, maintain a list of authorized URLs on the
server; then choose from that list based on the input provided. Alternatively,
ensure requests constructed from user input are limited to a particular host or
a more restrictive URL prefix.
</p>
</recommendation>
<example>
<p>
The following example shows an HTTP request parameter being used directly to
form a new request without validating the input, which facilitates SSRF attacks.
It also shows how to remedy the problem by validating the user input against a
known fixed string.
</p>
<sample src="RequestForgery.rs" />
</example>
<references>
<li>
<a href="https://owasp.org/www-community/attacks/Server_Side_Request_Forgery">OWASP Server Side Request Forgery</a>.
</li>
</references>
</qhelp>