Web Application Security Testing in the Real World

Why Not Just Test Manually?

Everyone is talking about the importance of information security and yet security researchers keep finding the same vulnerabilities, such as the recent cross-site scripting vulnerability in Facebook. We have penetration testing, we have SAST, we have DAST – so why do web application vulnerabilities still exist?

Anyone complaining about insecure code in today’s applications is, in fact, asking the wrong question. Yes, writing secure source code is difficult, but it’s only one part of a much larger puzzle. The correct exasperated question to ask would be: Is it really so hard to secure a web application? For many organizations, the answer is still yes, mainly because vulnerabilities can appear at all stages of development and deployment. Effective web application security is not about ticking boxes – it must be an integral part of the software development lifecycle.

Before the era of web domination and agile development, security belonged in the testing phase, alongside functional testing, user acceptance testing, and so on. This traditional view of software security as just another thing to test leads to inefficiencies that make it much harder to get results and really fix security vulnerabilities. This is especially true in DevOps environments, where development and operations processes are highly integrated and automated. Simply bolting on a conventional security testing process makes it a performance bottleneck, hence the idea of integrating security into DevOps workflows, called DevSecOps (or SecDevOps, if you really want to put security first).

Today we see complex web applications that are in continuous development, have millions of users and are under constant attack from cybercriminals. Agile development approaches such as continuous integration/continuous deployment (CI/CD) are used to keep pace with fast-changing requirements, but security testing is often still manual and any security issues can hold up the whole deployment process. Large organizations can have dozens or even hundreds of websites and web applications, making manual penetration testing too slow and expensive to be effective at scale. Like it or not, automated security tools are the way to go.

Security from the Inside Out: SAST

Static application security testing (SAST) focuses on helping developers write secure source code. It’s also called white-box testing because the tools have access to internal code. SAST tools check code for vulnerabilities before it ever leaves the development environment. So if SAST secures source code, then everyone should just use it in the development process and there would be no more vulnerabilities, because all web application code would be secure – right? Well, SAST tool vendors would certainly like you to think so, but in the real world, things are much more complicated.

Starting with the obvious, source code security testing requires access to the source code – and that’s not always possible. Companies that develop their own applications are just one part of the software market and there are many cases where developers will get external modules or libraries without the source code. For example, think about integrators who write code that interconnects third-party products: they might use static analysis tools on their own code, but won’t have access (or permission) to check the modules they are integrating.

SAST solutions analyze the source code (and/or byte code, depending on the tool and language) to find insecure constructs that can lead to vulnerabilities. However, because they work on abstract models of data flows and application logic, static analysis tools can generate a lot of false positives. This means extra work for developers, who need to double-check all flagged issues, including false alarms. You also need separate tools for each programming language. Modern web applications often use more than one language, so in an organization with multiple applications the tooling can get very complicated – and expensive.

If you use SAST tools from the very first line of code on a greenfield project and ensure that all your code plays nicely with them, you are likely to get very good results. But, again, in the real world, many new software projects need to integrate existing routines, libraries, or modules that may need a lot of work to prepare for static analysis. And if you have existing applications and want to introduce static application security testing into your current development processes, you are likely to run into the same challenges on a much bigger scale.

Beyond the source code, a running web application often uses dynamically loaded external libraries or modules. These are only loaded at runtime, so they can’t be checked using static analysis tools. Many security issues are also caused by misconfigurations – again, something that can only be detected at runtime.

If you can make it work, SAST is great for reducing the number of vulnerabilities right from the coding stage. Anything that improves web application security is worth using, and every development toolkit should include at least rudimentary tools to run code security checks. But we are talking about the real world, where vulnerabilities are going to creep into production code and application deployments sooner or later. In the hectic world of web applications, static code analysis is not enough.

Poking Around a Black Box: DAST

Dynamic application security testing (DAST) is performed on a running application without access to the source code, so it’s also called black-box testing or outside-in testing. The great advantage of DAST is that testing is independent of internal implementation details – you just scan whatever is accessible from the web. This is important because modern web applications are extremely complex mixtures of multiple web technologies, frameworks, libraries, and resources. In a large application, few developers (if any) will know the entire codebase and all the dependencies. Open-source libraries and frameworks are also widely used to make application development easier, faster, and cheaper – but what if they have vulnerabilities of their own? 

The only realistic way to fully test the security of a complex application is from the outside in using DAST tools for automated scanning. With dynamic application security testing, you don’t need to know the implementation and deployment details, so even if you don’t develop your own applications, you can still scan them for vulnerabilities. This is also the only approach to testing web APIs – the back end of countless web services and mobile applications.

In large organizations with hundreds of websites, reliance on manual testing often means that only a handful of critical sites are regularly tested and maintained. If you are serious about web application security at scale, automated scanning is the only practical solution. Security professionals are often wary of automated tools because many early vulnerability scanners were inaccurate, either reporting many false positives or not finding existing vulnerabilities (i.e. generating false negatives). Without trustworthy results, you can’t automate security testing, because even if you automate scanning, someone still has to sit down and manually check the scan results. 

This is where Invicti is in a league of its own, with its Proof-Based Scanning technology delivering verified vulnerability reports that can go straight to the developers to fix. When you have proof that reported vulnerabilities are real and not false positives, you can confidently automate and integrate dynamic application security testing tools into your SDLC. 

Real-World Solutions to Real-Life Challenges

In a perfect world, everyone would have the skills, time, and resources to build flawless software. But in the real world, where there is software, there are bugs – including security issues. With limited information available at all stages of the development lifecycle, the only practical way to test the security of an entire web application is from the outside in.

Static code testing is a great way to minimize the number of vulnerabilities that are introduced in new code, but once a large application is up and running with all its modules, dependencies, and configuration parameters, nobody can be completely sure what’s going on inside. Complex web applications are black boxes – which is why black-box security testing is a practical necessity.