Quick tips for Web application security

A traditional firewall is commonly employed to restrict Web site access to Ports 80 and 443, used for HTTP and Secure Sockets Layer communications, respectively. However, such a device does very little to deter attacks that come over these connections. URL query string manipulations including SQL injection, modification of cookie values, tampering of form field data, malformed requests and a variety of other nasty tricks are often given free passage on allowed, legitimate traffic.

A Web application firewall, such as those reviewed in this issue (see review) might help address security holes in Web servers and Web applications, but there is certainly a great deal that network security professional could and should do before and after employing such measures.

So sharpen your pencils: It's time for Web Application Security 101.

Tip 1: Don't trust, authenticate.

If you are in charge of designing or administrating a public Web site, you need to embrace the fact that you cannot trust your users. If you are particularly paranoid, you might extend this concept to an extranet or even an internal site. But the point is that unless the users authenticate themselves with the site somehow, you have no idea who they are and what their intentions might be.

Not to suggest that a hacker hides behind every IP address accessing your site, but can you easily separate legitimate traffic from non-legitimate traffic? Are those excessive 404 errors in your server log simple mistakes or someone probing your defenses? You should always err on the side of caution, and the tips that follow embrace this spirit.

Tip 2: Keep a low profile.

The first step for a potential intruder is to gather information about your Web server and any hosted application. Don't expose anything your end users don't need to know and consider the following simple anti-reconnaissance tactics:

•  Remove personal information from your WHOIS records that might be useful in a social engineering attack and employ a role account instead.

•  Make sure your machine is not named something that indicates its operating system or version.

•  Remove the server header from your Web server's response.

•  Remap file extensions of dynamic pages, for example .jsp to .shtm.

•  Add custom error pages that suppress useful information about the server or associated development platform.

•  Remove comments, particularly those that indicate implementation information or the names of site and network personnel, from HTML, Cascading Style Sheets and particularly JavaScript source.

•  Do not expose sensitive file or directory names in robots.txt file.

You can go deeper with anti-reconnaissance by tweaking your network firewall and server connection settings to fool tools such as NMAP (www.insecure.org) that will try to identify your server via its TCP stack responses. At the HTTP level, you might consider changing your Web server's responses to alter header order, mask session cookie names, and remove other items in the response. A tool such as ServerMask for Internet Information Systems can help you perform many of these masking tricks.

Obviously, the competent Web administrator does not solely embrace security by obscurity. True protection is required. However, inviting attack to test your site's "armor" is foolish; the aim is only to keep potential attackers from easily sizing up defenses and attacking more successfully by giving the site and server the equivalent of camouflage.

Tip 3: Use misdirection and misinformation beyond reducing information exposure.

You should consider using misinformation and misdirection in what you do reveal. Looking like another type of server, pretending to use a different technology or giving contradictory information can trip an attacker into making the wrong types of attacks and clearly signaling his intention. For example, you might add fake "off- limits" directories or file names in a site's robots.txt, comments or error pages so that users or tools with bad intent reveal themselves for monitoring or blocking. Other examples of misdirection include:

•  Randomized network and HTTP server signatures found in the response packets.

•  False administrator names in page comments or network records that are known internally when used to be indicative of a social engineering attack in progress.

•  Decoy servers or honeypots (www.honeypots.org) to confuse intruders.

•  Send varying error responses or make your site "play dead" by sending obvious intruder "500 Server Error" responses for all their requests.

There is a great deal of room to expand on the idea of misdirection. Creating a forest of decoy devices and sites that rotate their signatures could make finding your site a great pain for a potential intruder. A service such as Netbait suggest such thinking is not so wild.

Yet be careful - camouflage will not protect problems, and misdirection might anger an enemy inviting attack. In many cases the tactics will be useless against the "stupid" attack from a robot, worm or script kiddies following a canned script. These folks don't care what they are hitting and hit Apache boxes with IIS attacks and vice versa, so make sure you can handle what they throw at you.