Chapter 11: Canonical Representation Issues

Chapter 11

Canonical Representation Issues

If I had the luxury of writing just one sentence for this chapter, it would simply be, Do not make any security decision based on the name of a resource, especially a filename. Why? If you don't know, I suggest you reread the previous chapter. As Gertrude Stein once said, A rose is a rose is a rose. Or is it? What if the word rose was determined by an untrusted user? Is a ROSE the same as a roze or a ro$e or a r0se or even a r%6fse? Are they all the same thing? The answer is both yes and no. Yes, they are all references to a rose, but syntactically they are different, which can lead to security issues in your applications. By the way, %6f is the hexadecimal equivalent of the ASCII value for the letter o.

Why can these different roses cause security problems? In short, if your application makes security decisions based on the name of a resource, such as a file provided by an untrusted source, chances are good that the application will make a poor decision because often more than one valid way to represent the object name exists. All canonicalization bugs lead to spoofing threats, and in some instances the spoofing threats lead to information disclosure and elevation of privilege threats.

In this chapter, I'll discuss the meaning of canonical, and in the interest of learning from the industry's past collective mistakes, I'll discuss some filename canonicalization bugs and Web-specific issues. Finally, I'll show examples of mitigating canonicalization bugs.