Cross-site scripting (XSS) continues to remain a prevalent vulnerability in web applications, having ranked in the OWASP Top Ten for 2017. XSS is a type of injection attack where malicious scripts are injected into a trusted website, abusing the user’s trust in said website. The Financial Services website I was examining for this attack vector evaluated risk management.
Creating a document template was a two-step process: the first step designated a name for the template, and the second was selecting the parameters for the template. After creating a test template, I noted on the page listing the templates that the template names were reflected in the source code as such:
Targeting the reflection in the anchor tag, the idea was to get an event handler attribute in the tag such that user interaction with the link triggered the injected payload. The initial attempt of using special characters in the template name was met with an error message stating only alphanumeric characters can be used; further digging into the source code revealed it was just a client-side check that can be bypassed using a proxy tool such as Burp Suite.
Using the test string
“xss=”xss, I came across another issue. The inputted template name was being reflected on the second step of the creation process and being interpreted as code, so saving the new template would not set the same template name that was initially inputted. Using HTML entity encoding, I was able to resolve the issue with the test string
onmouseover event handler, I crafted this initial payload of:
confirm) from the template name, along with property accessors of some objects (e.g.
Combining these evasion techniques, the final payload to illustrate the success of an XSS attack was:
The request to create the malicious template was as follows:
With the newly-created template containing the injected payload, simply moving the cursor over the template name on the template list page triggered execution of the script.
Preventing XSS requires treating untrusted data separate from the application code. Input validation can be used for untrusted data to ensure that the data is properly formed for the context it is received, both syntactically and semantically. However, output encoding should be the primary method of preventing XSS. Untrusted data, such as that from user input, should be contextually encoded when displayed so that it is treated as data and not as code. Additional mitigations against the impact of XSS include setting the HTTPOnly flag on the session cookie, implementing Content Security Policy, and using the X-XSS-Protection response header. Following these strategies will work much better than trying to use a blacklist to prevent XSS.