We live in an application world. From shopping to communicating with friends, reading the news, following our favourite sports teams to listening to music – we do it through apps. With so many interactions and transactions now taking place via apps, maintaining security is becoming a big concern.
It is an indisputable fact that web app attacks are on the rise. According to the 2014 Data Breach Investigations Report, a global study by Verizon, web app attacks doubled in frequency from 2012 to 2013, jumping from less than 20 percent to 40 percent of recorded security incidents .
For the security or operations practitioner, following the three Cs of web application security that is ‘client, context and content’ can provide a good foundation for keeping not only the app, but also the network and data secure.
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 a security or operations practitioner can evaluate the security status is on request. When a verified client makes its first request, it is time to inspect those requests for a variety of potential bad behaviors. That includes validating input fields, URIs and HTTP headers - especially cookies. Practitioners should 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 final point at which practitioners can do some security checks is on response. This should involve comparing expected length and data types against what is really coming back from the app or API call. The practitioner should identify sensitive data in payloads that could be problematic or indicative of a failure on the inbound flow.
The expected response should match the request; i.e. 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 slowly. 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 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, you can never be too careful. In addition, 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 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 number of web app attacks, following the three Cs of web application security will certainly enhance existing security posture and provide better overall coverage of web applications and APIs.
Read more: Smarter DDoS attacks require smarter DDoS defence
This article is brought to you by Enex TestLab, content directors for CSO Australia.
Upcoming IT Security Events
Read more: Billion-dollar Carbanak heist blamed on poor staff cybersecurity training
March 3rd, March 5th, March 9th 2015
Join CSO for the day@#csoperspectives and hear from @kimzetter @LeviathanSec
3 International Keynote speakers, 36 Key IT Security Industry Speaker, 21 Exhibitors, Security Analysts and many more.. Register today
Dont miss one of the biggest IT Security events in ANZ (registration is free, but seats are limited)