The proliferation of Web-based applications has required security VARs and integrators to add installation, configuration and support for Web application firewall appliances to their array of services. These products have gained attention for their role in aiding Payment Card Industry Data Security Standard (PCI DSS) compliance (PCI Requirement 6.6 mandates either a review of all Web application code developed in-house, or the installation of an Web application firewall to protect against known attack methods), but they've become a necessity for any organization that provides Web access to its applications.
Traditional network firewalls are not a sufficient means of Web protection. While they remain necessary to protect other network components, they cannot protect Web-based applications. This tip will provide a brief introduction to Web application firewalls, explaining what they do and how they work, the types of attacks they help thwart and the reasons why they are superior to Web application code reviews.
What is a Web application firewall?
Web application firewalls are designed specifically to protect Web-based applications, as opposed to traditional firewalls, which monitor and block packets based on Internet address and port number. A standard port number is defined for each network application type. For example, telnet receives packets addressed to port 23; mail servers receive packets addressed to port 25. A traditional firewall allows packets addressed to the Internet address corresponding to a mail server and to port 25 to pass through and reach their destination. A packet addressed to port 25 with the Internet address of a system that is not a mail server is an attack. The firewall blocks these packets.
Web servers expect packets addressed to port 80. All packets addressed to port 80 on the system supporting the Web server must be allowed to pass through the firewall. Traditional firewalls have no way of determining whether a properly addressed packet contains a threat, but Web application firewalls carefully examine packet contents to detect and block threats.
How Web applications are attacked
Hackers constantly develop new methods to gain unauthorized access to Web applications, but there are several common techniques.
- SQL injection: Some applications create database queries by copying Web client input. Hackers construct input query strings, which if not carefully inspected and rejected by the application, return confidential data.
- OS command injection: Some applications create operating system commands from Web input, such as accessing a file and displaying the contents. If input strings are not carefully checked, hackers can create input that displays unauthorized data or modifies files or system parameters.
- Session hijacking: Hackers gain access to a logged-in session by guessing the contents of a session token based on knowledge of token format. This enables the hacker to take over a session and access the original user's account information.
- Parameter or URL tampering: Web applications often embed parameters or URLs in returned Web pages or update cookies with authorization parameters. Hackers can modify these parameters, URLs or cookies to cause the Web server to return information that should not have been exposed.
- Buffer overflows: Application code should always check input data lengths to ensure that input data doesn't overflow the end of a buffer and modify adjacent storage. Hackers quickly learn about applications that fail to check for overflows and create input that causes this error.
How to block Web application attacks
Web application firewalls examine the contents of each incoming packet to detect the types of attacks noted above. For example, Web application firewalls scan SQL query strings to detect and delete a string that will return more data than is required by the application. VARs should carefully monitor newly developed attack types and track updated products that detect them.
Web application firewalls not only detect known attack types like those listed above, but also monitor for unexpected usage patterns to detect previously unknown attack methods. For example, Web applications typically exchange limited amounts of information with Web clients. If the Web application firewall detects a case where the Web server is returning a much larger than expected amount of data, it will cut off the transfer before more data is compromised.
Both software- and appliance-based Web application firewalls are available. Software products reside on the same system as the Web server, while appliance placed products are placed between the Web server and the interface to the Internet. In both cases the firewall inspects incoming data before it reaches the Web server and outgoing data after it leaves the Web server.
Software products are in many cases less expensive than appliance-based, and vendors claim lower latency and higher throughput. Installing additional software on the system supporting the Web server adds additional processing load and increases software complexity on the system.
Appliance vendors claim simplified installation and support since no additional software is installed on the system supporting the Web server. Web server performance is not impacted by processing on the Web application firewall.
In addition to commercial products, there are a number of open source Web application firewalls available as well. These products are less expensive than commercial products (as they are either free, in the case of pure open source tools, or likely reduced in cost, in the case of commercial products based on open source code). A concern in the past with open-source has been that hackers will examine the code and find ways to evade protection. Experience with widely used open-source software such as Linux has shown that this has not been the case.
All products, whether purchased or open-source, software or appliance based, must be supported. Commercial products are supported by their vendors. Open-source products provide an opportunity for VARs and integrators with extensive security expertise. Providing ongoing support for the Web application firewall ensures that the partner maintains a close relationship with the customer offering future opportunities to provide additional products and services.
Because each customer environment and application set is different, VARs and integrators must evaluate each customer's unique needs in order to determine which type of Web application firewall would be the best fit. However, there's no question that all customer Web applications should be protected by a Web application firewall. If customers don't understand the need or disagree with that assertion, be sure to introduce them to the many ways Web applications can be attacked.
Careful application code inspection is an alternative to Web application firewalls. Attacks are successful where coding errors or lack of internal data checking permit them. In theory, a program in which code reviewers pour over Web application code line by line looking for errors can negate the need for a Web application firewall.
In practice, despite the fact that software engineers typically believe their code is without flaw, the constant updates to applications make such careful review nearly impossible, not to mention code reviewers can easily fail to spot insecure code, especially those that don't have a security background. Also, hacker techniques evolve rapidly. Web firewall vendors monitor news of new attack types and update their products quickly. Some customers may think a code review program can enable them avoid the expense and effort of a Web application firewall implementation, but solution providers should help customers understand that the false sense of security code review provides is really no substitute to the comprehensive security provided by a Web application firewall.
About the author
David B. Jacobs of The Jacobs Group has more than twenty years of networking industry experience. He has managed leading-edge software development projects and consulted to Fortune 500 companies as well as software start-ups.