Web Application Firewall

The Perceptions of Web Application Firewalls

Difficult to configure. Confusing to use. Time-consuming to manage. Set-it-and-forget-it security. These are some of the perceptions of Web application firewalls that can be, in many cases, dangerous to the security health of your organization. Like physical exercise, exercising good security practices requires effort and commitment, but at the end of the day, the benefits far outweigh the costs. This may be news to some, but a Web app firewall is not a set-it-and-forget-it security crutch. Rather, a Web app firewall is a security tool that requires dedicated use. Most importantly, the Web application firewall isn’t a sentient being, it’s a device that, like many of man’s creations, is only as good as the person or people wielding it.

A State of Mind

Security is never a feature you can outright purchase. It’s not a box you can check, or a test you can pass and be done with. This rationale applies to security whether it be for a car, a home, or your Web apps. This is a concept most people can grasp in more physical, trivial day-to-day tasks, but sometimes is lost when it comes to the Web. For example, driving to and from work is potentially very dangerous. However, if you practice, get your license, and drive with caution, while avoiding activities like speeding and texting while driving, you will -in all likelihood – be safe. No one would get into the driver’s seat of a car for the first time and expect passive safety features like a seat belt and airbag to make up for their lack of experience. The same applies to Web app firewalls; there are measures of practice that must be applied in order to achieve security, one cannot rely solely upon passive features to do all the work. Web app firewall users need to be active drivers, not passive ones. Here are some tips to help keep in an information security state of mind, and become an active Web app firewall driver.

Think in Layers

Don’t: Put up only a single obstacle to prevent vulnerability exploits.
Do: Use a Web app firewall as one layer in a multi-layered wall.
Why: Most code in applications isn’t perfect (really, none of it is, but even if it was finding legitimate paths of entry via proper authorization information is possible). This means there are flaws in it that can be exploited by attackers. However, flaws or vulnerabilities oftentimes cannot be easily fixed or recognized. Security should be thought of in layers, with each layer serving its own purpose and no layer being responsible for the entire load. Think of home security; you may have a fence, locks on your doors, and an alarm. A WAF should only constitute a single layer in a larger defense scheme.
How: A Defense in Depth strategy. This type of strategy aims to create a series of backup measures in case one layer fails, which allows each security tool to perform within its functional specifications and not put the entire job of security on one layer. This strategy can also be thought of as a funnel, with broader measures at the top leading down to the most specific security functionality at the base, in the form of a Web app firewall.

Firewall

Block traffic going to all ports other than Ports 80 and 443. This will funnel traffic into those two ports for inspection by the other layers of security behind it. Wendy Nather wrote a piece on why we still need firewalls that nicely explains their usefulness.

IDS

Detection is needed to alert a system admin if and when an intruder is recognized in the application. Being aware of an intruder’s existence inside the app allows for a potential attack to be identified before the attack has commenced. This will give a system admin time to take additional preventative measures to prevent an attack, such as blocking the IP or logging off a user account if its been taken over. This will provide a more general security detection solution that will alert when intrusions occur at the network and system levels, not specifically within an application, as an app firewall would.

IPS

An intrusion prevention system will prevent an attacker from gathering information on your app and sever. It’s essential to prevent hacker reconnaissance by obfuscating information like server type, file extensions, and application or site errors from being easily accessible to hackers. This is again a more system and network level approach.

Application firewall

Finally, your applications will require an app firewall to secure them specifically, as they are valuable centers of information with large amount of traffic going in and out. A Web app firewall can monitor, detect, and prevent malicious traffic accessing applications.  With active usage, a Web app firewall will act as a powerful last line of defense for your Web apps against attacks.

Shrink Wrap Your Security

Don’t: Expect a WAF to be correctly configured for your site out of the box.
Do: Set up your Web application firewall for your specific needs.
Why: Shrink-wrapping a Web app firewall’s security to tightly fit around your specific requirements leaves less room for error. Simply using a blacklist of attack signatures is a good way to get hit by a Zero Day, and whitelisting could lead to false-positives.
How: Set app specific policies that only allow an app to be used the way it was intended. Any vulnerabilities found through penetration testing that cannot be easily remediated should have app firewall policies put in place to protect until corrections can be made to the vulnerable code. Setting some of the below policies in your Web app firewall is a good start to shrink wrapping security.
Input validation.  Configuring a Web app firewall’s input validation policies will help prevent against attacks like SQL inject and cross site scripting (XSS).  Platform-specific exploits can use complex URL strings to gain access to a shell or a Common Gateway Interface (CGI), from which a hacker can easily get a directory listing revealing file structure. Input sanitizing prevents harmful scripts from being injected into your app through URLs or form fields and should be enabled on an app firewall. This should be configured depending on the characters permitted and needed in each individual field.
Use different configurations. Like customizing input sanitizing, if you need to secure – for example – an Exchange server and a Joomla site, do not use the same configuration for both. Just as a house with no windows will need different security than a glass house, different Web apps will have their own security needs that should be addressed independently.
Manage file uploads. If users can upload files, only allow the file types your site uses. This means things like preventing dynamic files from being uploaded if your site only hosts images. A Web app firewall should be configured to block any attempt to upload files that your app or site does not use. Be sure to be as specific as possible by either whitelisting only what you will use, or blacklisting all file types that you cannot use.
Be weary of session hijacking. Set user sessions to timeout when idle for an extended period of time. This will help prevent a user’s session from being hijacked, leading to unauthorized access to sensitive information. Policies can also be enforced so a session can only be used on a single IP address, thus preventing an outside hacker (with a different IP) from gaining access to the legitimate users session because it is limited to one IP.
Request management. You know the areas of your site or app where sensitive data can be accessed, the types of sensitive data, and the types of files that your site is composed of. Make sure access to admin URLs are restricted and requests for sensitive files are blocked by your Web app firewall for untrusted users.
Without security measures in place, hackers will find vulnerable penetration vectors in your Web applications. Imagine your site as a bank; there are ordinary locks and alarms on the perimeter doors, but the valuable goods (money, etc.) are inside a vault. Since you know your Web applications best, it’s up to you to make sure you place locks on all the doors, and make sure you put bigger locks on the more important doors. If you’re unsure what needs to be secured, thoroughly scrutinize and pentest your site.

