After years of cajoling by security experts, organizations are finally starting to embrace the layered approach to cyber security. They realize firewalls can be breached and network traffic needs to be monitored if they’re to keep attackers at bay.

Many organizations, though, aren’t quite sold on protecting the next layer ­­the application layer, which can be the most complicated layer to secure. That’s because it could be a costly endeavor, which is outside the comfort zone of the typical stakeholders such as developers, project managers, product managers and quality assurance engineers.

Besides, if an application starts misbehaving, won’t the network security systems pick up that activity and shut it down?

Yes and no. Just as a firewall isn’t a perfect shield against attacks on an organization’s endpoints, devices and network. Network security solutions are imperfect, too. They can keep some but not all threats from reaching your apps.

Intrusion Detection/Protection

For example, an Intrusion Protection System (IPS) is designed to sit on the network and examine packet traffic passing through it. It can match data in the packets to a signature database ­­ much as antivirus programs do ­­ to flag malicious traffic. It can also identify anomalies in traffic based on a norm developed by observing traffic over time. In addition to logging suspicious traffic and alerting defenders to it, the IPS can be programmed to block potentially harmful packets from getting to applications.

There are a couple of drawbacks to an IPS that can allow attackers to reach an organization’s applications and if there are any vulnerabilities in those apps, exploit them. First, an IPS can’t understand web application protocol logic. That means it can’t determine the difference between a normal or malformed request at the application layer. The shortcoming can result in an attack being undetected or prevented. Some of the evasion techniques include obfuscation, encryption, and fragmentation. For example, the following is an example of obfuscated JavaScript:

The following piece of JavaScript, which is human readable

xmlDoc = xhttp.responseXML;
window.onload = function() {
document.document.getElementById('label').innerHTML = xmlDoc;

Could be obfuscated to (among many ways):

var _0xbc37=["\x72\x65\x73\x70\x6F\x6E\x73\x65\x58\x4D\x4C","\x6F\x6E\x6C\x6F\x61\x64","\x69\x6E\x6E\x65\x72\x48\x54\x4D\x4C","\x6C\x61\x62\x65\x6C","\x67\x65\x74\x45\x6C\x65\x6D\x65\x6E\x74\x42\x79\x49\x64","\x64\x6F\x63\x75\x6D\x65\x6E\x74"];xmlDoc= xhttp[_0xbc37[0]];window[_0xbc37[1]]= function(){document[_0xbc37[5]][_0xbc37[4]](_0xbc37[3])[_0xbc37[2]]= xmlDoc}

Second, while an IPS can protect a system from known vulnerabilities, it can’t protect it from all potential vulnerabilities. That can result in the creation of a burdensome number of false positives ­­ alerts about vulnerabilities that aren’t vulnerabilities. False positives not only divert valuable human resources to dead­end tasks, but they divert them away from real attacks, which slows response times to those assaults. For example, there is no way for an IPS/IDS to know that an account ID of 12345 should be accessible to the user but not 12346 for example in the following URL:

A variation on the IPS is the Hosted IPS (HIPS). It has a better understanding of what’s going on at the application layer. For example, it knows what protocols TCP and UCP packets can and cannot carry. When it sees deviations from those norms, it can alert defenders to them. Still, even HIPS lacks a full understanding of web application languages and logic.

Web Application Firewalls

Another network solution designed to protect applications from attack is the Web Application Firewall (WAF). It’s designed to protect applications that face the public Web in ways that an IPS can’t. For instance, WAFs sit in front of an application and examine traffic only to the app. That allows them to do a more thorough job of analyzing the application layer.

In addition, while an IPS will monitor net traffic against signatures and anomalies, WAFs can understand the application’s logic. It can determine what an application is requesting and what it wants to be returned. In that way, it can guard the application against common threats such as SQL injection, cross­site scripting, session hijacking, parameter or URL tampering and buffer overflows.

What’s more, it enables the WAF to not only detect attacks that are known but those that are unknown. It does that by identifying unusual or unexpected behavior. When it sees such behavior, it blocks it or alerts someone of it. Most WAFs operate using signatures (rules) or using a blacklist, two techniques that have obvious shortcomings.

Some Problems with WAFs

The problem with WAFs is they can be penetrated just like other kinds of firewalls. For example, the policies a WAF uses to filter out malicious traffic can be exploited to bypass it. They can also be bypassed with the same attacks used against web apps, such as SQL injection. For example, the following SQL injection payload could easily be picked up by a WAF: Union Select 1,2,3,4,5--

However, the following payloads might not be easily detected by your average WAF;

/*!%55NiOn*/ /*!%53eLEct*/
%55nion(%53elect 1,2,3)-- -
+#1q%0AuNiOn all#qa%0A#%0AsEleCt

WAFs can also be difficult to configure. “Features” in a misconfigured WAF can become an open door for hackers. A misconfigured WAF can also be a headache for an organization. Such a WAF will start flooding the network with false positives. The network will take a performance hit, users will start grousing and unwanted denial of service issues will arise. When those conditions occur, most organizations will turn off the WAF’s blocking functions. That defeats one of the main purposes of installing the WAF in the first place.

Network protection strategies that use tools like an IPS and WAF can only provide a degree of protection for an application. That means once the network defenses are breached, the application, unless it was built from the bottom up with security in mind, will be at the mercy of the attackers. As

more organizations buy into baking security into the development process, we can expect the nature of network security to change. That’s because many of the threats addressed by technologies like WAF will be addressed through integration and testing during the development process instead after the code is up and running online.

White Paper - Proving Adherence to Software Security Best Practices

White Paper - Proving Adherence to Software Security Best Practices

Industry standards and the best practices for developing secure software. Please provide your email and name to receive your copy.

Success! Your copy is on the way.