Anatomy of Cross Site Scripting Attacks
Many Web applications include unfiltered user input, such as text entered into forms, in their own output. This flaw allows attackers to inject malicious URLs into emails, social media communications, forum posts and more. Since the response to a user request is delivered from a trusted site, the client browser follows the same origin policy and executes the malicious script. The code might do any number of things including transmit session tokens and cookies or modify page HTML. The modified HTML pages could deliver an infected PDF through an iFrame to try and compromise visitors as they arrive. As the scripts target client-side browsers, even read-only websites can be vectors for XSS attacks.
An attack script running under the same permissions as an unsuspecting user could compromise a customer entering financial information or a Web administrator with superuser access to an entire website. Admin-level exploits include posting malicious content, exposing sensitive files, altering logs to cover evidence of other attacks, and even deleting sites.
Cross-site scripting attacks exploit dynamic Web content and insecure Web development practices. Web scripts parse and manipulate user input, allowing users to interactively submit and retrieve information, log in to accounts, socialize, and many other activities. If applications do not properly validate user input, attackers can inject malicious code into otherwise innocent vectors. Many Web applications are developed with security flaws in rapid coding environments that shortchange coding and testing from a security perspective. Design requirements might not adequately specify how the application should filter input, and test plans often do not include test cases for robust error checking.
Reflected XSS Attacks
Stored XSS Attacks
In a stored or persistent attack, the malicious script is stored in a database, blog post or other permanent location on the target server where it can be repeatedly accessed. When a user requests the compromised information, the script executes and sends data back to the attacker’s server.
For example, an attacker seeds a user list with a link to the attack server. When an unsuspecting forum administrator clicks on the link, the session ID information with admin privileges is sent to the attacker, who now has superuser access to the victim system for as long as the session persists.
HTML-Based Attack Vectors
Attackers can hide malicious code within HTML constructs deployed on Web pages and in HTML-formatted emails. In addition to commonly used tags such as script, onmouseover and onerror, attackers can disguise a UTF-8 encoded string in an IMG or META tag to pass certain kinds of validation by the Web application. For instance, an attack might bait users by displaying a legitimate-sounding message on a trusted website. However, following the innocuous message is an invisible XSS script hidden between tags. If the user clicks on the link to display the bait message, the client browser executes the script.
While identifying all of an application’s vulnerabilities is time-consuming, the payoff of a thorough code review is worth it. Developers and testers should also seek better and continuous training in application security practices. Investing in a defensive mindset at the design and test phases reduces the burden on administrators and the victimized public.
About the Authors
Terry Cutler is a co-founder of Digital Locksmiths, an IT security and data defense firm based in Montreal and serves as the company’s Chief Technology Officer and Certified Ethical Hacker. In addition to being a licensed private investigator in Canada, Terry is an internationally known author, trainer, speaker, and security consultant, Terry has appeared in numerous national television and radio programs and is very active on the conference circuit.
Follow Terry on Twitter at @TerryPCutler