What Can You Learn from 87 Advisories About Web Application Vulnerabilities?

We have been publishing advisories of vulnerabilities Netsparker Web Application Security Scanner identifies in open source web applications since 2011. Two years ago we published statistics about these identified web application vulnerabilities and to accompany these statistics, this year we have statistics about the advisories we publish. One thing that you will obviously notice is that the number of advisories we publish each year is increasing. In 2014 we published 45 advisories, almost one every week.

How Do We Find These Vulnerabilities?

Every developer has his or her own way of writing code. With such a variety of writing styles, web frameworks and technologies the challenge for us, or anyone else for that matter to develop a web vulnerability scanner that is able to automatically crawl and scan all type of web applications is very big. So to ensure that both Netsparker Web Application Security Scanner and Netsparker Enterprise can automatically crawl and identify all possible attack surfaces and vulnerabilities in custom web applications we constantly scan a wide variety of open source web applications throughout the year. Through this process we identify both weaknesses in our own scanning engine, which we address with updates and also vulnerabilities in such web applications.

Why Do We Scan Open Source Projects?

There are several other reasons why we do such exercise apart from the one mentioned above. We could simply do our tests and not hassle about contacting the owners of this project. Though we understand that many open source projects do not have the adequate resources to ensure their web application is secure. Hence to give something back to the community we are helping these projects to ship more secure code, and hopefully improve the security of the internet in general. Secondly we do it to raise awareness on how easy it is to ship insecure code and how important it is to use the right security tools.

What Can We Learn from Netsparker Advisories?

The advisories we publish are like all other web application advisories, though there is always a lot to learn from them. To start off with let’s take a look at the graph below which shows how many advisories we published each year since 2011.

In total we published 87 advisories so far. In 2014 we published 45 advisories, as opposed to the 10 we published in 2011. One must also note that a whopping 53 of these advisories are about multiple vulnerabilities, so technically speaking we are talking on more than just 87 vulnerabilities.

Do these statistics mean that the state of security of web applications is decreasing? The answer is both yes and no. The drastic increase in the number of advisories we published is a result of:

• As a company we are growing and so are our resources. In 2014 we scanned much more web applications than ever before. To be exact we scanned 97 different web applications.
• We are constantly improving both the crawling and scanning technology hence our scanner is able to identify more attack surfaces and vulnerabilities than before.
• The number of open source projects is also increasing, hence there is a bigger repertoire to choose from, and for us to scan.

At this stage it is very difficult to predict if things are improving or not because tools are also improving thus they are finding vulnerabilities which have never been detected before, maybe some of which have been around for years. Though within a few years’ time we should be able to tell better. Also note that this data is based only on the advisories we published only. For example as we have seen last year, there are many vulnerabilities which we identify yet we do not release an advisory. This year it is the same. There are a number of vulnerabilities which we identified though for some reason or another we never publish an advisory for them.

Type of Vulnerabilities in Advisories

The below graph shows the different types of vulnerabilities that were reported in the advisories since 2011. Cross-site scripting leads the pack – it was featured in 78 advisories. Second place goes for SQL Injection with 17 advisories, third is Local File Inclusion with 4 advisories etc.

From our tests you can easily conclude that cross-site scripting vulnerabilities are by far the most common vulnerabilities. Not a surprise considering XSS made it to the OWASP Top 10 ever since. But what does this mean?

SQL Injection and other high impact vulnerabilities risks are clearly high – The direct impact of vulnerabilities such as SQL Injection and Remote File Inclusion are quite high. These type of vulnerabilities are widely exploited and are very popular in the media. Therefore there is more awareness on these vulnerabilities which means that more developers are aware of these high profile and high risk vulnerabilities, thus taking the necessary precautions.

