-
Notifications
You must be signed in to change notification settings - Fork 0
SSRF ‐ Hints
- Burp collaborator
- RequestBin
- Beeceptor
This first SSRF is an introduction, just try to understand what is a Server Side Request Forgery and learn the basic principle of the vulnerability. Then you can practice without restrictions.
For this second SSRF, something changed that reduce the attack surface of the vulnerability, but you can still easily send requests to external urls and see the result on the page.
This SSRF have the same protection that the second one, the only difference is that the result isn't fetched on the page.
This SSRF had a protection that allow to request only some types of files by checking the extension at the end of the URL.
This SSRF is a little bit more tricky as the server check now if the domain name "example.com" is used in the URL. But the way the verification is done makes it easy to bypass the protection has it do not check where the domain is entered in the URL.
In contrast to the "SSRF - Whitelist", this SSRF now check that the URL start with "https:// example.com", so you will have to understand better the structure of an URL to find a way to request your server.
For this SSRF, You will have to chain the vulnerability with an other one that will allow you to send requests to you server while respecting the target server whitelist.
Like the previous SSRF, You will have to get your SSRF by first exploiting an other vulnerability called "XXE", try to understand how this vulnerability work, and how to get an SSRF through it.
Some PDF generators accept HTML execution. If user inputs are included while generating PDF, it sometimes can lead to HTML injection and being escalated to SSRF. (I'm currently searching a way to improve this PoC)
Who said that image files are safe ? For this SSRF, try to list image file extensions that are accepted by the target server and upload a malicious file that is able to force users to send requests to your server.