Chapter 12: Canonicalization Issues

When we first began to write this chapter, we were asked whether we could use a word other than canonicalization ”after all, canonicalization cannot be found in most dictionaries. However, the term is used heavily in the computer industry, and several security issues involve canonicalization problems, so we decided it was the best fit for what we describe in this chapter.

Canonicalization refers to the process of converting data into its canonical representation ” its simplest or most basic form. Take a name , for instance: Bryan can be represented in more than one way, including Brian , BrYaN , Br%79an (%79 is hexadecimal for the ASCII value of the letter y ), or even (which uses different Latin letters ). The main point is that often there is more than one way to represent data.

In this chapter, we discuss why you should be concerned with canonicalization issues, the general testing approach for finding common file and Web-based canonicalization issues, different encodings that can be used to bypass security validations, and other techniques to fool the logic of parsers.

Understanding the Importance of Canonicalization Issues

If your application does not use the canonical form of a name when it makes security decisions, you might have security bugs . Lots of known security bulletins involve canonicalization issues. Attackers will use the same techniques discussed throughout this chapter to work around specific blocks an application is attempting to make. An application s parser might be able to handle some checks, but often will ignore other representations of the same data. This mistake can lead to security vulnerabilities that an attacker will exploit. Following is an example of a canonicalization vulnerability in Microsoft ASP.NET that could allow an attacker unauthorized access.

On February 8, 2005, Microsoft released a security bulletin for a canonicalization vulnerability in ASP.NET. Normally, when you access a Web site, the address looks something like http://www.contoso.com/default.aspx ; however, sometimes a forward slash (/) or a backslash (\) can be used to represent the same path .

In this vulnerability, an attacker could bypass the security of an ASP.NET Web site because the parser in ASP.NET did not map the request to the correct URL. So if a Web site secured a request to http://www.example.com/secure/default.aspx using ASP.NET to prevent unauthorized access, an attacker could bypass the security check by accessing the site using http://www.example.com/secure\default.aspx instead.

More Info  

For more information about this vulnerability, see http://www.microsoft.com/technet/security/bulletin/ms05-004.mspx .