The Three Cs of Web App Security

Web app attacks are on the rise. According to Verizon's Data Breach Investigations Report, web app attacks doubled in frequency from 2012 to 2013, jumping from under 20% to 40% of recorded incidents.

That should be a concern, because it's an application world and that means we're also increasing the rate with which we expose new web applications (and APIs) to the world.

That parenthetical, too, is important. Failure to treat your API with as much care as a web app with respect to security could net you some pretty ugly results. And not the kind of ugly that grows up into a beautiful benevolent swan; I'm talking about the 9-headed hydra kind of ugly - the kind that takes the stuff of myth and legends to get rid of.

For the security (and increasingly operations) practitioner, following the three Cs of web application security can provide a good foundation for keeping that hydra out of your app and your network and, of course, your data . 

All you need to remember is "Client, context and content."

 

Client (On Connect)

The client is, thanks to the Internet of Things and BYOD and cloud, a very important component to securing web apps today. The client should be checked on connect. That is, when a client first makes a connection with the app some very basic pieces of information should be verified. This might include device type or IP address or the app version itself. It might dig deeper and examine whether the client is running A/V software or connecting via the appropriate app tunnel. Network, device type, user and other operating parameters should be verified if possible at this point. 

Increasingly this includes the use of security threat feeds. Clients and IP addresses alike can be checked against known sources of bots, malware or other questionable data points to assist in determining whether or not the connection should be allowed. For example, anti-fraud services are able to determine, in real-time, whether or not a client is compromised, enabling security services to determine the appropriate course of action. When combined with a WAF or strategic point of control in the critical conversation path, this information provides tactical guidance on whether or not a connection should be allowed to continue.

Context (On Request)

The next point at which you have a chance to evaluate the security status is on request. When a verified client makes its first request, it's time to inspect those requests for a variety of potential bad behaviors. That includes validating input fields, URIs, and HTTP headers - especially cookies. Check not only the value of expected HTTP headers but look for new ones that don't seem to be used by the application. 

The use of HTTP headers - both those specified in the standard and custom - as a means of attack has been increasing in the past few years. This is because few intermediaries and fewer applications use all possible headers, and thus many of them still contain vulnerabilities that have simply not been discovered due to lack of use. The exploitation of a vulnerability associated with an HTTP header can wreak havoc on applications because it impacts the application platform - the web or app server - itself. This requires patching and deployment and can be delayed while waiting for the vendor or group owner of the platform to address. By using an intermediary like a WAF or programmable proxy to eliminate potentially dangerous (and unnecessary) HTTP headers apps and APIs can be rendered usable during this time.

Content (On Response)

The next (and final) point at which you have the opportunity to do some security checks is on response. Compare expected length and data types against what is really coming back from the app or API call. Sniff out sensitive data in payloads that could be problematic or indicative of a failure on the inbound flow. Make sure the expected response matches the request; i.e. if the request was for product information, should the response really be a bunch of customer data? Similarly, if the request is for a single customer record, the response should not contain a list of records.

It is also at this point that an intelligent intermediary can discern whether or not the client is attempting an HTTP DDoS attack. By understanding the client context, intermediaries can gauge whether or not requests are coming in too fast - or responses being accepted too slow. Deviations from expected transfer rates can indicate the client is part of an attempt to consume resources such that a denial of service is effected.

 

The frequency with which web apps are being attacked is increasing along with other attacks. Security operations must remain vigilant in its attempts to root out the sources of potential disaster before they successfully breach the sanctity of corporate and consumer data managed by the application. While secure development goes a long way in preventing a significant number of attacks, one can never be too careful. Too, the prevalence of zero-day and emerging exploits makes it difficult for developers to discover, address and push a fix for a vulnerability before it can be exploited.

Whether you're applying web app security as a stop-gap to give developers (or vendors in the case of app platform-related vulnerabilities) time to address an issue or as a first line of defense against the growing cabal of web app attacks, following the three Cs of web application security will certainly enhance your existing security posture and provide better overall coverage of your web applications and APIs.