This step simply implies using the web app THOROUGHLY and finding a place where you input a URL and the server fetches it.
Ex: profile pic from URL, URL Redirects, etc.
The best tip I can give you for this step is: CLICK EVERY SINGLE BUTTON YOU SEE
If your target has Documentations, such as API Docs, make sure you go through them.
Not only for SSRF, but for other bugs such as IDORs, BAC, XSS, etc.
If you can't find any URL redirects/inputs, you can always FUZZ for parameters (use ffuf โก๏ธ github.com/ffuf/ffuf)
2๏ธโฃ Testing
Before trying to exploit SSRF, you might want to get a feel of how the target handles redirects and URL fetches.
Try to ping your Burp collaborator (if you're using Pro) or webhook.site
The point is to see how/if the server actually accesses the URL.
Another alternative to Burp Collab is hosting your own redirect locally using XAMPP (apachefriends.org) & NGrok (ngrok.com) to help with understanding how they handle redirects.
XAMPP lets you run PHP code and NGrok provides you with a public IP address.
Don't spend too much time on what I said above.
Pull up the below list and throw some SSRF payloads, however, don't just spray and pray without knowing what you're doing.
You may encounter a custom WAF/Filter , and you'll need to get creative.
If every SSRF payload fails, your last resort could be going for Open Redirects, although beware most programs have it set as Out Of Scope, so check out your target's policy first.
That's a wrap!
If you enjoyed this thread:
1. Follow me @shrekysec for more of these 2. RT the tweet below to share this thread with your audience
The ๐๐๐ซ๐ข๐ฉ๐ญ๐ข๐ง๐ part indicates, obviously, scripting, so we can think about what kind of scripting we know exist in Web Apps: HTML & JavaScript being the 2 most common.
Secondly, XSS is part of the INJECTION bug class (see @owasp's Top 10)
So, we now know XSS consists of injecting scripts in websites.
Types of XSS:
1. Reflected 2. Stored 3. DOM-based
They can also be Blind too (you don't see the reflection)
As this thread is aimed at beginners, I will focus on the first 2 as they're easier to understand at first
In order to know what which user role can do, you have to know your target well.
If documentations are available, make full use of them, if not, use the app as much as you can from the perspective of each user role (have a different account for each role)
Anywhere you see user input is reflected in the response (not limited to what you see on the page, it could be in source code/HTTP response only), note the location/parameter down, that's a potential attack vector.