In this week’s post, we’ll be doing an introduction to SSRF or Server-Side Request Forgery.

SSRF is an attack that abuses the functionality of an application to make controlled requests which are not directly accessible.

For example, if the following existed http://example.com/page.php?url= you might first realise that this could be a Local File Include, or Remote File Include by changing the URL parameter to /etc/passwd (Linux) for Local or http://hacker.com/test.txt for remote. Both could be assorted with SSRF due to making the server performed requests which might not have been intended; however, these two attacks have their own title, and there is a slight difference.

SSRF on the other hand, is using the same example but targeting things which cannot already be accessed directly. So, expanding on the example above, what if there was a secret web service running on this server but only accessible via the local loopback interface on port 80? Access from outside would not be possible, as you would have to be logged on to this server directly to access it.

Now introducing the example here, if we were to use http://example.com/page.php?url=http://localhost/ instead, this would use the externally accessible application, but then request the service running on localhost, and this would be displayed. Of course, this would depend on how the application is written. However, if there was an admin panel running but wasn’t accessible or restricted externally, the local interface could bypass this and allow access.

Additionally, the problem can arise when using cloud services. The IP 169.254.169.254 is used by AWS EC2 and other cloud services to access a metadata service. Only instances metadata and user-data can be accessed from within the instance; however, there is no authentication or encryption used. So, any information contained here can be read by anyone on the instance, but not externally unless used with this SSRF attack.

Read the reference here