Python: Add SSRF qhelp

I included examples of both types in the qhelp of both queries, to
provide context of what each of them actually are.

Author: RasmusWL

python/ql/src/Security/CWE-918/FullServerSideRequestForgery.qhelp

@@ -0,0 +1,11 @@
+<!DOCTYPE qhelp PUBLIC "-//Semmle//qhelp//EN" "qhelp.dtd">
+<qhelp>
+
+  <overview>
+    <include src="ServerSideRequestForgery-start.inc.qhelp" />
+
+    <!-- query specific -->
+    <p>This query covers full SSRF, to find partial SSRF use the <code>py/partial-ssrf</code> query.</p>
+  </overview>
+  <include src="ServerSideRequestForgery-end.inc.qhelp" />
+</qhelp>

python/ql/src/Security/CWE-918/PartialServerSideRequestForgery.qhelp

@@ -0,0 +1,11 @@
+<!DOCTYPE qhelp PUBLIC "-//Semmle//qhelp//EN" "qhelp.dtd">
+<qhelp>
+
+  <overview>
+    <include src="ServerSideRequestForgery-start.inc.qhelp" />
+
+    <!-- query specific -->
+    <p>This query covers partial SSRF, to find full SSRF use the <code>py/full-ssrf</code> query.</p>
+  </overview>
+  <include src="ServerSideRequestForgery-end.inc.qhelp" />
+</qhelp>

python/ql/src/Security/CWE-918/ServerSideRequestForgery-end.inc.qhelp

@@ -0,0 +1,47 @@
+<!DOCTYPE qhelp PUBLIC
+  "-//Semmle//qhelp//EN"
+  "qhelp.dtd">
+<qhelp>
+  <recommendation>
+
+    <p>To guard against SSRF attacks you should avoid putting user-provided input directly
+      into a request URL. Instead, either maintain a list of authorized URLs on the server and choose
+      from that list based on the input provided, or perform proper validation of the input.
+    </p>
+
+  </recommendation>
+  <example>
+
+    <p>The following example shows code vulnerable to a full SSRF attack, because it
+    uses untrusted input (HTTP request parameter) directly to construct a URL. By using
+    <code>evil.com#</code> as the <code>target</code> value, the requested URL will be
+    <code>https://evil.com#.example.com/data/</code>. It also shows how to remedy the
+    problem by using the user input select a known fixed string.
+    </p>
+
+    <sample src="examples/ServerSideRequestForgery_full.py" />
+
+  </example>
+  <example>
+
+    <p>
+      The following example shows code vulnerable to a partial SSRF attack, because it
+      uses untrusted input (HTTP request parameter) directly to construct a URL. By
+      using <code>../transfer-funds-to/123?amount=456</code> as the
+      <code>user_id</code> value, the requested URL will be
+      <code>https://api.example.com/transfer-funds-to/123?amount=456</code>. It also
+      shows how to remedy the problem by validating the input.
+    </p>
+
+    <sample src="examples/ServerSideRequestForgery_partial.py" />
+
+  </example>
+  <references>
+    <li>
+      <a href="https://owasp.org/www-community/attacks/Server_Side_Request_Forgery">OWASP SSRF article</a>
+    </li>
+    <li>
+      <a href="https://portswigger.net/web-security/ssrf">PortSwigger SSRF article</a>
+    </li>
+  </references>
+</qhelp>

python/ql/src/Security/CWE-918/ServerSideRequestForgery-start.inc.qhelp

@@ -0,0 +1,31 @@
+<!DOCTYPE qhelp PUBLIC
+  "-//Semmle//qhelp//EN"
+  "qhelp.dtd">
+<qhelp>
+<fragment>
+    <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
+      request may be changed, directed at a different server, or via a different
+      protocol. This can allow the attacker to obtain sensitive information or perform
+      actions with escalated privilege.
+    </p>
+
+    <p>
+      We make a distinctions between how much of the URL an attacker can control:
+    </p>
+
+    <ul>
+      <li><b>Full SSRF</b>: where the full URL can be controlled.</li>
+      <li><b>Partial SSRF</b>: where only part of the URL can be controlled, such as the
+        path component of a URL to a hardcoded domain.</li>
+    </ul>
+
+    <p></p>
+
+    <p>
+    Partial control of a URL is often much harder to exploit. Therefore we have created a
+    separate query for each of these.
+    </p>
+
+</fragment>
+</qhelp>

python/ql/src/Security/CWE-918/examples/ServerSideRequestForgery_full.py

@@ -0,0 +1,15 @@
+import requests
+from flask import Flask, request
+
+app = Flask(__name__)
+
+@app.route("/full_ssrf")
+def full_ssrf():
+    target = request.args["target"]
+
+    # BAD: user has full control of URL
+    resp = request.get("https://" + target + ".example.com/data/")
+
+    # GOOD: `subdomain` is controlled by the server.
+    subdomain = "europe" if target == "EU" else "world"
+    resp = request.get("https://" + subdomain + ".example.com/data/")

python/ql/src/Security/CWE-918/examples/ServerSideRequestForgery_partial.py

@@ -0,0 +1,15 @@
+import requests
+from flask import Flask, request
+
+app = Flask(__name__)
+
+@app.route("/partial_ssrf")
+def partial_ssrf():
+    user_id = request.args["user_id"]
+
+    # BAD: user can fully control the path component of the URL
+    resp = requests.get("https://api.example.com/user_info/" + user_id)
+
+    if user_id.isalnum():
+        # GOOD: user_id is restricted to be alpha-numeric, and cannot alter path component of URL
+        resp = requests.get("https://api.example.com/user_info/" + user_id)