Another way to secure cookies is to encrypt them. In addition, you might want to make your cookies comply with the Platform for Privacy Preferences (P3P) standard, which sets limits on how you can use cookies. For information about this standard, see the P3P Web site (http://www.w3.org/p3p).
Be prepared for good systems to go bad. No matter how good your Web application is, the possibility exists that it might crash someday. Web applications can produce dangerous output when they aren't working. Error messages can provide valuable information to intruders probing your defenses. For example, error messages can reveal the type of application and the application's version number, so intruders know the types of exploits they can deploy. Error messages can reveal a Web application's structure and subroutine names, which might be callable from a Web browser. In the worst case, a Web application might spit back sensitive data, some of which might not belong to the user receiving the error message.
Although you can't predict when your Web application will go awry, most applications support scripted error-handling. You can write a script that displays a simple We are sorry message and provides a nonsensitive error code for the technical support staff. This solution lets you be friendly to users yet unaccommodating to intruders.
Prevent Cross-Site Scripting attacks. You need to protect users from your Web application's output. This statement might sound strange, but intruders can use an exploit called Cross-Site Scripting, in which an email message, a forum discussion, or another medium lures users to an intruder-controlled Web site that has a link to another site, typically a trusted, well-known site (e.g., a major vendor's site, a site with a search engine). When a user clicks the link, the intruder-controlled Web site directs the user to the trusted site but also enters invalid input on the trusted site's input form (e.g., a logon screen, a search page). Embedded in that invalid input is a malicious program that runs as soon as the trusted site returns a message that says something such as Sorry, we can't find X, where X represents the malicious code. Because the user is on a trusted site, he or she will probably let the program run despite a warning message, or the user's browser might be set to automatically accept code from that trusted site.
To prevent intruders from using your Web site for Cross-Site Scripting attacks, you need to filter your Web application's output. IIS 6.0 includes output filtering. Although Microsoft released an output-filtering patch for IIS 5.x and IIS 4.0 last year, new Cross-Site Scripting attacks have come out as recently as April 2002. To protect your IIS 5.x and IIS 4.0 servers from these most recent attacks, you need to download the cumulative patch from Microsoft Security Bulletin MS02-018 (Cumulative Patch for Internet Information Services—http://www.microsoft.com/technet/security/bulletin/ms02-018.asp).
Avoid using Basic authentication. Your authentication process can include sensitive data in its output. Web administrators commonly use the Basic authentication method that's built into the HTTP standard to authenticate Web users. Unfortunately, this method has two serious security shortcomings. First, it includes the user's logon information in the header of every transmission but doesn't encrypt that information. Figure 1 shows a sample HTTP header from a Basic authentication session. Notice the gibberish at the end of the last line. That gibberish is a username and password encoded as a base-64 string. Encoding isn't the same as encrypting, so intruders can easily extract the logon credentials. Second, the Basic authentication method is vulnerable to brute-force attacks. When users receive an Access denied message after three bad logon attempts, they can click Reload or Refresh and get another three tries.
As its name implies, Basic authentication offers only limited protection from unsophisticated attacks. A more secure solution is using SSL with Basic authentication. This solution solves the header problem because SSL encrypts the header data. However, using SSL with Basic authentication doesn't prevent brute-force attacks. Thus, an even better alternative is to use form-based authentication.
As a side note, when a user logon fails, don't provide informative messages such as User doesn't exist or Password invalid. Such messages let the intruders gather valid usernames that they can eventually use in a brute-force attack. A simple message such as Logon failed. Please try again gives a valid user enough information to act without giving away useful information to an intruder.
Securing the Input
Web applications act on users' input. Whether the input is a username and password, a database query, or an order submission, this data, by definition, is coming from an untrusted source. I'm not saying that you shouldn't trust your users, customers, or vendors but rather that you shouldn't trust any data coming from the Web. You have no way of knowing whether that's really Jane Doe from accounting or Joe Hacker from Romania entering that data. You must always assume the worst.
The vast majority of serious security holes in Web applications result from buffer overflows. You could easily avoid this sad situation if the applications were written properly to begin with. However, buggy software isn't going away, so a good plan is to implement a routine that checks the input that users enter in your Web applications. The routine should filter all input fields—even seemingly innocuous fields such as name or address—for size, content, and format.
In UNIX systems, the semicolon (;) and question mark (?) are special characters that tell the OS to take some action. Similarly, in Windows systems, the slash (/) and angle brackets (< >) are special characters. Intruders might include a slash in their input to try to perform a directory traversal and back their way into the directory tree so that they can go where they aren't supposed to be. And if you find angle brackets in users' input, someone is embedding HTML tags.
You have several ways to secure your Web application's input. One option is to permit only regular characters and numbers in the input. Another option is to filter out slashes, angle brackets, and any escape characters specific to your OS. Listing 1, page 4, contains sample code that you can use in a Web application's input forms to filter out special characters. (The code samples are courtesy of Jeff Forristal, "Maintaining Secure Web Applications," http://www.nwc.com/1105/1105ws1.html, and David Rhodes, Auditing Web Applications, SANS Institute, 2001.) If your application requires users to include special characters in their input, you can permit only those characters that the application needs and reject all others.
If you're running IIS, you can take advantage of Microsoft URLScan 2.0. This program filters all input to your Web server, so you can stop dangerous content before it reaches your application. URLScan works on IIS 4.0 and later. You can download the free program from the Microsoft Windows 2000 Web site (http://www.microsoft.com/windows2000/downloads/recommended/urlscan/default.asp).
Besides filtering input, version 2.0 of the program lets you change the server name in the header that the Web server gives to any browser that visits your site. Changing the server name makes the intruders' job that much more difficult: Imagine their reaction when they see you're running HAL9000. To change the server's name, you simply place the new name in the AlternateServerName field in your urlscan.ini file. You can also have the Web server return a blank server name by changing the value of the RemoveServerHeader field from 0 to 1. However, be careful when changing URLScan's default configuration because incorrect settings can damage your Web site. (For more information about the tool, see Randy Franklin Smith, "Protect Your IIS Server with URLScan," page 6.)
Resources Well Spent
Spending time and money to secure your perimeter and host defenses is a good investment. However, you also need to expend resources to make sure your Web applications aren't letting in or leaking out information that could be dangerous to your network, your users, or your customers. Patching up the security holes in your Web application's I/O will lessen the chance of unwanted visitors causing havoc on your Web site.
End of Article
Register