You’re Never Done Securing

Even after you’ve configured your Web application firewall perfectly and put in place the best security policies you can, there are dangers to be aware of.  Human error, trust betrayal, and organizational challenges pose security threats that are hard to defend against, but are important to evaluate as they pertain to your organization.
Denial of Service (DoS). Made popular by its presence in the media as the attack method of choice by hacktivist groups, denial of service attacks (DoS) have become a major concern for many organizations – and rightly so. DoS attacks rely on a large number of requests to bring down a target site or app.  Casual DoS attacks can be diminished through use of a Web application firewall by limiting the number of requests per second or blocking IP addresses with high request frequencies. Though if you are dealing with very serious and determined DoS attacks, you may want to perform a risk assessment and investigate cloud-scale countermeasures, which will require some organizational backing to make the necessary changes.
Zero Day.  Zero Day attacks are attacks that exploit previously unknown vulnerabilities.  Even if you have tested against every known exploit and have secured against them, new vulnerability exploits will arise that you will not be protected against.  Any attack, even know attack types like SQL injection or cross site scripting, can become major threats if its a zero day exploit.  New exploits are created every day and can be very damaging, though a Web app firewall can be used to preempt them.   When purchasing a Web app firewall make sure it has a strategy for dealing with unknown exploits or a methodology for dealing with attacks that it hasn’t seen before.   Even with an app firewall in place, it’s important to remember that security today doesn’t mean you won’t be vulnerable tomorrow.
Exploiting Legitimate Trust Relationships.  Web app firewalls and security policies can go a long way to securing an organization, but exploitation of trust relationships – whether intentional or unintentional – are hard to defend against.  Members of an organization must be intelligent and prudent about their Web use for the organization to remain secure.  This means not opening attachments from unknown senders, not clicking on strange links from unknown and un-trusted people, and so on.  For example, if a user unknowingly downloads a keystroke logger from an untrusted email correspondant, a hacker can simply lift credentials from the logger and gain legitimate access to an organization’s system – no SQL injection, session hijacking, or complex hacking techniques required.  This example brings to light the human element of Web security; an organization is only as safe as its least secure link.

Test, Update, and Evaluate

Don’t: Have static security or perform one round of penetration testing, auditing, or use being PCI compliant as an excuse to not perform further testing.
Do: Test and audit regularly. Evolve your security plan as threats and traffic trends on your site change.
Why: Security vulnerabilities can arise after a code change, an update or through a new hacking method. Nothing is ever static; the Web is constantly changing, which means that security needs to stay current with changes that occur. New vulnerabilities are discovered all the time, even in major software companies’ code.
How: Stay current with patch and updates; people spend hours developing these for a reason. Stay informed by reading about information security trends, following #infosec on Twitter, talking to peers, and so on. Regularly pentest and audit your apps and sites. Analyze logs and learn from them to make adjustments to Web app firewall configuration.
Log. When first setting up a WAF, use a logging mode to evaluate your site’s traffic. This will give you a sense of where tighter policies may need to be set or where exceptions may need to be set.
Check for false positives. False positives are bad for business. You never want to blocking a legitimate and harmless user who accidentally mistyped a URL or input incorrect characters into a field because security policies are set too tightly. Logs should be checked regularly for errors that aren’t really errors, and exceptions should be added to policies that may be resulting in false positives.
Perform tests. Penetration testing for vulnerabilities in your code will show you what you need to protect against until new code can be deployed to fix it.  Set new policies in your app firewall based on your testing.
Update and patch.   Install updates as they are released.  Deploy patches to secure vulnerable code; it does’t matter if the patch is out if you don’t actually apply it.  If there is an update or patch available to secure a vulnerability, chances are there are people who know how to exploit it.
Web app firewalls can be a useful ally toward greater Web security for those who know how to use them properly.  Whether you’re in the market for a new Web app firewall, or are already a proud owner, understanding that a Web app firewall is a tool designed to be driven is an important step toward increased Web security.

---