CCRROOSSSS--SSIITTEE SSCCRRIIPPTTIINNGG EEXXPPLLAAIINNEEDD AMIT KLEIN, FORMER DIRECTOR OF SECURITY AND RESEARCH, SANCTUM A whitepaper from WatchfireTTAABBLLEE OOFF CCOONNTTEENNTTSS Introduction ..................................................................................................................... 1 Full Explanation – The XSS Technique...................................................................... 1 Scope and Feasibility ..................................................................................................... 3 Variations on the Theme ............................................................................................... 4 Other Ways to Perform (traditional) XSS Attacks .................................................... 4 What Went Wrong?......................................................................................................... 4 Securing a Site Against XSS Attacks........................................................................... 5 How to Check if Your Site is Protected from XSS.................................................... 5 Conclusion........................................................................................................................ 6 Links .................................................................................................................................. 7 About Watchfire.............................................................................................................. 8 Copyright © 2006 Watchfire Corporation. All Rights Reserved. Watchfire, WebXM, Bobby, AppScan, PowerTools, the Bobby Logo and the Flame Logo are trademarks or registered trademarks of Watchfire Corporation. All other products, company names and logos are trademarks or registered trademarks of their respective owners. Except as expressly agreed by Watchfire in writing, Watchfire makes no representation about the suitability and/or accuracy of the information published in this whitepaper. In no event shall Watchfire be liable for any direct, indirect, incidental, special or consequential damages, or damages for loss of profits, revenue, data or use, incurred by you or any third party, arising from your access to, or use of, the information published in this whitepaper, for a particular purpose. www.watchfire.comCROSS-SITE SCRIPTING EXPLAINED © Copyright 2006. Watchfire Corporation. All Rights Reserved. 1 INTRODUCTION Cross-Site Scripting (XSS for short) is one of the most common application-level attacks that hackers use to sneak into web applications today. Cross-Site Scripting is an attack on the privacy of clients of a particular website which can lead to a total breach of security when customer details are stolen or manipulated. Unlike most attacks, which involve two parties – the attacker, and the website, or the attacker and the victim client, the XSS attack involves three parties – the attacker, a client and the website. The goal of the XSS attack is to steal the client cookies, or any other sensitive information, which can identify the client with the website. With the token of the legitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site – specifically, impersonate the user. For example, in one audit conducted for a large company it was possible to peek at the user’s credit card number and private information using a XSS attack. This was achieved by running malicious Javascript code at the victim (client) browser, with the “access privileges” of the website. These are the very limited Javascript privileges which generally do not let the script access anything but site related information. It should be stressed that although the vulnerability exists at the website, at no time is the website directly harmed. Yet this is enough for the script to collect the cookies and send them to the attacker. The result, the attacker gains the cookies and impersonates the victim. FULL EXPLANATION – THE XSS TECHNIQUE Let us call the site under attack: www.vulnerable.site. At the core of a traditional XSS attack lies a vulnerable script in the vulnerable site. This script reads part of the HTTP request (usually the parameters, but sometimes also HTTP headers or path) and echoes it back to the response page, in full or in part, without first sanitizing it i.e. making sure it doesn’t contain Javascript code and/or HTML tags. Suppose, therefore, that this script is named welcome.cgi, and its parameter is “name.” It can be operated this way: GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0 Host: www.vulnerable.site ... And the response would be: <HTML> <Title>Welcome!</Title> Hi Joe Hacker <BR> Welcome to our system ... </HTML> How can this be abused? Well, the attacker manages to lure the victim client into clicking a link the attacker supplies to him/her. This is a carefully and maliciously crafted link, which causes the web browser of the victim to access the site (www.vulnerable.site) and invoke the vulnerable script. The data to the script consists of a Javascript that accesses the cookies the client browser has for www.vulnerable.site. It is allowed, since the client browser “experiences” the Javascript coming from www.vulnerable.site, and Javascript’s security model allows scripts arriving from a particular site to access cookies belonging to that site.CROSS-SITE SCRIPTING EXPLAINED © Copyright 2006. Watchfire Corporation. All Rights Reserved. 2 Such a link looks like: http://www.vulnerable.site/welcome.cgi?name=<script>alert(document.cookie)</script> The victim, upon clicking the link, will generate a request to www.vulnerable.site, as follows: GET /welcome.cgi?name=<script>alert(document.cookie)</script> HTTP/1.0 Host: www.vulnerable.site ... And the vulnerable site response would be: <HTML> <Title>Welcome!</Title> Hi <script>alert(document.cookie)</script> <BR> Welcome to our system ... </HTML> The victim client’s browser would interpret this response as an HTML page containing a piece of Javascript code. This code, when executed, is allowed to access all cookies belonging to www.vulnerable.site, and therefore, it will pop-up a window at the client browser showing all client cookies belonging to www.vulnerable.site. Of course, a real attack would consist of sending these cookies to the attacker. For this, the attacker may erect a website
View Full Document
Unlocking...