Secure Your Web Application’s I/O

These days, Web administrators focus most of their attention on securing OSs, routers, and firewalls. But securing your network devices from outside intruders does little good when attackers can use a Web application to drill to the center of your network. Therefore, securing your Web applications is just as important as securing your Web servers and workstations.

By definition, a Web application accepts input from and returns output to the network. Most Web site exploits take advantage of deficiencies in these I/O interfaces. Intentionally or not, Web applications often accept inappropriate input or return inappropriate output, which can leave security holes for intruders to exploit. For example, leaving your Web application's I/O unsecured can expose sensitive information about your system's configuration, your users, and your customers. Intruders who obtain this information can use it to crack your system, impersonate valid users, or steal customer information, which can lead to civil lawsuits or prosecution for violating privacy laws. To avoid such problems, you need to first secure your Web application's output, then secure its input.

Securing the Output
Securing your Web application's output is crucial because intruders can easily exploit unsecured output and cause a lot of damage. To secure the output, you need to remove sensitive data, make session IDs difficult or impossible to discern, secure cookies if you use them, be prepared for good systems to go bad, prevent Cross-Site Scripting attacks, and avoid using Basic authentication.

Remove sensitive data. Web applications often receive and transmit sensitive data, so you need to sufficiently protect that data from unauthorized viewers. To begin, you need to remove from the HTML pages that the application returns to users any sensitive data that isn't explicitly required. For example, an HTML page might include hidden frames to hide data from users. Using hidden frames to hide data works only if the users don't know how to view a page's source code in their browser (e.g., by selecting the Source option on the View menu in Microsoft Internet Explorer—IE). For that reason, using hidden frames is a poor way to secure data. Don't use hidden frames, except maybe to tidy up a window of nonsensitive data.

To determine whether your Web site uses hidden frames, you can perform a text search for the keyword Hidden in the HTML pages' source code. You should search for strings such as TYPE="hidden". If the hidden data is sensitive, you should rewrite the code to remove the data from the page.

Other keywords to search for are Action and Get. The presence of the Action attribute means that the page is going to perform a function, such as sending data from a Web form to the Web server. You use the Method attribute to specify how to send the data. You have two options: GET and POST. Typically, Web administrators use the GET method to send small amounts of data, whereas they use the POST method to send large amounts of data.

To get the data to the server, the GET method embeds the data in a URL, which means that URLs might contain sensitive information. For example, a URL might contain a user's name and password (e.g., http://www.acme.com/bin/query?user=tony&pass=12345). This URL not only appears in the Address text box of the user's browser but also is recorded in multiple places, including the user's Web browser history, Web server logs, proxy logs, firewalls, and even on unrelated Web servers visited through the HTTP-Referer field.

Using the POST method is a safer way to transfer data. This option embeds the data in the body of the HTTP request. The key here is that the data isn't part of the header, which is typically what most systems track and record. Thus, if a search reveals that your HTML code uses the GET method to transfer data, you need to rewrite the code so that it uses the POST method.

Make session IDs difficult or impossible to discern. Session IDs can help you track users' activities on your Web site. You can often see your session ID embedded in the URL of the Web page you're accessing. For example, when I visited an e-commerce site, the URL was http://generic-ecommercesite.com/php-bin/gig_display.php?sid=400305. (I changed the name of this e-commerce site.) This URL shows that my session ID was 400305. When I again logged on to that site a few minutes later, I received a session ID of 400324. By comparing these session IDs, I learned that the site was handing out sequential session IDs. Issuing sequential session IDs isn't a secure practice. If I were to change the URL's session ID to 400323 and press Enter, I would be logged on as the person who accessed the system just before me. Issuing session IDs that fall within a range of values isn't secure either because intruders can usually figure out a valid session ID fairly quickly. Instead, you should make the session IDs exceptionally large numbers and randomly generate them. Even better, you should encrypt the session IDs. For example, my bank's online service encrypts session IDs. Discerning someone else's session ID from a URL such as https://bigbanking.com/cgi-bin/session.cgi?sessargs=UbIJPnF)uz7BRhMQPhiUeZxlDTTGKUOyofbnVupJ2CM= is nearly impossible.

Secure cookies if you use them. When designed improperly, cookies can represent a security threat. An intruder program such as CookieMonster can use a poorly designed cookie to gather information from users' hard disks.

Cookies consist of several fields. One of those fields contains four parameters—Domain, Path, Secure, and Expires—that you can use to secure your cookies. The Domain parameter specifies the domain to which the Web server can send cookies. Some Web administrators simply specify .com as the cookie's Domain parameter, which means that any .com server can request that cookie—a dangerous practice. Instead, you should set the Domain parameter to your domain's name so that other Web sites can't request your cookies. The Path parameter lets you further limit requests for cookies within your Web site. If you set this parameter to a path that leads to your Web site's secured area, the Web server will send cookies to that area only. Setting the Secure parameter to Yes ensures that the Web server transmits cookies only when Secure Sockets Layer (SSL) is in place. That way, the server never transmits cookies in clear text. The Expires parameter specifies when cookies expire. You should set a reasonable expiration date so that the cookie doesn't remain forever on users' hard disks.

   Previous  [1]  2  Next