Server Side Request Forgery (SSRF) is an interesting vulnerability, which can have potential impact on internal infrastructure residing behind firewall. In this case, HTTP server running over ports like 80/443 becomes an entry point for an attacker to enter into internal network over as legitimate HTTP/HTTPS tunnel.
To understand this vulnerability in detail, let’s assume we have a vulnerable application running on a hypothetical domain www.victim-example.com having a resource named “profile.php”. It is having a parameter named “propic” and it seems to be fetching picture from a resources as below.
GET /profile.php?propic=http://www.someserver.com/mypicture.png&id=9826739HTTP/1.1
Host: www.victim-example.com
Now, looking at the parameter propic, it is taking URL and fetching file from third party server. What if we can tamper with it and try to fetch something else instead? To try it out, we make a following request.
GET /profile.php?propic=http://www.myblueserver.com/foobar.html HTTP/1.1
Host: www.victim-example.com
This example server www.myblueserver.com belongs to us so we can see the logs of it. We can see this entry in it.
<IP of www.victim-example.com> - - [14/Dec/2017:00:06:28 -0700] "GET /foobar.html HTTP/1.1" 404 113 "-" "<Client type>"
Hence, clearly we got out-of-band call from the application. Application is processing propic (URL)parameter and making call to external app or resources. Application page may have lines like below.
$getpicurl = $_GET['propic'];
$profilepic = fopen($getpicurl, 'rb');
Now, this opens up various exploitation opportunities for an attacker. One of them is shown in figure below.
An attacker can start scanning internal hosts and network with reverse HTTP calls like below -
GET /profile.php?propic=http://192.168.100.X HTTP/1.1
Host: www.victim-example.com
It may get access to internal files and resources. This type of vulnerability is known as SSRF. It is like abusing HTTP calls with request forgery.
Exploit scenarios:
This functionality can be abused and following types of exploitation can be done.
• Internal resource scanning and stealing.
• Using file:// schema to access sensitive resources/files like /etc/passwd or other resources from the same server.
• One can use other schemas like "ftp://", “dict://” or "gopher://" to abuse vulnerability further.
• Attacking some other ports as well with cross protocol requests if possible and given scenario.
Conclusion:
SSRF is relatively easy to detect by DAST specially using manual pentesting. One can fuzz requests and look for 200 OK coming from the same server with content coming from different server (internal/external). It may require out-of-band testing setup in some cases if there is a blind SSRF. If vulnerability is identified then it brings major threat to internal resources and should be fixed immediately by proper validations, whitelisting and other secure coding practices.
To understand this vulnerability in detail, let’s assume we have a vulnerable application running on a hypothetical domain www.victim-example.com having a resource named “profile.php”. It is having a parameter named “propic” and it seems to be fetching picture from a resources as below.
GET /profile.php?propic=http://www.someserver.com/mypicture.png&id=9826739HTTP/1.1
Host: www.victim-example.com
Now, looking at the parameter propic, it is taking URL and fetching file from third party server. What if we can tamper with it and try to fetch something else instead? To try it out, we make a following request.
GET /profile.php?propic=http://www.myblueserver.com/foobar.html HTTP/1.1
Host: www.victim-example.com
This example server www.myblueserver.com belongs to us so we can see the logs of it. We can see this entry in it.
<IP of www.victim-example.com> - - [14/Dec/2017:00:06:28 -0700] "GET /foobar.html HTTP/1.1" 404 113 "-" "<Client type>"
Hence, clearly we got out-of-band call from the application. Application is processing propic (URL)parameter and making call to external app or resources. Application page may have lines like below.
$getpicurl = $_GET['propic'];
$profilepic = fopen($getpicurl, 'rb');
Now, this opens up various exploitation opportunities for an attacker. One of them is shown in figure below.
An attacker can start scanning internal hosts and network with reverse HTTP calls like below -
GET /profile.php?propic=http://192.168.100.X HTTP/1.1
Host: www.victim-example.com
It may get access to internal files and resources. This type of vulnerability is known as SSRF. It is like abusing HTTP calls with request forgery.
Exploit scenarios:
This functionality can be abused and following types of exploitation can be done.
• Internal resource scanning and stealing.
• Using file:// schema to access sensitive resources/files like /etc/passwd or other resources from the same server.
• One can use other schemas like "ftp://", “dict://” or "gopher://" to abuse vulnerability further.
• Attacking some other ports as well with cross protocol requests if possible and given scenario.
Conclusion:
SSRF is relatively easy to detect by DAST specially using manual pentesting. One can fuzz requests and look for 200 OK coming from the same server with content coming from different server (internal/external). It may require out-of-band testing setup in some cases if there is a blind SSRF. If vulnerability is identified then it brings major threat to internal resources and should be fixed immediately by proper validations, whitelisting and other secure coding practices.