While performing a recent penetration test for an undisclosed client, I found that the site was vulnerable to several types of XSS attacks.

The field was a simple search box located on the site.

During a blind test, the search box was performing unusually to special characters, namely quotation marks and brackets. The characters were not encoded in any manner nor went through any data sanitization.

Entering the following payload resulted in a pop-up:

874865arxwa"><script>alert(1)</script>mtnal">

The quotations allowed breakout from the text field and the use of <,/,> allowed for script injections. Additionally, there was no character limit on the search box, which can allow for dangerous scripts to be injected.

The image below shows the code injection was successful.

The report was sent to the undisclosed company, who attempted to remediate the finding.

Retest at a later date found that the company’s efforts for data sanitization removed only brackets from their whitelisted characters. However, there are other payloads that can trigger XSS popups without the use of <script>. An example of this is:

hello"onfocus="alert(1)"autofocus="kz1za

The original problem of quotation marks being a whitelisted character without any sort of encoding still allows for text to breakout of the search box. The severity of the vulnerability decreases only slightly with disallowing the use of brackets. However, injecting malicious code from external sources or rerouting the page could still be possible.

Other factors Contributing to the Risk Level

The website did allow for the use of a Content Security Policy but allowed for unsafe-inline  so external content and inline scripts can be injected into the site. The unsafe-inline keyword negates the majority of benefits that Content-Security-Policy provide.

Mitigation

The encode() method HTML encodes characters, which can prevent this type of attack from occurring.

If the double quote (“) character is inserted inside of the search box to try and break out of the HTML attribute context, this would be converted to " or " which is the HTML representation.

Content-Security-Policy will also help provide defense in depth. See Resources section for how to properly implement.

Additional Resources

XSS Payloads: https://github.com/payloadbox/xss-payload-list

CSP-Header: https://content-security-policy.com/unsafe-inline/