Summary
Acunetix 360 detected Cross-site Scripting via File Upload, which makes it possible to conduct cross-site scripting attacks by uploading a file that contains cross-site scripting payload.
Cross-site scripting allows an attacker to execute a dynamic script (JavaScript, VBScript) in the context of the application. This allows several different attack opportunities, mostly hijacking the current session of the user or changing the look of the page by changing the HTML on the fly to steal the user's credentials. This happens because the input entered by the user has been interpreted as HTML/JavaScript/VBScript by the browser.
Cross-site scripting targets the users of the application instead of the server. Although this is limitation, since it allows attackers to hijack other users' sessions, an attacker might attack an administrator to gain full control over the application.
Cross-site scripting via file upload, leverages user supplied image files, not being validated or sanitized by the server before being reflected on the page. These files may contain <script> tags or other HTML code and if they are reflected on the page without output filtering, or served without a proper content-type, they may enable cross-site scripting attacks.
Example content for Gif and Svg files for this kind of attacks are shared below:
- Gif file content:
- GIF89a/<svg/onload=alert(1)>/=alert(document.domain)//;
- Svg file content:
- <svg xmlns="http://www.w3.org/2000/svg" onload="alert(document.domain)"/>
Impact
- Hijacking user's active session.
- Changing the look of the page within the victim's browser.
- Mounting a successful phishing attack.
- Intercepting data and performing man-in-the-middle attacks.
Remediation
The issue occurs because the browser interprets the input as active HTML, Javascript or VbScript. To avoid this, all input and output from the application should be filtered. Output should be filtered according to the output format and location. Typically, the output location is HTML. Where the output is HTML, ensure all active content is removed prior to its presentation to the server.
Additionally, you should implement a strong Content Security Policy (CSP) as a defence-in-depth measure if an XSS vulnerability is mistakenly introduced. Due to the complexity of XSS-Prevention and the lack of secure standard behavior in programming languages and frameworks, XSS vulnerabilities are still common in web applications.
CSP will act as a safeguard that can prevent an attacker from successfully exploiting Cross Site Scripting vulnerabilities in your website and is advised in any kind of application. Please make sure to scan your application again with Content Security Policy checks enabled after implementing CSP, in order to avoid common mistakes that can impact the effectiveness of your policy. There are a few pitfalls that can render your CSP policy useless and we highly recommend reading the resources linked in the reference section before you start to implement one.