Hi Alice,
I'm here today to talk about Server-Side Request Forgery (SSRF). SSRF occurs when a web application contains some functionality where the application makes an outbound request which the attacker controls the destination to. This can vary from banner grabs to full HTTP requests. An interesting example is a researcher pivoting into NIPRNET via SSRF:
https://medium.com/bugbountywriteup/piercing-the-veil-server-side-request-forgery-to-niprnet-access-c358fd5e249aThe impact of SSRF is contextual, but potentially being able to pivot into an internal network, unreachable from the internet, opens up a whole new attack surface.
There is a longer article about it here:
https://www.acunetix.com/blog/articles/server-side-request-forgery-vulnerability/(Use Tor if you want to follow along)
However, examples are always best. Let's use a googledork like the following: "inurl:proxy ext:php "miniproxy""
Miniproxy (
http://joshdick.github.io/miniProxy/) is a PHP proxy that is vulnerable to SSRF out of the box.
From the first page of Google, we see two Miniproxy instances:
https://echo534.server4you.de/proxy/index2.phphttps://atomicmc.tk/proxy.phpTo test for SSRF, let's input a value such as '
http://localhost/server-status'. Apache's mod_status (
https://httpd.apache.org/docs/2.4/mod/mod_status.html) provides a useful page that lists some server details, plus all HTTP requests to the server. Very often, sensitive information is disclosed by GET requests within Apache's server-status. While this page is normally inaccessible from the internet, we are able to exploit SSRF to issue the request from the webserver itself and return the content, bypassing this restriction:
Post too long. Click here to view the full text.
