This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Command vs Data in 2nd Order Cross-Site Scripting Attacks

SQL injection isn't the only situation in which hackers can elevate data to a command level in order to execute an attack. Web applications, for example,
have to constantly guard against what can happen when end-user input is collected then redisplayed for other users (typically after it's been saved to a
database).

Here's a simple example of how exploits against web applications can function: Suppose that a blog engine allows visitors to comment on posts. This
blogging engine stores user comments in a database and then redisplays them to subsequent visitors. A comment such as "nice
post!</body></html>" would wreak havoc with the display of the site because the user input has been elevated to the command level and has been
empowered to prematurely signal the end of the HTML document through the use of HTML tags.

However, when it comes to exploiting web applications, hackers typically aren't looking to merely deface layouts. Instead, they're looking for an
opportunity to use any input mechanism (such as form fields, the query string, cookies, user-agent strings, or the referrer) to inject markup and behavior
into a vulnerable site, which they can then use to exploit the browsers of other visitors. So, for example, rather than injecting something tame like
"</html>", a hacker might try something like "<img src=http://evilsite.com/x.gif />", which would instruct a user's browser to "reach across"
to another website. Moreover, if hackers are able to force browsers to reach across to other websites and load scripts, they succeeded in creating what is
known as a cross-site scripting, or XSS, attack. (See "Cross-site scripting" for
more information.)

Commonly, XSS attacks are categorized as either being first-order (or direct) or second-order (or persisted) attacks. In first-order attacks, hackers try
to lure users to click a link that uses direct input (commonly from the query string) to facilitate an attack. In second-order attacks, hackers try to
successfully save input (e.g., input in the form of comments) in a database.

Because second-order XSS attacks involve a database, they're commonly confused with SQL injection attacks. But other than the fact that SQL injection and
second-order XSS attacks involve the use of databases and occur when developers let hackers elevate input to the command level, these two attack vectors
are quite different. For example, SQL injection attacks focus solely on attempting to gain control of databases and the data within them (although if
hackers gain sufficient control, they can execute second-order XSS attacks as a "bonus"), whereas XSS attacks focus on exploiting web browsers and their
owners.

Trying to scrub, or filter out, malicious input represents an ineffective solution for XSS attacks. Instead, you need to make sure that end-user input is never allowed to be blindly parroted back as markup. In other words, to defeat XSS attacks, user-supplied input needs to be encoded to ensure that
it's treated as data instead of markup.