This is an advanced Cross-site Scripting (XSS) post, if you’re new to XSS maybe try this one first: What is Cross-site Scripting? During Penetration Tests I often see testers utilising Cross-site Scripting attacks, popping an alert(1) and stopping there; additionally looking through the payloads used by other testers I often find one area missing. So if you’re a tester, think of the payloads that you deploy and think how you are testing for the type of vulnerability described below:
Effectively filtering user input is one of the best ways to prevent an awful lot of web application vulnerabilities. There are several ways to approach this, each with their own pros and cons so I’ll run through them here an then you can think of the best way to combine them for your context. It’s important to remember though, that filters are context specific, there is not one filter that will work for a whole application and that’s what can make writing an effective filter tricky.
Cross-site Scripting is the third vulnerability on the OWASP Top 10 and it is a vulnerability that can allow an attacker to steal confidential data, execute functions on a vulnerable site, virtually deface a site or redirect the user to a malicious page.
Sometimes when I’m chatting to security engineers and developers I hear them say that the only characters you need to encode (or strip) are < and >. This often comes around due to .Net’s security filter which restricts any alpha-character from appearing after a < character. This filter prevents a lot of XSS attacks but it’s definitely not complete.