Exploitation of XSS vulnerabilities is not easy – Exploiting an SQL Injection is a straightforward process when compared to exploiting a cross-site scripting vulnerability, which is a process that requires preparation, interaction and even luck sometimes. As a matter of fact very few junior penetration testers or security engineers, who are new to web application security ever properly exploited a XSS issue. Possibly all they have done is the typical

alert(‘XSS’)

proof of concept, which is enough to prove that the vulnerability exists but undermines the actual impact of it. This causes XSS to not get enough attention, hence there is less awareness about it thus is considered as a low risk vulnerability. Although we know for a fact that big organizations have been hacked via XSS in the past, such as the Apache Foundation.

Frameworks support and general defense solutions against XSS are not good enough – To fix SQL Injection vulnerabilities you can just use “Prepared Statements”. Yes there are the some super edge case scenarios where prepared statements are not enough, but in general you are covered, end of story. On the other hand, if you want to write web applications that are not vulnerable to XSS attacks you are in for a long and very complicated journey, irrelevant of the language or framework you are using. None of the frameworks available today have a complete and straightforward support against XSS. In fact when we analyzed all of the XSS vulnerabilities we found that more than half of these XSS issues output locations were:

“HTML Attribute” tags. i.e. <a href=”” title=”[VULNERABLE]“>

 One might be surprised by this initially because normally the most basic XSS is within the HTML context, such as:

 <p>Something <script>alert('xss')</script></p>

 This further proves that there is not enough support from frameworks when it comes to cross-site scripting protection. As a matter of fact encoding input in HTML context is a well defined and solved problem. But what about encoding in places such as HTML attributes, inline CSS/JS or within CSS/JS blocks? This is more complicated and the depending on the usage default frameworks’ anti-XSS functions do not support it, for example if the attribute is wrapped with single quotes (‘), HTML encoding functions will not help you.

Therefore even when developers apply the correct function that works in another context, their web applications are still vulnerable to XSS because when the input reflected in an HTML attribute they need a different function. Many frameworks are trying to address this issue and there are some variants which have been addressed, but it will take at least a couple of more years before we can see solutions as close to the elegance of today’s SQL Injection solutions.

How Bad is the Impact of an Exploited XSS Vulnerability?

There is a common misconception in the web application security industry that XSS is not a vulnerability you should worry about, as in it is not as dangerous as an SQL Injection. Therefore these results are not as alarming as they might seem. As explained in Web Application Security Misconception; Are All Vulnerabilities Equally Dangerous? XSS can be as dangerous as an SQL Injection. It is all about the context and attack avenues, so it should be given the same importance and attention when it comes to remediation.

Type of Web Technologies and Database Servers

Since 2011 in total we released advisories for 79 different projects. 45 of the vulnerabilities we identified were zero day. Though to give you an idea of the type of web applications we are scanning, most of them use MySQL server as database server although we have seen some which use NoDB.

The majority of the scanned open source web applications are written in PHP. Though we scanned and also found vulnerabilities in web applications written in .NET, JAVA, Python, Perl & CGI and Ruby on Rails.

The Shocking Truth of Vulnerabilities and Advisories

All of the above advisories are about vulnerabilities in 79 different open source web application projects. There are other vulnerabilities we know of but we haven’t released an advisory for. There are also thousands of other web applications available out there and this is just a fraction of what is out there. Therefore should you be alarmed?

I would say yes, we should be alarmed. Most of these open source web applications have many users and developers, some of which are also relatively popular. If such vulnerabilities are being missed, even with the exposure they get and with so many eyeballs analysing the source code, how can you still be sure that your website is secure? Is your custom web application being tested enough to withstand a malicious attack? When you look at the state of security of these projects you start realizing how badly written many web applications are, and how important it is to use the right tools to ensure you develop and use secure web applications.

And to close this article on a high, here is an interesting statistic; out of the 79 projects we tried to get in touch with 45 of them never got back to us. Why is this interesting? Well let me just say that most of those who never got back to us are relatively popular and active projects in their niche. Some of them even have commercial extensions or are available commercially.