These three types of files (.htm/.html files, HTML resources, and CHM files) can contain XSS bugs . In the reflected XSS examples discussed so far, the server has echoed attacker input in the HTML returned to the client. This is most commonly done by sever-side scripting languages such as Perl, Active Server Pages (ASP), or PHP: Hypertext Preprocessor (PHP). Because local files are not run through a server-side script interpreter how can a local HTML file contain a reflected XSS bug? The HTML file can contain script that rewrites its own contents and can echo user -supplied data.

Data sent to local HTML files will generally be sent through the URL. Forms using the POST method send the form variables at the end of an HTTP packet. Because viewing HTML files on the local hard disk doesn t use HTTP, posting data to these files won t be very useful in testing. Data sent to local HTML files is usually sent by appending a question mark or hash mark (#) to the local HTML file s filename followed by the data. Here s an example to clarify.

Example: Local HTML File Reflected XSS

Load localHello.html (which you can find on the companion Web site) in your Web browser. After you enter the filename, insert the hash mark (#) followed by your name. As shown in Figure 10-9, your name will be visible in the local HTML file.

image from book


Figure 10-9: The local HTML file echoing the data supplied following the hash mark

View the source of localHello.html. When you examine the source of the document, you see that the name entered after the hash mark isn t present. What s going on? Somehow the HTML contained the name because it is displayed it in the browser. This requires a closer look at the page s source (see Figure 10-10). The script in the page contains a variable named strName . This variable is set with the value of the browser s hash ( location.hash ), excluding the first character in location.hash . (The first character is always the hash mark, and the programmer of the page didn t want to echo that character.) Later in the script, the new contents are written to the HTML displayed (through the DOM) using the document.write method. In this case, Hello, Tom was written. The browser displays the modified HTML content allowing you to see Hello, Tom in the browser window.

image from book


Figure 10-10: HTML source, which doesn t contain the user-supplied data in the local XSS exploit

With an understanding of the source code of this file, you know the untrusted data isn t encoded or filtered. Anything placed in the URL after the hash mark is echoed. The programmer likely didn t realize reflected XSS is possible through files on the local hard disk. Try sending in <SCRIPT>alert('Hi!')</SCRIPT> as the data following the hash mark. Bingo! Script runs.

Exploiting Reflected XSS Bugs in Local Files

Before we discuss why XSS bugs in local files are an issue, you must understand the first steps in exploiting these issues. In XSS bugs in Web servers, the attacker coerces the victim into navigating to a URL that contains the XSS bug. The attacker knows the full URL to the buggy page (example: ). Everyone can access the page at the same URL. This is good for attackers because they will always know where to point the victim. Much like an XSS bug on a Web server, to exploit an XSS bug in a local file attackers must point the victim to the URL of the buggy file. Unfortunately for attackers, the URL containing the XSS bug varies from system to system; for example, on one attacker s machine it might be C:\SomeCoolProgram\buggy.html, but on another attacker s machine it might be something different such as D:\SomeCoolProgram\buggy.html. The directory names might also be different. How can attackers deal with this? First, most users accept the default installation directory for a program. If a program suggests SomeCoolProgram as the install directory, most users will install to that directory. Also, most people install programs to the C drive. Information disclosure bugs, discussed in Chapter 7, Information Disclosure, might be used in combination with local XSS bugs to help attackers determine where buggy files live on a victim s hard disk.

Understanding Why Local XSS Bugs Are an Issue

Although there probably aren t cookies or user data issued for the local file system, an attacker can still cause harm by exploiting a local XSS bug ”often more harm than attackers can cause with an XSS bug in a Web application. Local XSS bugs enable an attacker s code to run in the My Computer zone, which has the most lax security settings, which is why attackers are quite happy when they discover a local XSS issue. Less security means more fun for attackers.

Remember that an XSS bug can access the DOM of all other pages for the same site. (If you missed it, this information is in the sidebar titled XSS Enables Actions That Are Normally Prohibited earlier in this chapter.) In the My Computer zone, there isn t the notion of domain or site. All of the My Computer zone is treated as the same entity, which means that any page in the My Computer zone can access any other page in this zone through the DOM (file system permissions still apply). Once in the My Computer zone, attackers can read other fileson the local hard disk. Attackers need to know the path of a file they want to look into, but often this isn t a huge issue. Suppose there is a file on the victim s machine named C:\SercetPlans.txt, which contains secret plans. The following script grabs the contents of C:\SecretPlans.txt and displays it in a dialog box:

<SCRIPT> var x=window.open('file://c:/SecretPlans.txt','myWindow'); while (x.document.readyState !='complete') ; var strSecretText=x.document.body.innerText; x.close(); alert(strSecretText); </SCRIPT>