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.
