As more and more businesses look to gain the productivity benefits of remote working, they are installing a plethora of dynamic web applications, servers and databases that allow their employees to access their applications from wherever, whenever.
But with remote accessibility comes greater vulnerability to hackers.
Several factors leave web applications open to attack – a lack of traditional network security measures, multitudinous design flaws, and the sheer number of potential hosts. Types of attack range from the theft of user credentials and data to bringing organizations down through denial-of-service and buffer overflow attacks.
High-profile attacks such as MS Blaster and Slammer testify to the potential for damage. Yet only three percent of web applications are secure enough to deter hackers, according to research by the Sims Group in 2003.
In the current corporate-governance climate, such weakness will not be tolerated by customers or regulators.
Design flaws
Configuring a modern web application server and keeping it up-to-date with security patches can be a difficult task, which is usually performed by web developers whose main concern is application up-time, not security.
Improper configurations – including under-used but enabled features, sample files and executables left untouched, and unpatched server software – can lead to multiple vulnerabilities.
The Open Web Applications Security Project (OWASP), a group dedicated to helping organizations recognize the security challenges intrinsic to web applications and web services, has identified a number of flaws in the design of web applications to which the majority of successful internet-based attacks can be traced.
One vulnerability identified by OWASP is the lack of secure access control. Attackers can exploit flaws such as authorization models that include directory traversal techniques, default file permissions and insecure user IDs to gain access to users' accounts, view sensitive files or use unauthorized functions.
Flawed credential management functions can also lead to compromised passwords and session cookies that allow hackers to assume users' identities and gain access to sensitive data.
Web application designers should use encryption to help protect their programs. However, this does not always work, as Bruce Schneier, author of Secrets and Lies, points out: "We use preventive measures such as encryption and access control to avoid different threats. If we can avoid the threats, we've won. If we can't, we've lost. Imagine my surprise when I learned that the world doesn't work this way."
Developers are often unaware of the importance of validating user input. Also, most web application architecture is multi-tier and it can be very difficult to predict how user input will be used across all tiers. Improper error handling can also help a hacker tailor his attack to the products and technologies in use. One way to handle this problem is to create a generic error message with a random user ID that links to a log.
Web applications are particularly susceptible to application-based denial-of-service (DoS) attacks. Such attacks can be made simply by opening too many requests. A single host can generate enough requests to consume all available resources on the web- and application servers; it is very difficult for the web server to distinguish between a legitimate request and an attack.
Organizations can prevent denial-of-service attacks by using software such as Web Intelligence (see panel), which verifies that a request is genuine. This prevents most of the known HTTP attacks. In addition, a policy-based management solution, such as Floodgate, can limit the throughput and bandwidth consumption of a specific URL and even put a quota on the amount of network sessions from a specific host, excluding known hosts.
Detect and protect
Authentication is one part of the web security process, but even solid authentication mechanisms can be undermined by flawed credential management functions.
Consistent and strong authentication security across multiple platforms can be difficult to maintain and might not be consistent between web applications. The solution is to provide strong authentication processes that are separate from the web application itself; the management of active sessions requires a strong session identifier that cannot be guessed, hijacked, or captured.
However, this is only the first step. Even authenticated users can do damage; only sophisticated access control mechanisms will ensure users are kept within secure areas. This requires a strong authentication policy. This might involve the use of tokens or hard-to-break passwords, but the most important thing is that it is designed into how the applications are accessed and used in day-to-day work.
Protection from the injection of malicious code calls for a security mechanism that can inspect the traffic and block command injections. Once the code is uploaded to the web server, it is impossible to distinguish from legal scripting code that belongs to the web application. If scripting code cannot be injected into the web application, it cannot harm the end user.
Appropriate security products should include built-in support for protocols such as DES, DES3, AES, IPSEC, SSL, TLS and so on, along with high-quality encryption. An important step is to shift the burden of implementing encryption away from web developers to security vendors.
"Header Cloaking" is another useful tool. This hides the identity of the web server from automatic scripts running across the internet looking for vulnerable web servers. While a dedicated hacker can still identify the web server type, most attacks come from script kiddies or worms that run automated scripting and Header Cloaking can outwit many of these tools.
Attack focus: buffer overflow
Buffer overruns are a serious headache for web security. These are dangerous because, with some effort, arbitrary code can run on the web application host machine. Some include automatic propagation mechanisms that allow an attacker to infect whole networks within minutes. Just think back to 2001 when Code Red exploited a vulnerability in the application program interface of Microsoft IIS and caused $2.6 billion of economic damage.
Such attacks can infect hundreds of thousands of hosts within hours, so waiting for a signature-based solution is not a viable defense. While it is hard to detect unknown buffer overflows, some basic steps can make them much harder to implement. The best solution is an intelligent application that inspects web traffic for malicious executables. The Malicious Code Protector in Check Point's Web Intelligence solution can detect unknown buffer overflows.
Other defenses include limiting URL and HTTP headers, thus minimizing the chance that executable code can be run if an overflow does occur; disallowing usage of binary characters in requests to make assembly of executable code much harder for the attacker; and blocking binary characters in web forms.
Technological solutions are, of course, the building blocks of web security. However, as is so often the case, people and processes can make all the difference. Organizations need to take web security into account when they design their security policies and security managers need to be involved in designing web applications in order to prevent flaws being built into programs. And whatever measures you take must be subjected to stringent testing; it does not matter how high you build the walls if carelessness leaves one door open.
Niall Moynihan is technical director of Check Point Software Technologies
