OWASP top 10 or fixing web security, one item at a time
Microsoft Software Engineer Christos Matskas looks at the OWASP Top 10 security risks, such as hackers, security misconfiguration, and cross site scripting, and suggests tools and practices to help you to mitigate them.
Introduction
I recently did a workshop on OWASP Top 10 with a client and it was great. I got the opportunity to look again at the top 10 web application security flaws and remind myself of all the things I need to be aware of when developing web apps. However, before we start looking at the top 10 security risks, as these have been highlighted by OWASP, it may worth spending a few words explaining why you should care about security and what is OWASP. Just recently, we heard about the 500 million Yahoo accounts that have been hacked. There are countless other security breaches that have been reported in the past few years. Some of these breaches involve large companies such as Adobe and Sony while others targeted small start-up that many of us never heard before. This only proves that the attacks span all industries and all company sizes. If you think that the business you operate or the size of your company will protect you then you need to think again. The bottom line is: if you have a public presence, for example a customer facing website, then you are or will become a target.
You may think that your site may not be important enough but the problem is that there are crawlers and automated tools that will scan the web to find vulnerable sites that can be exploited. It may be the server you’re running your site that’s the actual target of a bot network setup operation.
Or, it could be the contents of your site or ultimately, your network. The possibilities are endless and if we take into account a recent statement from James Comey, FBI director, that “there are 2 types of companies, those that know that they have been hacked and those that don’t” then it’s easy to understand how serious things are.
Then you may ask yourself who would want to hack me? To this question, there are 3 answers:
- Script kiddies or hactivists
- Cyber criminals
- Nation states
As you work yourself down the list of potential malicious actors you’ll find that they are better funded and organised. This is scary stuff!
And this is where OWASP (Open Web Application Security Project) comes to your aid. This is a not-for-profit organisation where numerous security experts from around the world contribute selflessly in an effort to make the web a safer place. They are technology agnostic which is great news as they have no agenda. The guidelines they produce apply equally well to .NET, Ruby, PHP, Node.js etc. The last official report, the OWASP Top 10 was collated in 2013 and the new one is due in 2017. The Top 10 list is what we will be briefly discussing further on. It’s not exhaustive and it only touches the surface, only to give you enough information to go out and look for more information and how to mitigate these risks.
Injection
The number 1 security risk has been the king of the list from the “beginning of time.” Injection primarily refers to SQL Injection but we know there are other injections such as LDAP, XPath, NoSQL etc. Code injection attacks give the attacker the ability to change a section of code which is executed in order to compromise a system. The Sony hack in 2011 was such an attack and it’s usually due to untrusted data not being properly sanitized. This is only a high-level description of the problem and there are in-depth mitigation techniques that can help you protect against such an attack. The biggest risk comes from un-trusted data. The portion of the query that changes based on user input. To help mitigate against this risk, you could:
a. Sanitise all untrusted data and user input both on the client and server side
b. Use parameterised queries
c. Process data based on a white-listed set of values and stop processing as soon as there's an exception
d. Do not hard-code sql query strings. This goes without saying as it's bad practice for many reasons, but if you do, please stop.
Broken Authentication and Session Management
The number 2 security risk in the list is still a massive issue for many websites out there. This all comes down to not using the appropriate measures to protect user accounts and session information. A very simple example highlighting this problem is login forms that load over HTTP only to redirect to HTTPS once successfully logged in. Another problem is allowing weak passwords using superficial restrictions (8-16 characters, no special characters etc). Ensure that you protect your cookies, use HTTPS throughout your site and hash your stored passwords
Cross Site Scripting (XSS)
Our number 3 attack is another form of Code Injection Attack, primarily using JavaScript these days, rendered within a browser which ultimately results in the attacker being able to take control of a user’s browser and assume their identity. There are 2 types of XSS attacks:
a) Reflected
b) Persistent
Reflected attacks are targeted and can only affect one person at a time, whereas persistent XSS attacks can infect any user accessing the compromised page. Again, you need to make sure you sanitize untrusted data (i.e url parameters etc), encode web requests and responses and ensure that your cookies are protected.
Insecure Direct Object Reference
This type of attack allows malicious users to access otherwise unauthorised data by manipulating known information such as a URL parameter. This attack is possible because there are inadequate security guards in place to ensure that only authorised users should have access to specific pieces of information. For example, just because my bank account URL is https://mysecurebank/account?id=12345 I shouldn’t be able to see someone else’s account by changing the Id parameter value. And yet, what OWASP is telling us is that this type of attack is still possible! To protect your resource, you should implement thorough Access Control and even go as far as introducing Indirect Reference Maps to hide away real-life keys.
Security Misconfiguration
Number 5 is a really broad type of attack due to the fact that security is a holistic approach with many moving parts. Any of these parts can be mistakenly misconfigured. Some examples of security misconfiguration that would allow an attacker to mount an attack:
a) Insufficiently secured web server logs
b) exposing internal code through improperly handled exceptions
c) exposing server/platform information through http headers
This information can be used by an attacker to penetrate the system using know vulnerabilities or data exposed through the attack. Due to the fact that this attack is so broad, it’s hard to provide mitigation advice but I’ve included some suggestions below:
a) ensure all OS and software is up-to-date
b) adopt Secure Development Lifecycle principles
c) make security part of your Change Management process
d) take advantage of Penetration Testing
Sensitive Data Exposure
Security risk number 6 refers to our failure to adequately protect high value assets from unauthorised access. A good example here is allowing an attacker to intercept user credentials during a login process through a Man In the Middle (MItM) attack due to lack of SSL. Because logging in over HTTP would send the user’s credentials in clear text and anyone able to intercept the data “over the wire” will instantly be able to impersonate that user. There are a few things you can do in order to mitigate against these risks:
a) encryption at rest and in transit
b) use SSL throughout your site
c) use strong encryption algorithms
d) implement a secure encryption key management
Missing Function Level Access Control
We’re already at number 7 and I would ask you to raise your hand if you ever implemented functionality that was hidden away on a page to non-site administrators. Like, say, the admin section! Guilty as charged. So this risk is about the absence of proper authorisation which could enable attackers to utilise code that they should not be able to execute. This is fairly wide security risk and there are many ways to protect against it such as:
a) protect against ‘force browsing’
b) deny access by default and only open up access in a piecemeal fashion.
c) do not write your own security features
d) test your site using an unauthorised user
Cross-Site Request Forgery (XSRF/CSRF)
“Sea-surf” (yes, really) or CSRF sits proudly at number 8. CSRF attacks are prevalent but easy to detect too. There’s also a big catch in the fact that the user needs to be authenticated and authorised for an attacker to pull this one off. The attack tricks users to submit a request without their knowledge to a previously authenticate site. Attackers can cause victims to change any data the victim is allowed to change or perform any function the victim is authorized to use. However, detection of CSRF flaws is fairly easy via penetration testing or code analysis. Other ways to protect your site include but are not limited to the following:
a) utilise built in controls such as Anti-Forgery Tokens, HTTPOnly Cookies, Access-Control-Allow-Origin Headers
b) request users to re-authenticate when performing important actions (e.g. authorising a payment to another bank account)
Using Components with Known Vulnerabilities
Using Windows Server 2003 with IIS7 in production – enough said. This attack relies on older, unpatched infrastructure or code in order to get to your system or data. If you use a package manager (NuGet, npm) to manage your dependencies, how often do you patch and update your packages to the latest version? Do you monitor the security bulletins for announcements pertinent to the software, libraries and tools you use? So how do you mitigate against threat number 9 in our list?
a) identify and catalogue all components being utilised within an application stack.
b) check for updates and common vulnerability and exposures (CVEs) to the components on a regular basis
c) automate integration testing of these components
d) patch components as you would the environment
Unvalidated Redirects and Forwards
Last but not least, this risk allows attackers to redirect users without their knowledge from a legitimate site to a phising or malware infected website. These sites are designed to look a lot like the legitimate ones, tricking the users to disclose sensitive information (login credentials). In the worst case scenario, users’ machines get infected with malware. In this case, your website becomes the conduit for launching this attack rather than the actual target. However, your users are the ones that have to suffer the consequences. To protect them, you can follow some of the mitigation guidelines below:
a) avoid using redirects and forwards if possible.
b) avoid allowing user input for creation of destination URL string if possible.
c) if user is input is used, validate user and destination URL string.
d) authorize access before redirecting
Summary
As much as I would like to say that you’re not at risk, I would be lying. If you have software running in the public domain, accessible by anyone with an internet connection, then you’re at risk. OWASP and security researches around the world are doing a great job in highlighting what's wrong with web security these days. Companies such as Microsoft and Google are also taking part in the effort to educate and help developers avoid some of this risks. Identifying and understanding these risks is the first step and, should you find that there are vulnerabilities in your software, you need to make sure that the appropriate mitigation techniques are implemented. It’s our responsibility to make the web a safer place, one website at a time. Stay safe.