Injection is an attack vector that involves breaking out of a data context and switching into a programming context through the use of special characters. These characters are significant to the interpreter being used, but not needed for the general user input being asked for.
Cross-site scripting, commonly known as XSS, is a form of injection where the interpreter is the browser and attacks are buried in an HTML document. HTML is particularly difficult because it's not only hierarchical, but also contains many different parsers (XML, JavaScript, CSS, PHP, etc.).
HTML is a very dynamic and free-flowing language—something that allows the web to be as advanced and colorful as it is, while also making it a nightmare to parse and filter. To make matters even worse, browser technology and features are expanding at an incredible rate and security must run to keep up.
While this makes the web fun and dynamic, it makes the security auditors job more difficult. How can you expect a legacy web application to take into account new features, protocols, and attack vectors? You simply can't.
What does all this mean to you?
Quite a bit actually, as XSS vulnerabilities are far more common that one might imagine. No matter if you are penetration testing, web developing, or black-hatting it somewhere in the middle, this is knowledge you want. Finding XSS holes is the easy part—knowing how to creatively exploit them and assess the possible impact of them is where the real coding and creativity comes in.
Injection? Like SQL Injection, Right?
Well, yes and no. In a nutshell, code injection using SQL is similar to XSS on the idea that it is abusing user input to be ran as a command or as code. SQL targets the database server (in this case, the interpreter), whereas XSS targets unsanitized HTML and JavaScript in the web browser, so as to execute one's own JavaScript code on an unsuspecting victim's machine. There are other differences, as well, and they will be apparent as we get deeper into the vulnerability.
There are two general categories of XSS attacks, reflected and persistent.
A Tale of Two Types
A reflectedXSS vulnerability is when code is injected into a website to deliver a payload or to produce a result on the end user's browser. Reflected XSS vulnerabilities are delivered to a victim via various means, such as an email causing the user to click on a malicious URL, which in itself normally contains the malicious code.
A persistentXSS vulnerability is one in which the code is actually injected into the website itself, and remains for multiple users to be attacked by. For example, placing XSS code within the database that a forum uses would mean anyone who viewed that specific forum or thread would be affected by said code. The URL used to access this forum would not appear malicious in this case and chaos might ensue.
XSS in Action
The next logical step to understanding XSS is to talk about its injection points. Where can web applications fall victim? Since XSS works as an interaction with active server content, any form of input should be filtered if it's ever to show up in a HTML page!
The default example of a reflected vulnerability, and the easiest to exploit, is parameters passed in through query string arguments (such as a search query) that get written directly to page. These are enticingly easy because all of the information can be provided directly in a clickable link and does not require any other HTML to perform. Hack in a sack, you could say.
Let's look at a famous example.
One well known persistent attack was the on MySpace by the Samy worm. In 2005, Samy Kamkar inserted JavaScript/Ajax code into his profile which updated a user's profile with "but most of all, samy is my hero."
The code would also add Samy's profile to the victim's list of friends. The XSS script would extract information about the user from the browser by looking at a cookie. Then the victim's profile was modified by adding Samy as a friend and in the victim's list of heroes, as well as replicating its own JavaScript/Ajax payload so as to spread. This ended up effecting over one million users.
Prevention
All XSS attacks infect your website via some form of user input. XSS attack code could come from a simple
Comments
No Comments Exist
Be the first, drop a comment!