XSS Through File Upload
Hi Folks!
This is my 33rd blog on web application security penetration testing. In this blog I will explain about XSS Through File Upload.
In my last blog, I have explained about XXE Attack. Hope everyone liked it. If you haven’t read it yet please follow along.
In my previous blogs I have already explained all the types of XSS and the ways to exploit it. This time we will see new technique to exploit XSS Vulnerability Via File Upload Functionality using Name of the file as a Injection Vector.
As we know many web application allows end users or their application users to upload files for many different purposes and this is only the opportunity to find loopholes on them. so let’s see how to attack these entry points which allows files to upload there, for the purpose of finding XSS.
XSS Through Filename:
Many web applications allows application user to Upload files on the server and displayed the name of the uploaded file back to the webpage which allows an attacker to upload malicious files with XSS payloads to be uploaded if proper input validation for file name is not in the place.
Below is the step-by-step POC which shows how XSS through File Upload works:
- I have below File Upload functionality in the web page which allows users to upload photos.
2. I have tested that application can accept different different malicious characters into file name upon uploading it.
3. In next step, I have created filename as a malicious XSS payload using kali linux because windows system doesn’t allow us to save malicious characters in the file name.
Payload Used: “><img src=x onerror=alert(document.domain)>.jpg (as a Filename).
4. In my kali linux, I have ran the web application and upload the malicious file as a photo. Once click on Upload button, Below prompt getting displayed which proves application is vulnerable to XSS through File Upload.
Cross Site Scripting Impact:
Cookie Theft
Keylogging
URL Redirection
Phishing Attack
Downloading Malwares on victim’s computer, etc.
Cross Site Scripting Prevention:
Preventing cross-site scripting is trivial in some cases but can be much harder depending on the complexity of the application and the ways it handles user-controllable data.
In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the following measures:
Filter input on arrival. At the point where user input is received, filter as strictly as possible based on what is expected or valid input.
Encode data on output. At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.
Use appropriate response headers. To prevent XSS in HTTP responses that aren’t intended to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.
Content Security Policy. As a last line of defense, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.
Labs to Practice XSS:
https://jlajara.gitlab.io/web/2018/12/16/XSS-Google-Game.html
I hope everyone will like the constant reading from my blogs. Please do comment and follow for more reads!
Thanks!
