In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL, which the code running on the server will read or submit data. By carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP-enabled databases or perform POST requests towards internal services that are not intended to be exposed.
The target application may have functionality for importing data from a URL, publishing data to a URL or otherwise reading data from a URL that can be tampered with. The attacker modifies the calls to this functionality by supplying a completely different URL or by manipulating how URLs are built (like path traversal, etc.).
When the manipulated request goes to the server, the server-side code picks up the manipulated URL and tries to read data to the manipulated URL. By selecting target URLs, the attacker may be able to read data from services that are not directly exposed on the internet:
Cloud server meta-data — Cloud services such as AWS provide a REST interface on http://169.254.169.254/ where important configuration and sometimes even authentication keys can be extracted
Database HTTP interfaces — NoSQL database such as MongoDB provide REST interfaces on HTTP ports. If the database is expected to only be available to internally, authentication may be disabled and the attacker can extract data internal REST interfaces
Files — The attacker may be able to read files using file:// URIs. The attacker may also use this functionality to import untrusted data into code that expects to only read data from trusted sources, and as such circumvent input validation.
What is its impact?
A malicious actor can retrieve the content of arbitrary files on the system, which leads to sensitive information exposure(passwords, source code, confidential data, etc.).
Sensitive Data Exposure
Unauthenticated Requests
Port Scans or Cross Site Port Attack (XSPA)
Protocol Smuggling
Key Points To Test SSRF Vulnerability :
Always make sure that you are making request to back end server on the behalf of public server not from the browser.
To fetch the data from server also try http://localhost/xyz/ with the http://127.0.0.1/xyz.
Server may have the firewall protection always try to bypass the firewall if possible.
Make sure that request is coming from server not from your local host.
Where to look for :
uri=
logout_redirect_uri=
url=
page=
proxy=
fwd=
forward=
u=
data=
page=
url=
ret=
r2=
img=
u
return
r
URL
next
redirect
redirectBack
AuthState
referer
redir
l
aspxerrorpath
image_path
ActionCodeURL
return_url 0
link
q
location
ReturnUrl
uri
referrer
returnUrl
forward
file
rb
end_display
urlact
from
goto
path
redirect_url
old
pathlocation
successTarget
returnURL
urlsito
newurl
Url
back
retour
odkazujuca
r_link
cur_url
H_name
ref
topic
resource
returnTo
home 0.2%
node 0.2%
sUrl 0.2%
href 0.2%
linkurl 0.2%
returnto 0.2%
redirecturl 0.2%
SL 0.2%
st 0.2%
errorUrl 0.2%
media 0.2%
destination 0.2%
targeturl 0.2%
return_to 0.2%
cancel_url 0.2%
doc 0.2%
GO 0.2%
ReturnTo 0.2%
anything 0.2%
FileName 0.2%
logoutRedirectURL 0.2%
list 0.2%
startUrl 0.2%
service 0.2%
redirect_to 0.2%
end_url 0.2%
_next 0.2%
noSuchEntryRedirect 0.2%
context 0.2%
returnurl 0.2%
ref_url 0.2%
1-SSRF attacks against the server itself
In an SSRF attack against the server itself, the attacker induces the application to make an HTTP request back to the server that is hosting the application, via its loopback network interface. This will typically involve supplying a URL with a hostname like 127.0.0.1 (a reserved IP address that points to the loopback adapter) or localhost.