Hackers are gravitating toward Web app exploits, so be prepared.
One of the most common and biggest mistakes that companies make is not taking the steps necessary to properly protect their Web site and Web applications.
While exploits through mail, virus, malware, Trojan horses and distributed denial-of-service programs are unfortunately going to be with us for a long time, the fastest-growing area for new exploits is through Web interfaces.
Almost every company has some type of Web presence — ranging from simple brochure sites to sophisticated transaction-oriented applications — and therefore has some type of conduit from the general Internet to company resources and or company data.
Everybody allows a variety of Web protocols and programs directly through their firewalls and routers. Because you cannot stop this traffic from coming through your barrier systems, you have to do an outstanding job of creating an environment that detects malicious attempts that you cannot prevent and prevents as many different types of exploits as possible. To do this, several areas need to be addressed, each in its own way.
A Web environment consists of three main parts:
- The host that the Web services run on.
- The supporting Web server infrastructure.
- The Web application itself.
It is important to understand that these components are independent of each other and that effective Web security depends on getting each of them right. Failure of one part could may mean failure of the system as a whole.
For example, a company may have done a good job deploying a minimally configured and well-hardened host and have a well-configured Web server, but if it has a Web application designed using poor assumptions about authentication, authorization or session management, the system as a whole is vulnerable.
To achieve a robust Web presence, you need to look at each of these three areas and perform the testing and remediation measures each requires.
Step 1: The host
The simplest of the three to protect is the host itself. There are a variety of public domain and third-party tools that identify vulnerabilities on the host supporting the Web server and application. It is best to assume that an attacker is running these same tools, so the first step is to run the tools yourself and take the appropriate steps to resolve any exposures they reveal.
Two security tenets should drive your architecture and the configuration of your hosts:
- Enable only the services that are absolutely necessary to support the Web server and its particular application. Shut off, disable and even remove all software that isn’t needed for the Web environment. You want to minimize the ability of a hacker to exploit weaknesses in tools, libraries or services that aren’t required for the Web environment but might provide a back door for getting access to the system.
- Dedicate systems to the Web environment; do not share them with other Internet-based services. The more services that share a system, the harder it is to secure it,because the configuration moves toward a least common denominator.
Step 2: The Web server
The second component to protect is the Web server itself. Once you know what kind of Web server you are going to use and have decided what services it needs to offer, the easiest way to be confident that it is configured well from a security perspective is to have it independently reviewed by an expert (for example, an Apache wizard with outstanding administrative skills or an Internet Information Server expert with outstanding Windows and Windows services skills).
While some third-party and public-domain tools for analyzing Web-server configurations are available, by themselves they are insufficient. You need to complement the tools with hands-on assessments. Most of them are one-shot testing agents that come to a conclusion about the state of things after probing the server for a certain condition. The problem is that many configuration issues are too complex to be detected by this type of analysis.
Step 3: The Web application
The third and most complex piece of the Web environment is the Web application itself. Unfortunately, security-assessment tools for Web applications are incredibly immature. They have only a shadow of the robustness and reliability of host or Web server tools. Therefore, hands-on analysis of the application by an expert is needed. This is best accomplished by using various standard or specialized browsers, browser and server proxies, and protocol analyzers.
There are a variety of problems that many Web applications share, such as wrongly tying authorization decisions to authentication (such as, once somebody is logged on he has access to anything), not checking input fields to ensure they only have valid data types (for example, a number field should not have characters in it), not filtering input fields at both the client and the server for malformed data, malicious data or injection attempts, or having sensitive information in visible places (for example, in a cookie or embedded in the HTML page).
The fact is that identity theft and access to confidential or private information through Web applications is one of the fastest-growing exploits on the Internet. The reason is that most Web applications have not been developed with a keen eye toward the hostile Internet environment and are not using appropriately secure methods of authentication and authorization.
In addition, the vast majority of Web servers and Web applications do not have instruments to detect and log security events, so most attempts at breaking in go unnoticed.
Johnson is vice president of consulting at SystemExperts Corporation. He can be reached at Brad.Johnson@SystemExperts.com.
