The Truth About Zero-day Vulnerabilities in Web Application Security

Wed, 02 Dec 2020 - by Zbigniew Banach

Any mention of a zero-day is a guaranteed headline-grabber in cybersecurity news, and rightly so. But what does “zero-day vulnerability” mean in web application security as compared to systems or network security? Time to set the record straight.

The Truth About Zero-day Vulnerabilities in Web Application Security

Any mention of a zero-day is a guaranteed headline-grabber in cybersecurity news, and rightly so. But what does “zero-day vulnerability” mean in web application security as compared to systems or network security? Time to set the record straight.

Netsparker finds zero-day web vulnerabilities for a living

What Are Zero-day Vulnerabilities and Zero-day Exploits?

The term “zero-day” refers to the number of days the vendor has had to fix a security issue. Strictly speaking, any security bug can be called a zero-day vulnerability if the software vendor doesn’t know about it yet. If a way to exploit that software vulnerability exists, we have a zero-day exploit. The main difference between the mainstream and web application understanding of these concepts is who actually develops the software and supplies security updates.

Zero-days in General Cybersecurity

In the realm of network, systems, and endpoint security, zero-days are a big deal. If a zero-day vulnerability is found in your Windows operating system, it means that you will remain exposed to attackers until Microsoft prepares a security patch and gets it to you in a software update. This also applies to other software programs – Adobe Flash Player, for example, was notorious for vulnerabilities that exposed the browser or even the entire system to attacks.

If a zero-day is found in firmware, even the physical device itself could be compromised. In all these cases, there is very little you can do to mitigate the issue, other than setting up a firewall, disallowing USB flash drives (remember Stuxnet?) or otherwise blocking the attack vector. Then you can only sit and wait for the software vendor to acknowledge the vulnerability and distribute a security patch.

In terms of discovery, typical zero-days can only be found by dedicated security researchers. This could mean security staff at software companies or freelance bounty hunters looking for bug bounty payouts. But black-hat hackers are also on the trail of money, selling vulnerability information to cybercriminals on the cybercrime black market, and zero-day attacks are often available to the highest bidder just hours after a security bug is discovered.

This is the main reason why zero-day vulnerabilities are so dangerous. Until you patch your system, it remains exposed to cyberattacks that target the vulnerability, often to install some kind of malware, from ransomware to cryptocurrency mining code or botnet clients. And speaking of malware, zero-day has a slightly different meaning here. Zero-day malware is malicious software (for example a virus) that is not yet known to antivirus packages, personal firewalls, or other endpoint security software, and can’t be detected based on its signature.

Zero-days in Web Application Security

Moving to web application security, the vital difference is that the vast majority of web application vulnerabilities will be found in newly-deployed code, so there’s no way for anyone to know about them beforehand. This goes especially for business applications and systems developed and customized in-house. After all, if an application is only deployed and used by one organization, why would anyone report security holes?

More often than not, there is no external software company that can deliver a patch. If you have a critical vulnerability in your website or business application, you need to fix it yourself before someone uses it to gain access to your company systems, which could lead to a data breach that exposes sensitive data or worse. The only exceptions are widely-used web applications and libraries that have to be patched by the vendor and might even get their own CVEs – WordPress and its many plugins would be a good example. In fact, Netsparker runs an advisory program for open-source web applications specifically to report such issues.

CVE (Common Vulnerabilities and Exposures): Publicly known hardware and software security vulnerabilities in specific products. Issues that are discovered and officially reported receive CVE IDs assigned by CVE Numbering Authorities (CNAs)

Using Heuristic Scanning to Find New Vulnerabilities

In other areas of IT security, scanners rely primarily on fingerprinting and signatures to find known unpatched vulnerabilities. If you run a network scanner, it scans the network looking for software products and versions that are already known to be vulnerable based on CVEs and need to be patched. But it won’t find a new, previously unknown vulnerability, because that’s not how it works.

Web application security, on the other hand, is all about discovering unknown vulnerabilities that correspond to known weaknesses (CWEs). For example, failure to sanitize user inputs is a weakness that may lead to a specific cross-site scripting (XSS) vulnerability in a specific application.

CWE (Common Weakness Enumeration): A community-developed list of common software and hardware security weaknesses. Unlike CVEs, CWEs do not correspond to vulnerabilities in specific products but describe more general weaknesses that may lead to vulnerabilities.

Dynamic application security testing (DAST) tools like Netsparker use heuristic scanning to probe applications and uncover security flaws caused by development errors, insecure design, misconfigurations, and so on. While Netsparker will also find issues corresponding to known web application CVEs, any vulnerabilities found using heuristics are completely new and previously unknown. A web application scanner such as Netsparker quite literally finds zero-days for a living.

How to Find and Fix Web Application Zero-days

In the DAST space, you will occasionally see claims that a product “even finds zero-days”. If you’ve made it this far into the article, you can see why talking about zero-days in this context is misleading, to say the least. Well of course a DAST tool finds new vulnerabilities – that’s its primary function and the whole reason for doing application security testing.

Yet while many tools can identify some zero-day vulnerabilities in web applications, finding zero-day exploits, or actual attacks that are effective against a specific vulnerability, is another story. This is where Netsparker is in a class of its own because every vulnerability confirmed using its Proof-Based Scanning™ technology has just been safely exploited. That way, you know for a fact that an issue exists, you know how cybercriminals could exploit it, and you know how to fix it.

Mitigation is another vital part of web application security. When you are your own software vendor, patching a security hole means quickly getting actionable vulnerability reports to your software developers so they can fix the issue. Netsparker integrates with issue tracking systems for maximum efficiency and also provides detailed technical information and advice in its vulnerability reports. Combined with broad testing coverage, high accuracy, and even the option to export web application firewall (WAF) rules to temporarily block attacks, this helps you quickly eliminate real and present web security risks – which is why you run security tests in the first place.

Zbigniew Banach

About the Author

Zbigniew Banach

Technical Content Writer at Netsparker. Drawing on his experience as an IT journalist and technical translator, he does his best to bring web security to a wider audience on the Netsparker blog and website.