How You Can Escalate a Simple HTML Injection Into a Critical SSRF

SSRF or Server Side Request Forgery is a type of vulnerability where the attacker can make the request on behalf of the vulnerable web server and can fetch any internal file from the server, this is the most precise summary of the bug I can come up with. It is one of the hottest bugs to find as the number of attacks through SSRF are growing. As web applications are becoming more and more complex and integrated, the chances for it getting vulnerable to SSRF attacks are also increasing. Moreover protecting your server from SSRF Attacks are a bit tricky for developers as every day more and more bypasses are coming. SSRF bugs are present on functionalities where the wen application is fetching any data from the third part web applications. Some good examples of it are fetching an image trough URL, importing your files from services like DropBox or more specifically creating webhooks on the application. This article also assume that you can knowledge of basic pentesting tools like Burp Suite and Burp Collaborator.

HTML Injection:

Before I begin I would also like a explain HTML Injection in few words, HTML Injection is a bug in which the attacker can store or run the HTML code on the website by storing it or passing it in the parameters. HTML Injection is considered to be a low severity vulnerability and in most cases it is just considered as an Informational bug. Other than this an <iframe> tag in HTML is used to embed another document or webpage inside a current page. These two things can be used to escalate an HTML Injection into an SSRF attack which can undermine the privacy of the server.

Server Side Request Forgery through Html Injection:

There are many endpoints, functionalities and different ways to look at an SSRF vulnerability but today I will talk about only looking for SSRF through HTML Injection and more specifically HTML Injections in PDF File Generating Functionalities.

In most of the websites, specially in CRM web applications, we usually came across functionalities like Export In PDF or Generate a PDF Report. When we click on these buttons a PDF report in generated from the server and downloaded in our computer. These PDF generators in most cases are vulnerable to HTML Injections, and developers don’t even try to fix it because an HTML Injection in a PDF can never cause harm to anyone, but what they don’t realize is that through injecting an <iframe> tag in the PDF the attacker can look for SSRF Injection points and can could make a request on behalf of the server. I will be talking about looking for SSRF through HTML Injection and I will be taking an example of these PDF Generators.

These findings were made possible by the research of Nahamsec, which you can find at https://docs.google.com/presentation/d/1JdIjHHPsFSgLbaJcHmMkE904jmwPM4xdhEuwhy2ebvo/edit#slide=id.g5d4335792d_0_19.

Testing If SSRF attack could be possible here:

The first step in looking for Server Side Request Forgery through this way is to look for endpoints and parameters where you can inject the HTML Code. In most cases whenever you generate a PDF report, you usually have to fill in some parameters or sometimes some parameters like your name, message etc are reflected in the PDF. You have to inject a simple HTML code like <b>TESTING</b> into these inputs and see whether the server is rendering it as an HTML or not. If the code is getting rendered then you have move to the next step and now try to inject an <iframe></iframe> tag. Here you have to make sure of two things.

So now to test the endpoint further, you have to open your Burp Collaborator or you can also use your own server if you have one. Burp Collaborator is a network tool that is a part of professional version of Burp Suite, and this tool can be used to monitor the request that are made from any host or server.

On your collaborator generate a new payload and paste it in the src of your iframe tag. On the PDF generation, first you have to look if any request are made to your collaborator and if the requests are made then you have to look at the IP from which the request is made. Because the request must be made from the vulnerable server for SSRF and not from your own computer.

After it is confirmed that the host is making request to third party websites through an iframe injection. You now have to make the request to any internal file of the system and see if it is loading the contents of the file. For this purpose we mostly make the request to the /etc/passwd file using the protocol file://, so the whole URL and iframe code that you have to put in becomes <iframe src=file:///etc/passwd></iframe>. Pass it and if the server successfully shows you the contents of the etc/passwd file then the SSRF is confirmed. The contents of this file will be like following:

Now, here in most cases the websites have put protection and filters to stop any attacks on the server therefore making a request directly to an internal resource like /etc/passwd will most probably result in failure for the testers. But these protection can be bypassed in many ways, you can find a long list of bypasses at this github repository https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Server%20Side%20Request%20Forgery/README.md.

One of the bypass is using a redirect from your own site to the internal resource. What you have to do here is to create a PHP file on your website with the following code:

Let me explain the above code in easy words, this code will look for any address provided in the parameter link and redirect the user to that address and if no address is provided then by default it will redirect to http://127.0.0.1 which is considered as an internal IP of a server.

This file will take a URL link in its parameter link and then redirect the host to that URL address. Suppose we want to redirect the vulnerable server from our website to its internal file, then we will type in the following address https://yourwebsite.com/redirect.php?link=file:///etc/passwd. Here the name of your website is yourwebsite, the file in which the above code is stored is redirect.php and finally the location you want the vulnerable server to get redirected is given in the parameter link. In this way upon entering the iframe code like <iframe src=https://yourwebsite.com/redirect.php?link=file:///etc/passwd></iframe> in the place for HTML Injection you can bypass the protection that is placed against the SSRF attacks. If the contents of the etc/passwd file are shown in the iframe then congratulations you have pwned the security of the server and found an SSRF vulnerability.