<img height="1" width="1" style="display:none;" alt="" src="https://analytics.twitter.com/i/adsct?txn_id=nv7vl&amp;p_id=Twitter&amp;tw_sale_amount=0&amp;tw_order_quantity=0"> <img height="1" width="1" style="display:none;" alt="" src="//t.co/i/adsct?txn_id=nv7vl&amp;p_id=Twitter&amp;tw_sale_amount=0&amp;tw_order_quantity=0">

Web Application Security: Four Fundamental Truths

Zaid Al Hamami on Apr 26, 2016

Your truth.jpgweb applications have a larger attack surface than you probably have ever imagined. No, I’m not looking to raise the paranoia level, but I do want to point out a few fundamental truths of web security that, once you take them on board, will put you in a much stronger position to deploy the most effective protection strategies.

  1. However tight your coding is, and no matter how thorough your QA, unless you have a comprehensive set of security tooling, highly experienced personnel, and sophisticated processes, odds are your app is hackable. This year we found a remote server execution bug that had been sitting in a popular framework for almost four years. We identified an app vulnerability would have permitted a single malicious request to expose the entire database behind that app. Yet another coding weakness could have enabled the bad guys to take over the administrator account for almost all apps in another popular web framework.*
  2. Sadly, even after almost 40 years of frontline wars against hackers, information security professionals like us are still encountering the kind of bugs that enable sophisticated hackers to do a lot of damage – without having to work particularly hard.
  3. You can reduce the vulnerability of your code, but you probably won’t be able to eliminate it entirely. But that’s OK. Understanding that the risk is there, and the costs and actions you need to undertake to reduce that risk is what’s important. Doing nothing simply leaves the door wide open for the hackers.
  4. Your risk exposure increases with time, and so do the odds that the hackers will successfully exploit vulnerabilities in your code – you are not the only coder getting more sophisticated, and there’s a thriving black market for exploits on the dark web. Rapid release cycles and the increasing use of third-party libraries leave you unable to upgrade fast enough to remediate those vulnerabilities.

Why is all of this happening now? Quite simply, because building web apps has never been easier. Pick your favorite programming language, and you’ll have a plethora of open source web frameworks at your disposal that will make getting started a breeze. There are thousands of companies in the world using freelance platforms to build apps. It costs next to nothing to host those apps in the public cloud – just spin up a server, upload your app, and you’re off to the races. They assume these apps are secure. They assume all developers know how to develop securely. According to NetCraft, there are over 175 million unique (over a billion total sites) web apps out there in cyberspace – and probably a whole lot more behind corporate firewalls.

WhiteHat Security publishes an annual report tracking web vulnerabilities and time-to-fix; the 2015 report found that organizations in which the primary concern for website security was risk reduction (which I think we can safely assume would be the case for the majority of app-hosting sites) had an average of 23 vulnerabilities per site, with a remediation rate of 18% - not statistics that would give customers a sense of security, especially when the report goes on to report the average time-to-fix for those sites at 115 days. You can download a copy of the report here.

The SANS Institute published a report last year on the State of Application Security, in which they reported that almost half (47%) of all respondents felt that their application security programs needed improvement. SANS respondents had somewhat better time-to-fix rates, but not by much.

The harsh reality is that writing apps is easy, but writing apps securely is hard. Most developers don’t learn secure coding unless and until they have to – something else that hasn’t changed much in 40 years. Creativity is sexy, security is not.

If you’re working in an enterprise environment that has the financial and technical resources to retain a static source-code analysis team, use pen-testing services, deploy and maintain complex application firewall technology, and have trained analysts sift through thousands of event entries, good for you. But even all these resources don’t guarantee you won’t get breached.

If you’re lucky enough to have a few application security pros on your team, hang on to them – they’re in short supply, and they put you ahead of the curve. But even these resources aren’t available to most companies with less than a few hundred employees.

This was the challenge IMMUNIO set out to meet. And we think we came up with a pretty good answer – build the protection into the app itself. This approach lets developers maintain their rapid-release cycles without continuously rewriting their apps, protects customers from exploitation, pinpoints the source of the vulnerability, and buys time for remediation. Delivered as a service, IMMUNIO can be deployed in minutes and protects your apps right “out of the box”.

*We have disclosed these bugs to the development teams concerned.