The Importance of Automating Web Application Security Testing & Penetration Testing

Have you ever tried to make a list of all the attack surfaces you need to secure on your networks and web farms? Try to do it and there will be one thing that will stand out; keeping websites and web applications secure. We have firewalls, IDS and IPS systems that inspect every packet that reaches our servers and are able to drop it should it be flagged as malicious, but what about web applications?

Web application security is different than network security. When configuring a firewall you control who accesses what, but when it comes to web application security you have to allow everybody in, including the bad guys and expect that everyone plays by the rules. Hence web applications should be secure; web application security should be given much more attention and considering the complexity of today’s web applications, it should be automated.

Let’s dig in deep in this subject and see why it needs to be automated.

Automated Web Security Testing Saves Time

Also known as Penetration Testing or “pen testing”, this is the process by which a security engineer or “pen tester” applies a series of injection or vulnerability tests against areas of a website that accept user input to find potential exploits and alert the website owner before they get taken advantage of and become massive headaches or even financial losses. Common places for this can include user data submission areas such as authentication forms, comments sections, user viewing configuration options (like layout selections), and anywhere else that accepts input from the user. This can also include the URL itself, which may have a Search Engine Optimization-friendly URI formatting system.

Most MVC frameworks or web application suites like WordPress offer this type of URI routing. (We differentiate a URL and URI. A URL is the entire address, including the http:// portion, the entire domain, and everything thereafter; whereas the URI is the portion starting usually after the domain (but sometimes including, for context), such as /user/view/123 or test.com/articles/123.)

For example, your framework may take a URI style as test.com/system/function/data1/data2/, where system is the controlling system you wish to invoke (such as an articles system), function is the action you wish to invoke (such as read or edit), and the rest are data values, typically in assumed positions (such as year/month/article-title).

Each of these individual values require a specific data type, such as a string, an integer, a certain regular expression match, or infinite other possibilities. If data types are not strictly enforced, or – sadly as often as this really does happen – user-submitted data is properly sanitized, then a hacker can potentially gain information to get further access, if not even force direct backdoor access via a  SQL injection or a remote file inclusion. Such vulnerabilities are such a prevalent and consistent threat, that for example SQL Injection has made it to the OWASP Top 10 list for over 14 years.

There exist potentially millions, billions, or more combinations of various URIs in your web application, including ones it may not support by default or even to your knowledge. There could be randomphpinfo(); scripts publicly accessible that mistakenly got left in by a developer, an unchecked user input somewhere, some file upload system that does not properly prevent script execution – any random number of possibilities. No security engineer or his team can reasonably assume for or test all of these possibilities. And black-hat hackers know all this too, sometimes better than those tasked to protect against these threats.

Automation Isn’t Just Used By The Good Guys

Many automated security tools exist not to test and find security holes, but to exploit them when found. Black-hat hackers intent on disrupting your web application possess automated suites as well, because they too, know a manual approach is a waste of time (that is, until they find a useful exploit, and by then it’s sometimes too late).

Some utilities, like Slowloris, exist to exploit known weaknesses in common web services, like the Apache web server itself. Others pray on finding opportunity in the form of insecure common web applications – older versions of Wordpress, phpBB, phpMyAdmin, cPanel, or other frequently exploited web applications. There exist dozens of categorical vulnerabilities, each with thousands or millions of various attack variants. Looking for these is a daunting task.

As quickly as you can spin up a web application, a hacker can automatically scan it and possibly find vulnerabilities. Leveraging an automated web application vulnerability scanner like Netsparker or Netsparker Cloud provides you the agility and proactivity to find and prevent threats before they become seriously damaging problems. This holds especially true for complex web applications such as large forum systems, blogging platforms and custom web applications. The more possibility for user submitted data and functionality, the more opportunity for vulnerabilities to exist and be exploited. And remember, this changes again for every new version of the web application you install. A daunting task, indeed.

Without automation of web application security testing, a true strong security posture is impossible to achieve. Of course, many other layers ultimately exist – least-privilege practice, segregated (jail, chroot, virtual machine) systems, firewalls, etc. – but if the front door is not secure, what does it matter if the walls are impenetrable? With the speed afforded by automation, a strong and capable web vulnerability scanner, and of course patching found flaws and risks, security testing guarantees as best as reasonably possible that the front door to your web application and underlying infrastructure remains reinforced and secure.