<!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

different kinds of request forgery attacks, where the attacker essentially controls the request.

If the vulnerable request is in server-side code, then security mechanisms, such as external

firewalls, can be bypassed.

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.

</p>

</overview>

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

</p>

</recommendation>

<example>

<p>

The following example shows an HTTP request parameter being used directly in a URL 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

instance, the attacker can choose <code>"internal.example.com/#"</code> as the target, causing the

URL used in the request to be <code>"https://internal.example.com/#.example.com/data"</code>.

</p>

<p>

A request to <code>https://internal.example.com</code> may be problematic if that server is not

meant to be directly accessible from the attacker's machine.

</p>

<sample src="RequestForgery.go"/>

<p>

One way to remedy the problem is to use the user input to select a known fixed string before

performing the request:

</p>

<sample src="RequestForgeryGood.go"/>

</example>

<references>

<li>OWASP: <a href="https://www.owasp.org/index.php/Server_Side_Request_Forgery">SSRF</a></li>

</references>

</qhelp>