Cross-Site Scripting 101: Types of XSS Attacks
How Non-Persistent XSS Works
Taking a common example, imagine you have a search engine on your website. The user types a search string, such as
reflected XSS, and the web server returns a page with the heading
You searched for reflected XSS, followed by the search results. Quite often, the search string is directly included in the URL as a query parameter, which makes this type of attack much easier. Error pages are another place where user inputs are often echoed directly.
If the server fails to properly encode user inputs, an attacker might search for a string such as
Here’s a more realistic attack payload:
If the targeted search functionality directly echoes the search query in the results page, it will execute the injected script, causing a redirect to
attacker.com and sending the user’s current cookie value to the attacker.
This type of cross-site scripting attack requires the user to send an HTTP request containing the attack payload, so malicious links are the main vector for reflected XSS attacks. These can be distributed by e-mail or on social media, or simply published on a website under an enticing name in the hope that users will click them. Attackers often use URL shortening services to hide the link content from victims. With a bit of social engineering, users can thus be tricked into visiting malicious URLs.
Preventing Reflected XSS Attacks
Cross-site scripting is one of the fundamental vulnerability types in modern web application security, so there are plenty of tools and resources to help you protect against it. As with other injection attacks, careful input validation and context-sensitive encoding provide the first line of defense against reflected XSS. The “context-sensitive” part is where the real pitfalls are, because the details of safe encoding vary depending on where in the source code you are inserting the input data. For an in-depth discussion, see the OWASP Cross-Site Scripting Prevention Cheat Sheet and OWASP guide to Testing for Reflected Cross-Site Scripting.
Filtering inputs by blacklisting certain strings and characters is not an effective defense and is not recommended. This is why XSS filters are no longer used in modern browsers. For an in-depth defense against cross-site scripting and many other attacks, carefully configured Content-Security Policy (CSP) headers are the recommended approach.
The vast majority of cross-site scripting attempts, including non-persistent XSS, can be detected by a modern vulnerability testing solution. Invicti finds many types of XSS, from basic reflected XSS to more sophisticated attacks like DOM-based and blind XSS, and provides detailed recommendations about suitable remedies.