Server-side request forgery, or SSRF, is a vulnerability that allows an attacker to use a vulnerable server to make HTTP requests on the attacker’s behalf. This is similar to CSRF as both the vulnerabilities perform HTTP requests without the victim acknowledging it.

With SSRF: the victim would be the vulnerable server.

With CSRF: the victim would be a user’s browser.

As by OWASP- in SSRF Prevention Cheat Sheet:

• SSRF is not limited to the HTTP protocol, despite the fact that in general the first request leverages it, yet the second request is performed by the application itself, and thus it could be using different protocols (e.g. FTP, SMB, SMTP, etc.) and schemes (e.g. file://, phar://, gopher://, data://, dict://, etc.). The protocol/scheme usage is highly dependent on the application's requirements.
• If the application is vulnerable to XML eXternal Entity (XXE) injection then it can be exploited to perform an SSRF attack.

Server-side redirection vulnerabilities appear when an application takes user-controllable input and incorporates it into a URL that it reclaims using a backend HTTP request. The user-supplied input may comprise the entire URL that is retrieved, or the application may perform some processing on it. This could lead to:

• Information Disclosure where an attacker can deceive the server into disclosing information about itself and provide access to sensitive internal files.
• XSS if the attacker can trick the server to administer a remote HTML file with Javascript in it.

SSRF is an attack vector that abuses an application to interact with the: internal network, external network, and the machine itself.

Example:

Here, the vulnerable application makes a request to URL: “safedomain.safesite.com/account/edit.aspx” (having IP: 192.10.10.1) according to the application logic.

POST /account/index HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: safesite.com
Content-Length: 1234
show=default&url=safedomain.safesite.com/account/edit.aspx

An attacker could modify the requested URL to: “192.10.10.2:22” which requests for an alternative or internal resource, located behind a firewall, and is restricted from external access.

POST /account/index HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: safesite.com
Content-Length: 1234
show=default&url=192.10.10.2:22

The response received back includes the banner from the requested SSH service:

HTTP/1.1 200 OK
Connection: close
SSH-2.0-OpenSSH_4.2Protocol mismatch

An attacker can exploit server-side HTTP redirection bugs to persuade the vulnerable application to behave as an open HTTP proxy to perform various further attacks:

1. Use the proxy to attack third-party systems on the Internet. The malicious traffic appears to the target to originate from the server on which the vulnerable application is running.
2. Use the proxy to connect to arbitrary hosts on the organization’s internal network, thereby reaching targets that cannot be accessed directly from the Internet.
3. Use the proxy to connect back to other services running on the application server itself, circumventing firewall restrictions and potentially exploiting trust relationships to bypass authentication.
4. The proxy functionality could be used to perform attacks such as cross-site scripting by causing the application to include an attacker-controlled content within its responses.

1. Identify any request parameters that appear to contain hostnames, IP addresses, or full URLs.
2. For each parameter, modify its value to specify an alternative resource, similar to the one being requested
3. Check if that resource appears in the server’s response.
4. Define a URL targeting a server on the Internet that you regulate, and monitor for incoming connections from the application you are testing.
5. If no incoming connection is received, monitor the time taken for the application to respond.
6. If there is a delay, the application’s back-end requests may be timing out due to network restrictions on outbound connections.
7. If a successful connection with an arbitrary URL is established, try to perform the following:

a. Ascertain whether the port number can be specified. For example: http://site.com:22
b. If yes, try to port-scan the internal network by using a tool such as Burp Intruder to connect to a range of IP addresses and ports in sequence.
c. Try to connect with other services on the loopback address of the vulnerable server.
d. Try to load a web page that you control into the application’s response to perform a cross-site scripting(XSS) attack.

Bypassing restrictions using Special characters:

There could be further restrictions in redirecting the application internally, externally, or accessing any resources. You can try to bypass such restrictions, using special characters to modify the requested resource.

?url=http://safesite.com&site.com
?url=http://////////////site.com/
?url=http://site@com/account/edit.aspx
?url=http://site.com/account/edit.aspx
?url=http://safesite.com?.site.com
?url=http://safesite.com#.site.com
?url=http://safesite.com\.site.com/domain
?url=https://ⓈⒾⓉⒺ.ⓒⓞⓜ = site.com
?url=https://192.10.10.3/
?url=https://192.10.10.2?.192.10.10.3/
?url=https://192.10.10.2#.192.10.10.3/
?url=https://192.10.10.2\.192.10.10.3/
?url=http://127.0.0.1/status/
?url=http://localhost:8000/status/

Bypassing restrictions using HTTP Redirections:

You can try implementing a similar snippet in the request, if successfully processed by the server, will redirect you to the destination:

?url=http://site.com/domain.php
<?php
header(‘Location: http://127.0.0.1:8080/status');
?>

Ciao!