Cross-Site Scripting for Fun and Profit

Still one of the most common vulnerabilities in web applications, XSS (cross-site scripting) still serves as a useful point of attack for hackers. If you are a web developer, knowing how to properly protect your application from these attacks is a must.

Cross-site scripting vulnerabilities exist when the user input in web forms or in API calls are not properly escaped and sanitized before it is used. Directly reflecting user input back to the browser can be a sketchy practice. If the user inputs JavaScript into a form input field, and that script executes, then you have a vulnerability that hackers can take advantage of.

There are two ways users can give input to a web page: through web forms, and through URL parameters (usually by clicking links on the page). Both input types are interesting injection points for someone looking to exploit your page.

Modern web applications seek to filter out this type of input. OWASP has put together a large selection of attack vectors for XSS exploits that try to bypass these filters. You can see the list here.

To manually test your own applications you can try the following input strings:

• <script>alert()</script>: usually, doesn’t work. 
• <img src=x onerror=alert()>: this is typically stored as an XSS exploit, typically in the comment functionality, etc. If code pops up an alert when you reload the page, you have successfully injected JavaScript into the page that will be used by others too. Now you can just go ahead and change the alert with a more evil kind of thing, like a redirect to your phishing site of choice (don’t do it, it really is evil - and illegal).
• In URL parameters: data:html,alert() or data:text/JavaScript,alert(); or JavaScript:alert()

The URL manipulation is typically used in links supplied in scam emails, etc. It makes your code execute within the context of the web application, and is often used to steal session data.

Avoiding XSS as a Developer

There are several things you can do as a developer to avoid these vulnerabilities. The best way is to use a framework/templating system that auto-escapes dangerous inputs for you. Most modern web frameworks will do this for you, as long as you enable the right middleware!

You should also test for vulnerabilities, including XSS. You can do this manually by trying to inject strings like the ones above, and you can use a vulnerability scanner. Allow someone else to look at your code to try and find weaknesses – it is harder to see errors when you have made them yourself! You should use multiple test methods when available, and also consider including security tests in unit testing for your code.

Some takeaways:

• Also, big league players have XSS vulns on their sites. See this Register story from 2014 on a plugin bug for WordPress, affecting most of the platform (2014).
• XSS will allow hackers to attack your users. You are partially to blame if this was possible due to neglect on your behalf. Right? And your customers would get angry.
• Web application frameworks deal with this in a good way. It is very hard to write context-aware escaping manually, so stick with a framework!