We have free labs for this vulnerability coming soon. Currently it is only available on our members web application BARKER.
Tip from @zseano
When wanting to find SSRF I will always look for any sort of developer portal which may contain something such as web hook testing. These areas let you naturally input an URL so filtering will usually exist. Filters that can be bypassed..!
Learning about Server Side Request Forgery (SSRF)
SSRF also known as server side request forgery is an all time favourite for bug hunters. Relatively easy to find and just as easy to exploit. A server side request forgery bug will allow an attacker to make a request on behalf of the victim (the website we're testing) and because this request comes internally this means it is usually trusted and requests will go through. This then opens the window for an attacker to extract something such as AWS keys.
Honestly, just google 'SSRF aws' and you will see lots of disclosed issues which can give you a very clear idea on how these are pulled off. A really great report is this one by honoki: https://hackerone.com/reports/508459
Finding SSRF bugs
What's infront of you?
When hunting for SSRF bugs I first begin primarily with looking for features that will take an URL parameter already. This can mean something such as an API console or webhook and typically these features are found on the developer portal (
example.com/developer). The reason for wanting to find & test these features first is because they are designed to take an URL parameter and do something. This means that filering should exist around this feature to prevent malicious requests and you can spend time trying to understand how the filter works and learn to bypass it.
Examples of SSRF found in Webhooks
Sometimes when browsing a website you will even see certain parameter names such as
url. Anytime you see either an URL or local endpoint in a request, attempt to make a request to a domain you control. If it replies with a response then even better and you can start attempting to retrieve information.
As well as features and parameter names infront of you, what about the headers you send? Some websites will send a query to urls in the Referrer header to check where a user came from as well as querying
X-Forwarded-For values (such as an DNS request).
If you've got a victims website querying your domain for an answer then you may be able to execute commands behind their firewall. A really great write-up on DNS rebinding can be found here by Daniel Miessler. There is no point in me re-inventing the wheel & explaining it when he does an amazing job. https://danielmiessler.com/blog/dns-rebinding-explained/
Using open redirects
A lot of researchers will hold onto open url redirects bug for when they discover a potential SSRF bug. This is because sometimes when you have a feature which takes an URL parameter it may block any external requests (such as trying to query
example.com). However with an open url redirect on their domain, you can supply this in the URL parameter and hope that their server follows the redirect & lands you a valid SSRF bug.
SSRF via XXE
If you haven't already check out the XXE guide. Since XXE allows you to upload custom XML which will be executed server-side, this can create a window for you to achieve SSRF and read internal files via making internal requests.
Exploiting SSRF bugs
When trying to test for SSRF bugs your aim is to prove you can successfully access & read internal content, however sometimes reading isn't always possible and we get what is typically called a blind SSRF. This means you can send a request successfully to an internal subdomain/IP but you are unable to read the response. With these type of bugs to prove the impact I recommend trying to send a request to common images for popular software such as Jira and Atlassian. If you can prove you can access these internal areas then it should be enough to show impact of the bug.
As well as trying to access certain images used by certain software, attempting to visit a random port vs a common port such as
:80 can help prove that the connections are successful.
Bypass via redirect
If all your attempts to acesss internal content fail then what about testing how they handle redirects from an url you control (rather than needing to use an open url redirect). If you simply setup XAMPP & NGROK then you can run PHP locally which is accessible by anyone on the internet (be careful & make sure to not leave it running!). The code below will simply redirect to
<?php header("Location: 127.0.0.1"); ?>
Now simply visiting your ngrok address will redirect to
127.0.0.1. Perhaps the site you are testing are only checking the first url value (your url in this case), but no checks are done after it redirects. The logic behind the developer is: If this url is
127.0.0.1 then block. But the code see's our url and allows it through, but follows the redirect & outputs internal content. Bypassed!
Some sites block ngrok addresses so you may need to get a domain or look for alternatives.