A flawed Web application is a security risk. OWASPs Top 10 Vulnerabilities is a powerful document that raises awareness about the dangers out there and pinpoints possible flaws in a Web application. It also suggests ways and means to counter these susceptibilities. OWASP enjoys the support and backing of security experts from around the world.
Allow me to begin this article by asking a simple question. Can you say, with absolute surety, that your house is theft-proof? If your answer is, Yes, then youre living under a false sense of security. However, if your answer is No, then we have something to talk about. You may have state-of-the-art security systems installed in your home but none will be a good enough match against determined burglars. The security system will definitely make their task difficult, but it wont be able to stop them. All that would be required is for them to find the Achilles heel of your security system. You might wonder that if no security system is good then why even bother installing one? Why not leave your house wide open for the burglar? While security systems might not block out the burglars entirely, they will enable you to protect the vulnerable spots of your house and give you enough time to detect the burglars and take action.
If you replace the word house with Web application in the above scenario, the argument is still valid. The only difference is that the number of vulnerable spots in a Web application is much more than in a house. Also, given the fact that a Web application will most likely be exposed to the world at large, the number of threat agents and attack vectors increases exponentially. Therefore, in order to develop a secure Web application, developers will have to think of each of the possible ways in which their app can be compromised. Considering that there are more than 500,000 ways in which this can be done, by the time the application is ready to hit the market after being tested, it might already be out-of-date. How do developers then ensure that they develop a secure application without any significant impact on its time to market and its usability? The answer to this lies in the Open Web Application Security Project (OWASP).
The Open Web Application Security Project (OWASP)
The Open Web Application Security Project (OWASP) (http://owasp.org) is a not for profit community dedicated to help developers design and develop secure Web applications. It enables them to prioritise their efforts by publishing various standards, guides, cheat sheets, etc, in order to secure applications. Started in 2001 by Mark Curphey, it has grown to include several organisations, educational institutions and volunteers working towards building a secure Web.
Among its various projects, every three years, OWASP publishes a list of the top 10 vulnerabilities that plague Web applications. The list is published after extensive research, which includes the survey of the top four consulting companies in the world and three software vendors. In total, the project goes through a database of approximately 500,000 vulnerabilities and shortlists the top 10. The list was last published in 2013.
In addition to publishing this list, OWASP also includes the means and methods to counter them. The following section briefly describes each of the 10 vulnerabilities and their countermeasures (for more details, please visit http://goo.gl/p6rAzr).
OWASPs top 10 vulnerabilities, 2013
1. Injection
A Web application is vulnerable to injection when it accepts commands or queries in input fields, meant for obtaining information from the user. A classic example is SQL Injection, wherein the attacker injects SQL queries in an input field in order to bypass the authentication mechanism.
How to fix it: Use safe or parametrised APIs, escape special characters, provide white list input validation (e.g., if a field is meant to accept numeric values, the application should not permit the user to enter letters of the alphabet).
2. Broken authentication and session management
This flaw can occur when authentication mechanisms are not implemented properly (e.g., sending or storing credentials in plain text; when password recovery allows passwords to be changed without proper authentication and verification of the user, etc) or when sessions are poorly managed (e.g., if the session time-out is not defined; if session IDs are exposed in the URL, etc).
How to fix it: Use standards like ISO 27001:2013 or OWASPs Application Security Verification Standard (ASVS) when defining authentication and session management requirements for the Web application. Ensure that the Cross Site Scripting (XSS – explained later) flaw is taken care of.
3. Cross Site Scripting (XSS)
A Cross Site Scripting vulnerability allows an attacker to insert malicious script/code in a Web page that directs the users browser to perform a malicious action. For example, an attacker can leave a simple JavaScript code in a websites comments section, which redirects anyone visiting that website to a fake login page.
How to fix it: Avoid special characters, use white list input validation, use auto-sanitisation libraries for rich content, and employ the Content Security Policy to protect the entire website from XSS.
4. Insecure direct object references
Web applications often expose actual object names to users while generating Web pages (e.g., <URL>/acntID=1234). However, if they fail to verify a users access privilege to that particular object, users could manipulate the object value and access information that they are not authorised to. For example, in the above URL, a user may put acntID as 4567 and be able to access the information of that account even though hes not privileged to do so.
How to fix it: Check users access privileges to each object reference before granting access to it; use session-specific or user-specific mapping of objects to avoid direct references.
5. Security misconfiguration
Most software like Web servers, database servers, programming platforms, etc, ship with disabled security controls. Often, Web developers either forget to configure these controls or configure them loosely. This enables the attacker to break into the system very easily.
How to fix it: Harden the system, i.e., disable unnecessary functionality in the underlying applications, patch and update the systems regularly, and keep track of the libraries used in the Web application (update, if the new version is available or discard if its no longer supported). Regularly run vulnerability scans and penetration tests to uncover flaws.
6. Exposure to sensitive data
One of the most common flaws in Web applications is their failure to protect sensitive data adequately. They either store or transmit data in plain text, use weak encryption and hashing algorithms, or the keys arent properly managed. Exploitation of all or any one of these can have a massive negative impact on a business reputation.
How to fix it: Use FIPS-certified data encryption algorithms, collect and store only whats necessary, delete the data once it has served its purpose and disable auto-complete.
7. Missing function-level access control
This flaw occurs when the access to application functions isnt validated. For example, a Web application may hide the link to the Administration console by not presenting it to a normal user. However, it does not implement any function level access control to check who is accessing administration functions. As a result, normal users can access administration functions, provided they know which ones to use.
How to fix it: Implement access control on all functions handling sensitive data or functionality. At the least, assign roles to the users and validate their roles before granting access to sensitive functions.
8. Cross-Site Request Forgery (CSRF)
CSRF occurs when an attacker can craft a Web page that requests the users browser to send session information of some other website (e.g., sample.com). The browser senses this as a valid request and sends the requested information to the attackers server. Thus the attacker can forge the users session on sample.com with the stolen information.
How to fix it: Hide CSRF tokens in the body of the Web page, use CAPTCHA as a means for users to confirm their actions, etc.
9. Using components with known vulnerabilities
Most Web applications use third party libraries to implement certain functionality. While this saves on development efforts and time, it may become a developers nightmare if such libraries are not managed properly. For example, consider a Web application using a certain reporting library, which has reached its end-of-support phase. If the developers fail to keep track of this library, their application will be vulnerable to future vulnerabilities affecting the library.
How to fix it: Keep track of the versions, patches and upgrades of the libraries in use; discard libraries that are no longer in development or have reached the end-of-support phase. Create a policy outlining the process for safe usage of such libraries.
10. Invalid redirects and forwards
Redirects and forwards are a common occurrence in a Web application and its important to check whether or not they lead to a valid or correct page. If attackers can modify the parameters of the redirection URL and change the landing page, they can bypass the websites security mechanisms or lead users to disclose sensitive information.
How to fix it: Avoid using redirects and forwards. If they cant be avoided, ensure that no user parameters are involved in generating the landing page. If user parameters are to be used, ensure that they are properly validated.
Additional measures to secure Web applications
OWASPs ranking of the top ten vulnerabilities enables developers to secure their Web applications against the most prevalent vulnerabilities but this complex task doesnt end here. Once these are taken care of, Web developers should look at the environments in which their application will be used, who are its target users, etc. For example, if the application is being developed for military purposes, itll need to have strong access control mechanisms. If it is to be used in the health care industry, then encryption and the protection of data from leakage takes priority.
The IT environment differs from one organisation to another and each environment has its set of vulnerabilities. Web applications developers must take this factor into consideration and secure their applications with respect to the environment in which the Web application will operate.
Protecting applications from hobby hackers is a thing of the past. Attackers now have advanced skill sets and use sophisticated techniques to crack websites. Day in and day out theres news of some website being hacked and sensitive data being leaked (e.g., Dropbox, Apple iCloud, RSA, Snapchat, etc). Cracking into websites has become a booming business in the online underworld.
While attackers only have to find a new attack vector, Web developers are tasked with protecting their applications against known attacks as well as those that are yet unknown. The OWASP community has done a lot to ease the burden of Web developers by publishing the list of the top 10 vulnerabilities. Based on this, developers can prioritise their development efforts and develop secure Web applications without compromising a projects deadline or the overall user experience.
