Working SSRF Methodology For ME!

“இனியதோர் விதி செய்வோம்”

Hey folks! 👋 Hunting SSRF (Server-Side Request Forgery) is like solving a fun puzzle, and I’m here to share my go-to methodology. It’s a mix of automated tools and manual testing, and it’s been pretty effective for me . If you follow this, you’ll be finding those juicy bugs in no time. Let’s dive right in!

First, I start by collecting as many subdomains as possible. Tools like Sublist3r, Assetfinder, Findomain, Subfinder and Amass are my go-to for this. The more subdomains I have, the better my chances of finding something interesting.

Not all subdomains are active, so I filter out the ones that are actually alive using httprobe or httpx. This saves time and focuses my efforts on targets that matter.

Manual testing can sometimes find vulnerabilities that no tool will show you!

Next, I use crawlers like Katana and tools like Waybackurls and GAU to gather as many URLs as possible.

Dig into Web Archives for Hidden Gems

Wayback Machine archives are especially helpful for finding old or hidden endpoints that might be vulnerable.

These tools will fetch archived URLs that could lead to some sneaky SSRF endpoints. Don’t skip this — it’s a goldmine.

I merge all the URLs into one big file. This makes it easier to handle and ensures I don’t miss anything.

Inject SSRF Payloads Like a Boss

To test for SSRF, I replace all parameters in the URLs with my Burp Collaborator or Ngrok link. This helps me detect out-of-band interactions. I use qsreplace for this step.

if you don't have collaborator you can use ngrok

Then replace the query parameters with your ngrok link

Automated Testing with Eyewitness

For automation, I use Eyewitness. It takes the list of URLs, captures screenshots, and helps me identify potential vulnerabilities quickly.

Manual Testing with Open Bulk URL Extension

Automated tools are great, but manual testing is where the real magic happens. I use the Open Bulk URL extension to load all the URLs in my browser and manually inspect them.

“Manual testing often uncovers vulnerabilities that automated tools miss, like complex SSRF chains or edge cases.”

Check Logs

Finally, keep an eye on your Burp Collaborator or ngrok logs. If a server interacts with your payload link, it’s game on! 🎯

You’ll know you hit SSRF when you see those callbacks in the logs. And don’t forget to validate what you found.

“Never skip manual testing — it’s where the real treasures are.”

Look for Other Vulnerabilities

While testing for SSRF, I also keep an eye out for other issues like XSS, open redirections, or IDOR. It’s like a bonus round!

“A thorough SSRF test often reveals other vulnerabilities, making it a win-win for security assessments.”

And there you have it, my step-by-step SSRF hunting guide. It’s a mix of automation and manual testing, which gives you the best of both worlds. Plus, this method can help you uncover other goodies like XSS and open redirection.

This methodology has worked really well for me, and I hope it helps you too!

This is my first blog, so thank you for taking the time to read it! 🎉 I’d love to hear your thoughts, feedback, or any tips you might have. Let’s keep learning and growing together.

Happy bug hunting! 🐞💻.