If everyone is thinking the same, someone isn't thinking

Lori MacVittie

Subscribe to Lori MacVittie: eMailAlertsEmail Alerts
Get Lori MacVittie via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Security Journal, CyberSecurity Journal, DevOps Journal

Blog Post

Three Cs of Web App Security By @LMacVittie | @DevOpsSummit [#API #DevOps]

The use of HTTP headers as a means of attack has been increasing in the past few years

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.

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.