I was looking through the Attack Components list for Input Validation and it
appears to me that there is a class of attacks not fully addressed. The
Unicode Strings and URL encoded strings belong in a class of bug that
Michael Howard terms "Canonicalization" bugs in his book "Writing Secure
Code". There is an entire chapter about Canonical representation issues in
the book, but I'll try to briefly describe it here for the list.

The web application makes security decisions based on a string (a URL, an
HTTP Header, a Cookie value), and if there the string can be represented in
another, non-canonical , form, the application can make an incorrect
decision. Let's use the two examples above.

- Unicode representation, this is classic.
http://www.victim.com/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir. The
canonical form of this URL and the one that is executed by IIS is
http://www.victim.com/winnt/system32/cmd.exe?c+dir. So, an incorrect
decision was made that cmd.exe was in the /scripts directory and hence
executable and it also bypassed the parent paths check.
- URL encoded input, a contrived example here is that you could access a
secure directory by encoding part of the string, such as
http://www.victim.com/%73ecure which would have the canonical form
http://www.victim.com/secure.

My point is, there are many MORE examples of similar type of problems that
are not part of the Attack Components. Does it make sense to individually
list these in the Input Validation section, or create another subsection,
possibly canonicalization attacks. The way it is grouped isn't that
important, but if look at the problem as Canonical representation bugs, we
can work to identify all the problems that fall under this category. Here's
a list of some similar bugs off the top of my head.
- ::$DATA
- +.htr
- Trailing-dot
- UCS-2 Unicode encoding
- UTF-8 encoding
- Double encoding
- ANY type of encoding the app/OS understands. For example, foreign
languages.
- Dotless IP http://3232286052/ is really http://192.168.197.100
- FAT32 filesystem names SECRET~1.TXT can be SECRETFILE.TXT
- Relative file names vs. Absolute filenames
- UNC file names
- \\?\ format in Windows

BTW, All credit goes to Michael Howard for the canonicalization
classification and his new book is excellent. Most of the bugs are above are
described in the book.

Dave Wong

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]