When it comes to the Internet and web-based applications, many situations are unique to this area. Rarely are threats of vandalism an issue in typical computing environments. Also, the potential risk for fraud is higher due to the universal availability of these applications over the Internet. The reason we are using the Internet is to expose our product or service to the widest possible audience. We smartly put these web servers in the DMZ so those who access these servers don’t have direct access to our other internal servers. One of the unfortunate issues when using web-based applications is that you need to allow the Internet to access them in order for them to function, so you must open up the ports related to the Web (80 and 443) on your firewall—so now any attack that can come through on these ports is “game on.” The alternative to developing your own web application is using an off-the-shelf variety instead. Many commercial and free options are available for nearly every e-commerce need. These are written in a variety of languages, by a variety of entities, so now the issue is “Whom should we trust?” Do these developers have the same processes in place that you would have used yourself? Have these applications been developed and tested with the appropriate security in mind? Will these applications introduce any vulnerabilities along with the functionality they provide? Does your webmaster understand the security implications associated with the web application he suggests you use on your site for certain functionality? These are the problems that plague not only those wanting to sell homemade pies on the Internet, but also financial institutions, auction sites, and everyone who is involved in e-commerce.

The following are some common input validation attacks:

• Path or directory traversal - This attack is also known as the “dot dot slash” because it is perpetrated by inserting the characters “../” several times into a URL to back up or traverse into directories that weren’t supposed to be accessible from the Web. The command “../” at the command prompt tells the system to back up to the previous directory (try it, “cd ../”). If a web server’s default directory was “c:\inetpub\www”, a URL requesting http://www.website.com/scripts/../../../../../windows/system32/cmd.exe?/c+dir+c:\ would issue the command to back up several directories to ensure it has gone all the way to the root of the drive and then make the request to change to the operating system directory (windows\system32) and run the cmd.exe listing the contents of the c: drive.


• Unicode encoding - Unicode is an industry standard mechanism developed to represent the entire range of over 100,000 textual characters in the world as a standard coding format. Web servers support Unicode to support different character sets (like Chinese), and, at a time, many supported it by default. So, even if we told our systems to not allow the “../” directory traversal request mentioned earlier, an attacker using Unicode could effectively make the same directory traversal request without using “/”, but with any of the Unicode representation of that character (three exist: %c1%1c, %c0%9v, and %c0%af). That request may slip through unnoticed and be processed.


• URL encoding - If you’ve ever noticed that a “space” appears as “%20” in a URL in a web browser (Why is it only me who notices that?), the “%20” represents the space because spaces aren’t allowed characters in a URL. Much like the attacks using Unicode characters, attackers found that they could bypass filtering techniques and make requests by representing characters differently.

These are just a few attacks, and many more are cover in the Shon Harris CISSP Course!