This document provides an overview of server-side request forgery (SSRF) vulnerabilities. It defines SSRF as allowing an attacker to induce a server to make HTTP requests to domains of the attacker's choosing. The document covers the types of SSRF (basic and blind), impact (exposing internal systems or remote code execution), methods for finding SSRF vulnerabilities, exploitation techniques like bypassing filters, and mitigations like using whitelists instead of blacklists. Tools for finding and exploiting SSRF vulnerabilities are also listed.

1. DEEP DIVE INTO SSRF
-KATHAN PATEL

2. TOPICS TO BE COVERED,
• What is SSRF?
• Definition and Types of SSRF.
• Impact.
• How to find SSRF.
• Where to Look for SSRF.
• Manual Techniques.
• Other Methods.
• Exploitation of SSRF.
• Basic Exploitation.
• Whitelist Bypass.
• Blacklist Bypass.
• Tools to Find and Exploit SSRF.
• Mitigation.

3. WHAT IS SSRF..?
• Server-side request forgery (also known as SSRF)
is a web security vulnerability that allows an
attacker to induce the server-side application to
make HTTP requests to an arbitrary domain of
the attacker's choosing.
• In a nutshell, an attacker can make a server to
request to another server it can be internal or
external.
• SSRF vulnerabilities occur when an attacker has
full or partial control of the request sent by the
web application. A common example is when an
attacker can control the third-party service URL
to which the web application makes a request.

4. TYPES OF SSRF.
2 - Blind SSRF
Blind SSRF occurs when you never get any information about a target service from the initial request.
Typically, an attacker will provide a URL, but data from this URL will never be returned to the attacker. To
confirm a vulnerability in this case, an attacker must use Burp Collaborator, DNSbin, or a similar tool. These
tools can confirm that a server is vulnerable by forcing it to make DNS or HTTP requests to an attacker-
controlled server. Blind SSRF is typically easy to validate, but difficult to exploit.
1 - Basic SSRF
Basic or Direct SSRF is typically the most critical issue. In these scenarios, data from an arbitrary URI can be
fetched from an internal service and will be returned to the attacker.

5. IMPACT
• A successful SSRF attack can often result in unauthorized actions or access to data within the
organization, either in the vulnerable application itself or on other back-end systems that
the application can communicate with. In some situations, the SSRF vulnerability might allow
an attacker to perform arbitrary command execution.
• An SSRF exploit that causes connections to external third-party systems might result in
malicious onward attacks that appear to originate from the organization hosting the
vulnerable application, leading to potential legal liabilities and reputational damage.
1. Expose internal / firewalled systems
2. Service discovery and port scanning
3. Extract EC2 configuration files
4. Remote code execution
• List of Impact, not limited….
So why is this a vulnerability?

6. How To Find SSRF…?

7. WHERE TO LOOK FOR SSRF.
• Vickie Li (@vickieli7) analysis of 76 publicly disclosed reports out of 412 reports on hackerone.
• As you can see, most SSRFs in these reports occur in file upload, proxy or webhook services. This is
consistent with most documentation about SSRF vulnerabilities out there, and these features should
be the first places you go to look for SSRF vulnerabilities.
• Another interesting thing to note is the variety of file types that could be used to cause an SSRF. Any
file that could contain a URL that would be parsed by the application can potentially trigger the
vulnerability. Most of the files uploaded as POCs in these reports were SVGs, JPGs, XMLs and JSONs.

8. HOW TO LOOK FOR SSRF.
• Most common and effective method using Proxy Tools
1. Spider the web
2. Search for parameter like “url=“ or easy way “=http” in
requests.
3. Try your SSRF payload check response
• Understand how data flows from the target find endpoints which try
to make an connection to somewhere.
• Methods you can try to find this endpoints.
• See if the server is returning a response
that reveals any information about the
internal service. Does the response,
contain service banners or HTML content
of internal pages?
Error: cannot upload image: SSH-2.0-OpenSSH_7.2p2
Ubuntu-4ubuntu2.4
https://public.example.com/upload_profile_from
_url.php?url=127.0.0.1:22

9. HOW TO LOOK FOR BLIND-SSRF.
• In the case of blind SSRF, try to determine if there is a difference in server behavior between commonly open
and closed ports (ports 80 and 443 are commonly open ports, while port 11 is not). Look out especially for
differences in response time and HTTP response codes.
• For example, the following request results in an HTTP status code of 200 (Status code for “OK”).
https://public.example.com/webhook?url=127.0.0.1:80
• While the following request results in an HTTP status code of 500 (Status code for “Internal Server Error”).
https://public.example.com/webhook?url=127.0.0.1:11
• We can confirm that SSRF exists and deduce that port 80 is open, and port 11 is closed on the server.

