SSRF - Portswigger Lab Walk through | Shahul Hameed
What is SSRF?
Server-Side Request Forgery (SSRF) refers to an attack, wherein an attacker can send a crafted request from a vulnerable web application. SSRF is mainly used to target internal systems behind WAF (web application firewall), that are unreachable to an attacker from the external network. Additionally, it’s also possible for an attacker to mark SSRF, for accessing services from the same server that is listening on the loopback interface address called (127.0.0.1).
Server Side Request Forgery (SSRF) occurs when a web application is making a request, where an attacker has full or partial control of the claim that is sent. A typical example is when an attacker can control all, or a part of the URL to which the web application makes a request to some third-party services. Here, I had captured the parameter of file= URL, and I’ve tried to perform this server-side forgery attack.
POC
Browse to
/admin
and observe that you can't directly access the admin page.We walk through overall the application request and responses using the burp suite tool.
We found a stockAPI variable with contains an external third-party URL encoded as shown in the below screenshot. Since we are trying to inject some other URLs, ports, or IP addresses (RCE & LFI ) into the value.
Here we receive an internal server error response for the given URL in the below screenshot.
We found some sensitive paths such as admin in the response.
We entered the path of admin along with reviewing the response and we successfully found the path to delete the user account as shown in the below screenshots.
Finally, We have successfully deleted the account as shown in the below screenshot.
- Generic error messages should be displayed to every client, as unhandled responses might end up revealing sensitive information or data leakage about the server when any other raw response or different parameter is used.
- URL schemes other than HTTP and HTTPS should be blacklisted. Instead, these two mentioned protocols should be whitelisted thereby blocking different schemes which are not in use like file:///, direct://, feed://, touch:// and FTP://, which might prove to be dangerous for SSRF.
Comments
Post a Comment