JS: Rephrase the qhelp for SSRF query

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

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