This document provides an overview of server-side request forgery (SSRF) vulnerabilities, including what SSRF is, its impact, common attacks, bypassing filters, and mitigations. SSRF allows an attacker to induce the application to make requests to internal or external servers from the server side, bypassing access controls. This can enable attacks on the server itself or other backend systems and escalate privileges. The document discusses techniques for exploiting trust relationships and bypassing blacklists/whitelists to perform SSRF attacks. It also covers blind SSRF and ways to detect them using out-of-band techniques. Mitigations include avoiding user input that can trigger server requests, sanitizing input, whitelist

1. Server side Request
Forgery
Exploit the trust relationship
Twitter- @trouble1_raunak

2. Myself- Raunak Pamar
 Learning web security
 Whitebox / blackbox pentester
 Bug hunter
 Speaker
 Student

3. AGENDA
 What is SSRF?
 Impact Of SSRF?
 Attacks Against Server Itself
 Why do applications behave in this way?
 Attacks against other back-end system
 Bypassing filters
 White listing
 Black listing
 Blind SSRF

4. What is SSRF?
 It's a server side attack where an
attacker can create a HTTP request
from the server to internal servers
or external server.
 In simple language SSRF can create
request to itself (http://localhost/)
or other servers
(http://attackerserver.com)

5. Impact Of SSRF (Exploit the trust relationships)
 Breaking relationship
 SSRF attacks often exploit trust relationships to escalate an attack
from the vulnerable application
 These relationships might exit in relation to server itself to other
back-end sever systems within the same organization
 A successful SSRF attack can often result in
 Unauthorized actions or access to data within the organization.
 Or other back-end systems that the application can Communicate
 Sometimes even arbitrary command execution.

6. Attacks Against Server Itself
 In SSRF attacker induces the
application to make an HTTP request
back to the server that is hosting the
application, via its loopback network
interface.
 URL with a hostname like 127.0.0.1(a
reserved ip address) or localhost
(a commonly used name for same
adapter)

7. Attacks Against Server Itself
Example:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://stock.weliketoshop.net:8080/product/stock/check?productId=6&storeId=1
Attacker Comes in
stockApi=http://localhost/admin

8. Attacks Against Server Itself
 Now the attacker could just fetch for /admin page but
administrative functionality is ordinarily accessible only to
suitable users only.
 But here the request is made from the server side so the
access controls are bypassed.
 And application grants full access, because the request appears
to originate from trusted location.

9. Attacks Against Server Itself
URL schemas
 file:// - Allow attacker to fetch files
 http://example.com/ssrf.php?url=file:///etc/passwd
 dict:// - Used to refer to definitions or word lists
 http://example.com/ssrf.php?dict://evil.com:1337/
 tftp:// - allows a client to get a file from or put a file
 http://example.com/ssrf.php?url=sftp://evil.com:1337/

10. Why do applications behave in this way?
 Why do applications trust requests that come from the local
machine?
1. The access control check might be implemented in a different
component.
2. The application might allow administrative access without
logging.
3. The administrative interface might be listening on a different
port number.
 These kind of trust relationships, where requests originating from the
local machine are handled differently than ordinary requests, is
often what makes SSRF into a critical vulnerability.

11. Attacks against other back-end system
 Another type of trust relationship that often arises with server-
side request forgery is where the application server is able to
interact with other back-end systems that are not directly
reachable by users.
 eg, suppose there is an administrative interface at the back-end
URL https://192.168.0.68/admin.
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://192.168.0.68/admin

12. Bypassing filters – Black Listing
 Some applications block input containing hostnames
like 127.0.0.1 and localhost.
1. Using an alternative IP representation of 127.0.0.1, such as
2130706433, 017700000001, 127.1
http://ⓔⓧⓐⓜⓟⓛⓔ.ⓒⓞⓜ = example.com
2. Registering your own domain name that resolves to 127.0.0.1
You can use spoofed.burpcollaborator.net for this purpose.
3. Obfuscating blocked strings using URL encoding or case variation.
All bypassing techniques

13. Bypassing filters – White Listing
 Some applications only allow input that matches, begins with, or
contains, a whitelist of permitted values.
 https://127.0.0.1@evil-host
 https://evil-host#127.0.0.1
 https://127.0.0.1.evil-host
 You can use combinations of these techniques together.
All bypassing techniques

14. Where to look for SSRF?
 Webhooks:
 Look for services that makes HHTP request when certain events
happen.
 PDF Generators:
 Try <iframe>, <imp> or <script> elements or CSS url()
 Link expansions:
 Try looking for features that get you a web page for link
 File uploads:
 Try sending URL and see if it downloads the Content

15. Blind SSRF
 What is blind SSRF?
 When response from the back-end request is not returned in the
application's front-end response
 What is the impact of blind SSRF vulnerabilities?
 Impact is often lower than fully informed SSRF. They cannot be
trivially exploited to retrieve sensitive data from back-end
systems but in some situation they can be exploited to achieve
full RCE

16. Blind SSRF
 How to find blind SSRF vulnerabilities?
 Using out-of-band techniques
• This involves attempting to trigger an HTTP request to an external system that you control,
and monitoring for network interactions with that system
 The easiest and most effective way to do out-of-band techniques is using burp
Collaborator
• It will create unique domain name.
• Monitor for any interaction with those domains
• If Request is observed coming from the application then it is vulnerable

17. Blind SSRF
 USE http://pingb.in/ to verify SSRF

18. Demo

19. MITIGATION
Avoid user input that
can make requests on
behalf of the server.
1
Sanitize and filter user
input.
2
Use whitelist of
allowed domains and
protocols
3

20. Where you can practise and learn SSRF?
o https://portswigger.net/web-
security/ssrf

21. Reference Links
 https://medium.com/bugbountywriteup/server-side-request-forgery-ssrf-testing-b9dfe57cca35
 https://www.shorebreaksecurity.com/blog/ssrfs-up-real-world-server-side-request-forgery-ssrf/
 https://hackerone.com/reports/115748
 https://www.kernelpicnic.net/2017/05/29/Pivoting-from-blind-SSRF-to-RCE-with-Hashicorp-Consul.html
 https://geleta.eu/2019/my-first-ssrf-using-dns-rebinfing/
 https://medium.com/@androgaming1912/gain-adfly-smtp-access-with-ssrf-via-gopher-protocol-
26a26d0ec2cb
 https://medium.com/@armaanpathan/pdfreacter-ssrf-to-root-level-local-file-read-which-led-to-rce-
eb460ffb3129
 https://www.youtube.com/watch?v=D1S-G8rJrEk

22. Contact me
trouble1_raunak

23. Q & A

24. Thank you