2014’s Most Common Web Application Vulnerabilities
The internet has become an integral part of our life. We use it for various functions, such as online banking, social media, retail purchases and online gambling. When browsing through various web sites, a lot of personal and financial information is being transmitted and stored across a number of systems. It’s no wonder that security has become a top priority when developing web applications.
That being said, we have seen a great improvement in web application security over the last couple of years, however there are always areas where web developers can improve. With this in mind, I decided to look at the results we here at Pure Hacking have been seeing in our reports during the first six months of 2014, focusing on vulnerabilities with a risk level of medium or higher.
Below I will explore the top three most common vulnerabilities that Pure Hacking has encountered and offer a high-level recommendation for each.
Insecure Password Policy
When it comes to securing user accounts, having a complex password is a very simple yet important aspect.
Surprisingly, this is the most common web application vulnerability encountered. Why is this important you may ask? If the web application you are using does not support a complex enough password policy then an attacker might be able to brute-force the password. This results in a negative impact on the confidentiality of any data associated to the end user.
There have been several cases in the last few years when a website has been breached and the exposed user accounts had incredibly simple passwords. Allowing users to use passwords such as “1234” or “password” is never a good thing.
To defend against this vulnerability, web applications should enforce a complex password policy of at least nine characters containing a mixture of upper and lower case alphanumerics, as well as and typographical symbols.
Users are also encouraged to implement a proper password management solution. Software such as Password1 or Keepass can help to generate and store all of a user’s passwords. Generally speaking, if you are able to remember your password you are probably doing your password management incorrectly.
For further information on how to implement a strong password policy, refer to OWASPs recommendations:
Cross-Site Scripting (XSS)
“Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.”1
Even though XSS has become harder to find and harder to exploit due to additional security mechanisms such as the HttpOnly flag for session tokens, preventing hijacking of user accounts, it's still a very common vulnerability that we encounter.
I asked myself why this would be. One possible reason is that insufficient defences to the problem are being used, such as blacklisting limited character sets. Bypassing these types of defences is a lot easier than a limited whitelist character set.
Another possible reason is that people are trusting scanners to tell them that their product is secure. If web application scanners are returning a green light then the application must be secure… right? Sadly this isn’t the case, as those scanners are not able to think like humans and therefore are not able to spot more sophisticated (but still often very simple) XSS vulnerabilities.
What should developers do to protect against XSS?
Without going into a solution that is based on one specific technology developers should always ensure that all input from any source (including the user, database, headers and cookies) is:
- Canonicalized (that is made as simple as possible) prior to input validation and subsequent output encoding.
- Input validated using a positive validation, rather than a black list or sanitised. Bad input should be rejected rather than sanitised.
- Output encoded for all unprintable characters, and not just the big five (< > “ ‘ and &) for the correct output context. XML values, HTML attributes, HTML values, CSS, JSON, and AMF are very different output encodings.
OWASP has also provided a very good XSS prevention cheat sheet for developers that is accessible here:
Insecure Session Token
How do websites track if the user is logged on? And what privileges are given to the user?
This is done with a thing called a session cookie or a session token. HTTP and HTTPS are stateless protocols and do not retain login state within the protocol definition. This means that if an attacker is able to steal your session token, they may be able to obtain access to your account.
When auditing session cookies you inspect the attached parameters. Generally, the two most important things to check are whether the session token has the secure flag and the HttpOnly flag set.
The secure flag will prevent the session token being sent over HTTP which is an unencrypted protocol and will prevent an attacker from stealing the session token via a Man-in-the-Middle attack.
Thankfully, it is not difficult to implement a solution. We recommend that the session token parameters are set in the following manner:
Set-Cookie: SessionId=veryrandomvalue; path=/myapp/; secure; HttpOnly
Protecting user privacy and data is a key consideration in our highly connected, current day world.
One thing that surprised me when going through past reports was the lack of Cross-Site Request Forgery (CSRF) popping up. This is an indication of good progress being made in the field. It is a serious web application vulnerability, since it allows an attacker to forge a user request without their knowledge (transferring money, changing passwords etc). Some years ago, this vulnerability was much more widespread.
Implementing proper CSRF protection can be tricky so it was pleasing to see that developers are spending the time to implementing proper strategies to prevent this vulnerability.