10. OTHER METHOD TO FIND ENDPOINT TO TEST SSRF.
• Lets go way back in times when servers where using some params to connect to its internal
service or external service.
• So the other method is using URLs from AlienVault's Open Threat Exchange, the
Wayback Machine, and Common Crawl and find some get based ssrf.
• I found this methods when I was surfing twitter it was posted by Nick || hunt4p1zza (@ngkogkos)
all credits to him.
• Link to the tool to complete first 3 steps https://github.com/KathanP19/gaussrf

11. EXPLOITATION OF SSRF.
• A variety of techniques can be used to exploit SSRF vulnerabilities. These range from simply
providing parameters in the correct spots to exploiting the way that a server processes certain
data. It is not always obvious that an SSRF vulnerability is present, and sometimes exploitation
requires taking advantage of existing workflows in ways the developer did not intend.
• Some techniques of which you can take advantage are Server-side Rendering, SVG Images, Open graph tags,
PDF rendering, Proxy, XXE, vendor Software..
• Basic Exploitation You can Try First When You Find SSRF.
1. Access to an apache functionality of the server (unexposed):
http://example.test/ssrf.php?url=http://localhost/server-status
2. Access to a web service of the server (unexposed):
http://example.test/ssrf.php?url=http://localhost:8080
3. Access to a file of the server (LFI: Local File Inclusion):
http://example.test/ssrf.php?url=file:///etc/passwd
4. Access to a web server of the internal network:
http://example.test/ssrf.php?url=http://10.0.0.15/
5. Access aws metadata:
http://example.test/ssrf.php?url=http://169.254.169.254/latest/meta-
data/

12. BYPASS FILTERS
Error. Requests to this address are not allowed. Please try
again
• Companies have caught onto the risk of SSRF attacks. As a result, most have implemented some
form of SSRF protection on their web applications. There are two main types of SSRF protection
mechanisms out there: blacklists and whitelists.
• Whitelists are generally harder to bypass because they are by default, stricter than blacklists. But it is
possible if there is an open redirect vulnerability within the whitelisted domains.
If you could find an open redirect, you can request a whitelisted URL that redirects to an internal URL.
Whitelists Bypass.
• If the whitelist is not correctly implemented (eg. via poorly designed regex), it could also be bypassed by
using making a subdomain or directory as the whitelisted domain name (eg. victim.com.attacker.com or
attacker.com/victim.com).
http://example.com/ssrf.php?url=https://google.com - Fails To Fetch
http://example.com/ssrf.php?url=http://abc.com/?redirect=https://google.com - Successfully
Fetch

13. Blacklists Bypass.
1. Converting IP to hexadecimal :-
For Example - converting http://192.168.0.1 to doted hex – http://c0.a8.00.01 and dot less hex http://0xc0a80001
2. Converting IP to Decimal :-
For Example - http://0177.0.0.1/ = http://127.0.0.1 or http://2130706433/ = http://127.0.0.1
3. Converting IP to Octal :-
For Example - converting http://192.168.0.1 to doted octal http://0300.0250.0000.0001 and dot less
http://030052000001
4. Using wildcard DNS :-
For Example - 10.0.0.1.xip.io resolves to 10.0.0.1 - There are many site provide wildcard dns like xip.io , nip.io ,
ip6.name , localdomain.pw
5. Using enclosed alphanumerics :-
For Example - http://ⓔⓧⓐⓜⓟⓛⓔ.ⓒⓞⓜ = example.com

14. Tools to Find and Exploit SSRF.
SSRFmap - https://github.com/swisskyrepo/SSRFmap - Automatic SSRF fuzzer and
exploitation tool
Gopherus - https://github.com/tarunkant/Gopherus - This tool generates gopher link for
exploiting SSRF and gaining RCE in various servers
See-SURF - https://github.com/In3tinct/See-SURF - Python based scanner to find potential
SSRF parameters
SSRF Sheriff - https://github.com/teknogeek/ssrf-sheriff - A simple SSRF-testing sheriff
written in Go

15. MITIGATION.
• There is no universal protection against SSRF attacks, however there are a few things to have in mind:
• A blacklist is not a good protection because with so many different protocols, schemes, encodings and
super complex URI syntax, bypasses will most certainly occur. Because of this, a whitelist is a better
approach.
• When developing REST API’s, it is better to accept other HTTP verbs than POST and GET which will
make it harder for a SSRF vulnerability to make correct requests to the API service. If a SSRF
vulnerability is only able to make internal GET requests, it won’t be able to speak with the API. It is
also important to validate both the request and response to internal services.
• Services such as Kibana, Redis, Elasticsearch, MongoDB and Memcached do not per default require
authentication, and adding that to those services may make it harder to exploit a SSRF vulnerability.
.

16. Where You Go To Learn More.
https://github.com/jdonsec/AllThingsSSRF
• The collection of writeups, cheatsheets, videos, books related to SSRF
in one single location

17. THANK YOU