Skip to content

Commit 91c6415

Browse files
committed
JS: Rephrase the qhelp for SSRF query
1 parent cf66d01 commit 91c6415

File tree

1 file changed

+21
-16
lines changed

1 file changed

+21
-16
lines changed

javascript/ql/src/Security/CWE-918/RequestForgery.qhelp

Lines changed: 21 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -6,30 +6,35 @@
66
<overview>
77
<p>
88

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.
1212

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.
1515

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.
1919

2020
</p>
2121
</overview>
2222

2323
<recommendation>
2424

2525
<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>
3338
</p>
3439

3540
</recommendation>
@@ -39,7 +44,7 @@
3944
<p>
4045

4146
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,
4348
which facilitates an SSRF attack. The request
4449
<code>http.get(...)</code> is vulnerable since attackers can choose
4550
the value of <code>target</code> to be anything they want. For

0 commit comments

Comments
 (0)