Web Applications

Web applications are absolutely crucial in today’s digital world. They are an enabler for digital transformation. The agility of these applications, providing quick time to market and close adherence with users’ expectations, is a requirement to stay competitive in fast moving digital markets.

This requirement for quick development and constant availability does come at a price: security is often an afterthought. Security features not fully implemented or tested, updates not applied and patches being held back are just a few of the issues that can arise during web app development and maintenance.

So, with that in mind, should we be surprised that in the latest update of the Open Web Application Security Project (OWASP) didn’t actually contain many updates? The top vulnerability remains ‘injection’, while cross site scripting (XSS) has been in the top 10 for many years now.

But when looking at the list it’s important to remember that there is more than meets the eye. These exploits have been in the list for some time now mainly because hackers know exactly where to use them most efficiently. Injections and XSS represent a broad set of tools and techniques that in most cases result in data breach or remote code execution. Both of these tactics take advantage of interactive applications that ask for inputs from the user.

To understand why they are still on the OWASP list we need to get into a hacker’s mind and then explain why businesses are still being caught out. Many high-profile hacks require a long phase of reconnaissance, trial and error, social engineering and normally a combination of various attack tools in order to get through security controls. While collecting intelligence, hackers leverage various tactics to uncover the systems that are used by organisations and their versions, and look for tailored exploit kits against them.

Hackers usually know where most of the protection resources will be invested and how to bypass them. So the situation is not about trying to assault the fortified wall, but find the right spot where it comes apart (or go above it or dig below it or appear like a trusted figure), and there inject or run your script – which might come from one of your legitimate users’ browser or web services.

Businesses unfortunately have a different way of thinking. First – developing secure code is expensive – there’s a requirement to invest in proper QA and testing. Next, security can be an inhibitor in rolling out new application services. Lastly, as we’ve seen in the past, patching vulnerabilities doesn’t always happen immediately and organisations are waiting for the right timing for minimal impact on their operation.

Going a step further, the complexity and speed of development has grown considerably in the past years. Many web applications are running on top of large, complex, open sourced frameworks that might contain vulnerabilities that are not within the control and knowledge domain of the coders working on the application.

Libraries and tools to provide cross-device, cross-platform, dynamic and intuitive user interfaces are growing more complex with every new tablet, phone and phablet introduced. Timelines and pressure on coders means that security measures are often not a priority. It’s likely this situation will unintentionally result in more vulnerable code flowing through undetected to production.

Awareness is growing, and most organisations are investing in training their coders to provide secure code, but as long as the coder is a human, he will make errors – the larger the pressure on the coder, the higher the probability for vulnerabilities will be.

But don’t mistake this statement as one that it would be better if an artificial system would produce the code. AI and machine learning systems can be even more flawed than humans are, and produce anomalies that are surprising to its designers, and there is no real fundamental theory on how they might have been produced and how to ensure AI will not produce erroneous output on occasion.

The important part of the automated devops chain is to integrate security from the source code through to vulnerability detection. Static Application Security Testing (SAST) tools and Dynamic Application Security Testing (DAST) tools for black box testing and fuzzing can be used, as well as Runtime Application Self-Protection (RASP) technologies that are available for certain runtimes and platforms.

The most crucial action is to ensure a first line of defence using adaptive web application security that provides the same dynamic as the agile application environment. This will ensure any potential code injection vulnerabilities that might slip through the DevSecOps chain are detected and filtered even before they hit the application and XSS attacks are proactively handled. It is an extra layer of protection through identification and blocking of bad agents and bots such as scanners and Webscrapers that will ensure the application will not be easily exploited by humans or intelligent agents such as AI based attack systems.

So there is absolutely some work for organisations to do in being more alert to these threats, sanitise inputs and filter scripts and malicious code commands. The point to remember however is that determined hackers are like surgeons, and with the visibility challenges that many organisations face today, security has to be a priority to stop hackers from operating under the radar.

Are Web App Developers Falling Into The Same Old Security Gaps? | BCW
BCW

Are Web App Developers Falling Into The Same Old Security Gaps?