A quick glance through the CERT Coordination Center Web site and other security-related information clearinghouses shows that attackers choose a variety of approaches to achieve their goals. Often targeted are packaged applications, such as Microsoft Outlook and networking protocols such as Session Initiation Protocol.

You'll also find many security alerts and advisories about vulnerabilities in Web application technologies. But businesses (and even consumers) who host publicly accessible and internal Web applications often give short shrift to the threat posed by deploying vulnerable Web applications.

There is a variety of reasons why people don't pay as much attention to Web application vulnerabilities as they should. For starters, creating and deploying Web applications usually involves multiple individuals, such as system administrators and software developers. Quite frequently, insufficient communication between these people and lack of clear security responsibilities lead to a rich source of entry points for attackers.

In addition, businesses and consumers can choose from a wide array of available Web technologies to build applications. You may be using multiple tools, including PHP, Perl, Java Server Pages, Active Server Pages, Servlets, or other technologies. Keeping track of all the advisories that may impact the technologies you use can be mind-boggling. Some higher-end automated patch-management tools are capable of helping out in this area, but in many cases, small and medium-size businesses and consumers are on their own in this regard, given the cost of these tools.

Web application security is also tricky due to external Web hosting and outsourcing arrangements. You might have contracted with an ISP to host your site or hired one or more Web pros to build the application functionality you need. Yet, how can you be sure that your ISP or outside application guru is factoring security into the equation?

To gain the upper hand on Web application security, businesses and consumers should educate themselves on the most common methods an attacker might use to compromise a Web application and the resulting impact. Then, by asking a lot of questions of those that create and maintain your Web applications, you can be fairly certain that your Web applications are as impenetrable to attackers as possible. In particular, if you hire external talent, be sure to include language in the contract that will ensure the security of your Web applications.

Let's look now at some of the more common ways Web application security can be compromised.

Server configuration errors

Once created and deployed, Web applications will likely be executed using a Web server (such as Apache) and frequently an application server (such as WebSphere), too. These server technologies are mature and proven to be reliable. However, if they're misconfigured, unauthorized people can easily compromise them. Once in the hands of a capable attacker, a server break-in can lead to data theft or loss, network attacks, and more. Secure servers need to be your first line of defense against attackers.

Whether you manage your own Web servers and application servers or you have someone do it for you, there are a variety of configuration issues that can leave the door open for attackers. Chief among these are: unpatched server software; improperly set directory and file permissions; server services that are active, but not used; default accounts and passwords; leaving default or sample configuration files and scripts on the server; enabling directory listings.

No matter which Web or application server you use, be sure to obtain security documentation for it and carefully configure all settings as described by the vendor. If you have contracted with an outside provider, ask them to document your configuration and compare that information to what the vendor suggests.

Unprotected administrative tools

Web servers and application servers usually include one or more administrative interfaces. For example, application servers will likely have a console where applications can be monitored and user access-controlled. Likewise, one or more tools are usually included to make it easier to deploy applications or define how data is to be accessed. In the wrong hands, these tools can spell trouble for your Web applications.

The best thing to do in this area is to find out how your Web applications are administered. Can administrators remotely access the tools across the public network? What authentication and encryption methods are in place to protect these tools? Can these tools be used to run external commands? Ideally, the administration tools should only be remotely accessible via a back-end interface reachable only via a protected connection, such as a VPN. Administrators should use both encryption and authentication to access the tools. In addition, access to administrative tools and external command interfaces should be tightly restricted. For those using external hosting services, ask your provider for a detailed description of how your Web applications are administered.

Poorly implemented encryption

Many Web applications now routinely use encryption to secure sensitive data as it traverses the public networks, or for server storage. However, mistakes in encryption can easily make your data vulnerable.

Some of the more common mistakes made when implementing encryption include improper SSL certificate setup, use of default certificates, using self-signed certificates, failure to encrypt data within a portion of a Web application, and improper storage of encryption keys, certificates, and passwords.

The easiest way to insure that encryption issues won't leave you vulnerable is to use it only on the data that must be protected. In addition, you might consider hiring an outsider who is skilled in encryption and charge that individual with performing a code review to ensure that you are using encryption properly.

Issues with access control

Access control, which usually occurs when someone accesses your Web application (often after authenticating), is the technology that ensures content is made available only to authorized users. Access control can be implemented at a file or component level, controlled by the Web server or the application server, or inserted by developers of the application.

If your access control is not well thought-out and tested thoroughly, unauthorized users can access data and content for theft purposes or as part of an act of virtual vandalism.

The best way to approach access-control technology is to first decide at which layer you will implement it. Secondly, capture access-control details in your security policy. Define carefully which groups and users can access what data and content. Test all access points in the site. If you host your Web applications externally, you might want to hire a security pro to validate access controls.

Request validation problems

Your Web application likely uses HTTP requests to determine which steps to take next for a particular user. Attackers may frequently manipulate parts of an HTTP request, such as a query string, cookie, or a hidden field that you might be using.

If your Web application is not validating incoming HTTP requests in a centralized way before acting on them, you could be leaving yourself wide open for attack. Many Web applications do validation of incoming requests, but only on the client-side of the application. Attackers can easily bypass client-side validation techniques. Thus, your Web application should perform validation of incoming requests on the server before allowing any further interaction. In particular, your validation procedures should check data types, lengths of requests, null values, required parameters, legal values, and so on.

Even more security issues

The list of potential attack avenues on Web applications grows day by day. Other frequently used attack methods include cross-site scripting, parameter passing, and accessing non-protected accounts or session data. Attackers also like to take advantage of those times when your Web application doesn't handle events properly. And then there is the ever-popular buffer overflow attack.

What can you do?

Consumers and small and medium-size enterprises will likely not have the same tools and resources available to larger organizations simply given the costs involved. However, this does not mean that you can't protect yourself or reduce your risk of Web application attack.

The first step in preventing Web application attacks is to become more knowledgeable about the methods used by attackers. If you can afford it, hiring a consultant to conduct a security audit of your applications is also a good idea. More likely though, you'll want to investigate one or more of the no-cost and low-cost tools available to test the vulnerability of your Web applications. We'll examine some of these tools in next month's Security Advisor.