Over time the web has evolved from a tool to a platform. The web browser was once just one application among many, but over time the web has become the focal point of the computing experience. The expanded use of the web, and the reliance many companies have on web-based applications and services has also drawn the attention of attackers and highlighted the security concerns of the web—which is why web application security is crucial.
To get a better understanding of the threats and security concerns for Web applications, and perspective on the state of Web application security, I spoke to Ferruh Mavituna, founder, Product Architect and CEO of Netsparker. Mavituna has been working in the application security industry for well over a decade and his ambition to ease the process of automatically detecting web application vulnerabilities led him to build Netsparker web application security scanner, and pursue it to the point of commercial reality.
Tony Bradley: How would you define Web Application Security?
Mavituna: Web application security is the process of finding vulnerabilities in web applications, and also the process of protecting web applications from malicious attacks. Is web application security something that you should consider for your business? Definitely!
Nowadays businesses—and also people who are not involved in the IT industry—heavily rely on web applications. For example, when you access your bank accounts via the online banking portal, post an update to a social media channel, purchase something online, use a mobile app to connect to an online service, or even send an email via an online portal such as Gmail, you are using a web application or a web service.
And web applications and services have vulnerabilities, and—because of the type of data that they handle—malicious attackers are always on the lookout for new vulnerabilities in them to exploit. There are several ways to improve the security of your website. For example, you can use a black box web vulnerability scanner to scan your website, which pinpoints for you where and what the vulnerabilities are. You can also install a web application firewall (WAF) which is designed to detect any possible malicious attack before it reaches your website. Finally, you can also do a source code audit, or hire a penetration tester to do a penetration test.
Bradley: As the web itself, and web applications specifically, evolve is security improving?
Mavituna: Yes and no. Yes because the interest and demand for web application security tools is increasing in every industry vertical. We are also seeing businesses which are incorporating web application security in their development lifecycle and many large corporations are doing their fair share to raise awareness. For example, Facebook, Twitter, Google, Microsoft and several others are documenting and promoting their way of keeping their web applications secure and have bug bounty programs. We also do our small share, we are giving developers of open source web applications a free account of Netsparker Cloud, so they can develop more secure web applications.
No, because web applications are developed by humans, and as long as they are we will keep on seeing vulnerabilities. Even after all these years of awareness, the majority of web applications are still vulnerable to well-known vulnerabilities that can be easily identified with automated scanners. We can see this from our online web application security scanner statistics. The good old SQL Injection and Cross-site Scripting (XSS) vulnerabilities are always the main culprit, even though we’ve known about both of them for more than a decade now.
Who is to blame? No one and everyone. There is still a lot that needs to be done in terms of awareness and training.
Bradley: What does the threat landscape look like from a web application perspective? What do businesses need to worry about?
Mavituna: We are seeing new threats emerging every day. If you attend a security conference you will most probably be awed by some edge-case vulnerability, or by how an attacker crafted this complex web application attack and managed to hack his way into a corporation’s network.
These things exist for real, but if you look at the majority of the successful hack attacks, they are about exploiting a SQL Injection, Cross-site Scripting or DOM XSS vulnerability, all of which can be automatically detected with an automated web vulnerability scanner. So as a business owner, first I would worry about ironing out the basics; scan and test the code of your web application and repeat.
Bradley: How does web application scanning work to protect businesses and consumers?
Mavituna: Web application scanning is done by using an automated web vulnerability scanner to identify vulnerabilities in web applications. In my opinion it is the most effective solution because by scanning a website you are emulating the attackers. Many argue that web vulnerability scanners can only identify low hanging fruit and technical vulnerabilities, so they are not a good enough solution.
I do not agree with this argument. True, scanners can only identify technical vulnerabilities. But, when you look at the statistics, they clearly highlight that low hanging fruit vulnerabilities were the cause of the majority of hack attacks that we have seen in the last few years. So web application scanning is very effective. I am not saying only use scanners, because no scanner can replace us humans, but no human can do what a scanner does. A scanner can find hundreds of possible attack surfaces in a web application and heuristically scan them for hundreds and thousands of different vulnerability variants within just a few hours, a feat that would take weeks to complete if it had to be done manually.
And once the scanner pinpoints the vulnerabilities in a web application, it reports all the details about the vulnerabilities that developers need to both learn about and fix the vulnerability in the web application.
Bradley: What is unique about your approach to web application security? Why should a business choose Netsparker?
Mavituna: We have developed a unique vulnerability scanning technology called Proof-Based Scanning. During a scan it automatically exploits the identified vulnerabilities in a read-only and safe manner to confirm the identified vulnerabilities. Once a vulnerability is confirmed, the scanning engine will also generate a proof of exploit, proving that the identified vulnerability is not a false positive. For example, when the scanner identifies a Local File Inclusion vulnerability, Netsparker will attach the source code of a file to the report as a proof of exploit.
Therefore, when using Netsparker you do not have to manually verify the scanner’s findings, saving a lot of time. Imagine having to manually verify hundreds of SQL Injection, Cross-site Scripting, Command Injection and several other different vulnerabilities. If you have the technical knowhow, and can verify a vulnerability in an average time of three minutes, it will take you a good number of hours to complete such a task.
We also focus on automating some of the pre-scan process as well, such as the configuration of URL Rewrite rules. Modern web applications use URL Rewrite and unless you manually configure the rules in the scanner, it will be unable to find all the possible attack surfaces to scan them. The problem with configuring URL Rewrite rules is that unless you are the developer of the web application, or someone with enough technical knowledge about the target, you won’t be able to configure them.
This automation also comes in handy when scaling up web security scanning. For example, if you are using an online scanner such as Netsparker Cloud, can you imagine yourself configuring the URL rewrite rules for 50, 100 or even worse, 1,000 websites? It is impossible. So we developed a heuristic technology that can automatically identify the URL Rewrite configuration on the target web application so the scanner can still find all the possible attack surface without requiring any manual intervention.
Both these pre-scan and post-scan automation technologies not only allow users to automate more and save time, but also make it possible to scale up automated web application security scanning. This technology makes it possible to launch a vulnerability scan of 100 or 1000 websites within just a few minutes.
Bradley: Are false positives a problem with web application scanning? What impact does a false positive have on the web application experience?
Mavituna: False positives are a big problem in web application security. As explained in my previous answer, if a scanner reports false positives, the users have to spend time verifying its findings, decreasing the value received from automation significantly.
Also, false positives can mislead the user and we’ve seen this happen in the past. The scanner reports 100 SQL injection vulnerabilities and when manually verifying them, it turns out that the first thirty or forty vulnerabilities are false positives. At this stage it is normal to assume that the rest of the vulnerabilities are false positives as well, potentially leaving real vulnerabilities unnoticed.
And this is just one front of the problems. Let’s not forget that not all users have the technical expertise needed to verify the vulnerabilities that the scanner reported. Actually, in most cases very few really specialize in security. So what happens when the user cannot reproduce the issue? In most cases they presume that it is yet another false positive. On the other hand, if you have a proof of exploit, you can’t question the validity of the scanner’s report.
Bradley: Aside from web application scanning—what do you recommend businesses do to protect web applications? What are the web security best practices that companies miss most often?
Mavituna: There is no golden rule, though by taking a holistic approach businesses can better protect their web assets. Use a web application security scanner to automate the repetitive. At the same time do a manual penetration test and keep an eye for logical vulnerabilities. If the budget permits, there is no harm in implementing a web application firewall, after all it is another layer of protection.
And don’t let pride get the better of you. Even if you have your own security team there is no harm in recruiting an external auditor to audit your web applications. It does not mean your team is not good. But, by being an external entity, such a team can uncover some things that you would have never thought of. And to wrap it up; test, test and test. When designing and building a web application think of security, and do tests at every stage of the SDLC. Even when the application is live, continue the frequent tests and scans—especially if the website changes a lot, which typically it does.
Bradley: What’s on the horizon? Are there emerging threats facing web applications that companies haven’t even thought of yet?
Mavituna: Web application security is like a cat and mouse game. A new threat emerges; a new solution is available to prevent the new threat. Though so far new threats are never a very big concern—known issues are. History has taught us the problem is awareness rather than dealing with the unknown, or new threats. The majority of attacks still happen because web applications are vulnerable to popular vulnerabilities such as SQL Injection, Cross-site Scripting and CSRF vulnerabilities. Even worse because an old and vulnerable software is running on the web server as most probably happened in the most publicized hack ever.
So rather than trying to focus on what is unknown or yet to come, businesses should focus on the basics; use all of the methods that are available to you nowadays, including training. Just look at the OWASP Top 10 list of most popular vulnerabilities, it’s a lesson in itself. We are still failing to write secure code that is not vulnerable to vulnerabilities that we have known about for more than a decade.
- Tackling Swivel Chair Syndrome - November 14, 2024
- Unlocking Proactive Compliance with Adobe’s Common Controls Framework - October 14, 2024
- Unlocking the Power of Continuous Threat Exposure Management - October 8, 2024
