Other XSS-Related Attacks

Other XSS-Related Attacks

You should be aware of three subtle variations to the classic XSS attack: accessing an HTML file installed on the local computer; accessing HTML-like files, such as Windows Help files (CHM files); and accessing HTML resources. Let's look at each.

XSS Attacks Against Local Files

The concept of XSS attacks against Web sites, while a mystery to some, is relatively well-known in the security community. What are not so well-known are XSS attacks against HTML files on a user's computer. Local content is vulnerable to attack if the file location is predictable and it outputs input from the user. Web browsers download cacheable content to random directories on the client computer. For example, on one of my computers, the files are loaded into directories with names like CLYBG5EV, KDEJ41EB, ONWNWXYR, and W5U7GT63 (generated using CryptGenRandom!) This makes it very hard for an attacker to determine the location of the files. However, HTML files installed as part of a product installation are often placed in predictable locations, and it is this consistency that aids an attacker.

Generally, the attack happens because an HTML page takes data from a URL and uses that to build output. Take a look at this example imagine it's named localxss.html and it's loaded in a directory named c:\webfiles:

<html> <head> <title>Local XSS Test</title> </head> <body> Hello! &nbsp; <script>document.write(location.hash)</script> </body> </html>

This code will echo back onto the Web page whatever is after the hash symbol (#) in the URL.

The following link will display a dialog box that simply says Hi! if the user clicks it:

file://C:\webfiles\localxss.html#<script>alert(''Hi!');</script>

This attack is a little more insidious than simply popping up a dialog box. This code now runs in the My Computer zone. (Microsoft Internet Explorer includes the notion of zones. See the coming sidebar, Understanding Zones, for more information.) If code can come from the Internet, it's in the Internet zone by default, but when the unsuspecting user clicks the link, the file is actually in the highly trusted My Computer zone. From an Internet Explorer perspective, this is an elevation of privilege attack.

The same issues apply to the location.search and location.href properties.

NOTE
Note that these attacks apply to all browsers; however, it's only in Internet Explorer that an attack can include the notion of transgressing zones, because only Internet Explorer has zones. Attacks against local content are less of an issue in Internet Explorer 6 SP1, Microsoft Windows XP SP1, and Microsoft Windows .NET Server 2003 because navigation from the Internet zone to the My Computer zone is blocked.

Look again at Figure 13-1, replace the Internet Web server with an Intranet server, and you'll understand this threat a little better!

Understanding Zones

Security zones, introduced in Internet Explorer 4, are an easy way to administer security policy because they allow you to gather security settings into easy-to-manage groups. The security settings are enforced when you browse Web sites. The main tenet behind security zones is that some Web pages need to be handled with specific security restrictions depending on their host Web site, thereby matching security restrictions with Web page origin. In essence, zones are a form of security policy that is enforced when you browse certain classes of Web sites.

Another goal of zones is to reduce the number of times a user is prompted to make a security decision. If a user is asked to make numerous Yes-No decisions, often the user will end up repeatedly hitting Yes out of frustration without really reflecting on the question being asked.

Internet Explorer employs five zones. The default is in order of decreasing trust: My Computer, Trusted Sites, Local Intranet, Internet, and Restricted Sites.

HTML Help Files

HTML Help files are also potentially vulnerable to local XSS attacks. HTML Help files are a collection of HTML files compiled with the CHM file extension. You can create and decompile CHM files with Microsoft HTML Help Workshop. The attack is mounted by using the mk: protocol handler rather than http:. Treat any CHM files you create as potential XSS vulnerabilities. The same applies to any HTML document that has a non-HTML extension.

XSS Attacks Against HTML Resources

A little more obscure but still worthy of comment is accessing HTML through resources. Internet Explorer supports the res: protocol, which provides the ability to extract and display resources (such as text messages, images, or HTML files) from a dynamic-link library (DLL), EXE files, or other binary images. For example, res://mydll.dll/#23/ERROR will extract the HTML (#23) resource named ERROR from mydll.dll and display it. If ERROR takes input from the URL and displays that, you might have an XSS issue. This means you should treat resource HTML data just like a local HTML file.

More Info
Microsoft issued a security bulletin fixing some resource-based XSS issues in March 2002; see 28 March 2002 Cumulative Patch for Internet Explorer at http://www.microsoft.com/technet/security/bulletin/MS02-015.asp for more information.

Remember that the Windows shell, Windows Explorer, supports the res: protocol to extract and display resources from a DLL. Therefore, you must make sure any HTML resources you include are devoid of XSS issues.



Writing Secure Code
Writing Secure Code, Second Edition
ISBN: 0735617228
EAN: 2147483647
Year: 2001
Pages: 286

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net