DEV Community

Cover image for Story of SSRF from Stored XSS in PDF generator application
Ruheza, NS
Ruheza, NS

Posted on

Story of SSRF from Stored XSS in PDF generator application

Introduction

PDF generator libraries, particularly those implemented using JavaScript, often face vulnerabilities to cross-site scripting (XSS) attacks, posing a challenge to the security of web applications. One primary reason for this lies in the dynamic nature of JavaScript itself. Many PDF generator libraries heavily rely on client-side scripting to manipulate and generate PDFs, allowing attackers to exploit vulnerabilities in the code. In this write-up, I will show you how I exploited the server side issue (SSRF) from the front-end interface (XSS)

The finding

Basically, the application helps you to generate invoice online by just filling in the data and download the pdf file of it.

I started by doing a recon on the target to identify few things including the stack used to build this application (well, Wappalyzer plus review the minified client code on the browser) and the cloud used to deploy this application (which was AWS).

Story short, instead of filling intended fields and data, i tried to add JS code to see if the code will be interpreted and executed (XSS).

Passing a simple code with script tag

Surprisingly, the app responded with the output of my JS code <script>document.write(document.domain)</script> printing the domain name of the application. Now we have our stored XSS. A journey to increase an impact ...

Domain name got printed on the pdf as redacted.com

Next i wanted to try if i can exploit any server side issue (stealing cookies wasn't enough for me) for that i tried to use iframe, testing if the application can fetch resources remotely. Since i've already knew that AWS is used, i tried to fetch internal meta-data of the instance with <iframe src="http://169.254.169.254/latest/meta-data/">

 SSRF towards AWS instance

As how i was expecting, the application gave me what i requested ...

 SSRF successfully

Up to this point as an attacker, you can do alot on this application. I chose to read access keys of the this server so that i can completely take over the server. In AWS cloud-world, if you can have "Access Key ID" and "Secret Access Key" then you can run command remotely in the server and even play around with some connected services. I wanted this!

First in order to know and read these credentials, you must know the IAM role used in this particular instance. So i added <iframe src="http://169.254.169.254/latest/meta-data/iam/security-credentials/">

I got the IAM role and next step was just to append it on the same endpoint so that we can read these credentials.

Game over

Voila! Now we have a full control of the instance remotely.

Final thought

As we have seen above, the integration of third-party libraries in PDF generators can introduce additional vulnerabilities. Although this is most known issue and well fixed in most of the JS libraries but some libraries especially new ones are still prone to this kind of attacks.

It is advised to double check the library you want to use in your application and ensure that it is free-from pursing issues result to XSS. Also sanitization should always be implemented on all input fields and forms as a preventive measure.

Disclaimer: The researched target mentioned (anonymized) in this write-up was successful patched and remediated. Kudos to the team!

Originally wrote this article here Thanks for reading !

Top comments (3)

Collapse
 
rafeh1 profile image
rafe husain

need help need to send whatsapp message to wordpress blog as comment
can you help or advise?

Collapse
 
maen profile image
Ruheza, NS

Hello, i think you can use wordpress APIs to interact with your whatsapp automation. If you still fail to do it, let me know how i can reach you

Collapse
 
rafe_husain profile image
Rafe Husain