Web Application Security Top 10 OWASP list

One of the best ways to check the security of your web-based applications is to check the Open Web Security Application Project (OWASP) Top 10 List.  OWASP has been the basis for a security checklist for 10 years now.  Did you know OWASP updated their Top 10 list this year?  How often do you look for the Top 10 risks in your web-based applications? 

The OWASP Top 10 list helps your organization learn from other organizations and gives you a framework to help manage the risk to your enterprise introduced by your applications.  This list provides a basis for your application security program, which should help your organization leverage its existing strengths to measure how it positively impacts your business goals and direction.

 

According to OWASP, in their release notes for the Top 10 2013, the “Top 10 for 2013 is based on 8 datasets from 7 firms that specialize in application security, including 4 consulting companies and 3 tool/SaaS vendors (1 static, 1 dynamic, and 1 with both). This data spans over 500,000 vulnerabilities across hundreds of organizations and thousands of applications. The Top 10 items are selected and prioritized according to this prevalence data, in combination with consensus estimates of exploitability, detectability, and impact estimates.”  So as you can see, this list allows you to learn and have a basis from a wide range of experience and data collected worldwide.

 

The OWASP Top 10 List

Injection flaws – An attacker sends simple text-based attacks that exploit a weakness in the way your application handles requests. These flaws are easy to discover when examining code, but frequently hard to discover via testing.

 

Broken Authentication and Session Management – When authentication and session management are implemented incorrectly it can allow attackers to compromise passwords or other implementation flaws to assume other users’ identities. An attacker uses flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to impersonate users. Many times this is found when organizations build custom authentication and session management schemes. The areas where you most often see flaws or weakness include: logout, password management, timeouts, remember me, secret question, account update, etc.

 

Cross-Site Scripting – Another type of an attack using text- based attack scripts that exploit your application in the web browser. Cross-Site Scripting (XSS) is the most prevalent web application security flaw. XSS flaws occur when an application includes user supplied data without properly validating the content.  Your application is vulnerable if you do not verify it to be safe via input validation, before including that input in the output page.

 

Insecure Direct Object References – When an attacker, who is an authorized system user, simply changes a parameter value that directly grants them access to something they are not authorized for. Applications don’t always verify if the user is authorized for the access they are requesting, which results in an insecure direct object reference flaw. The best defense is to verify that all requests have appropriate defenses.

 

Security Misconfiguration – Security misconfiguration allows an attacker to access: default accounts, unused pages, unpatched flaws, unprotected files, directories, and more; and to gain unauthorized access to or knowledge of the system. Security misconfiguration can happen in any component of an application, including: the platform, web server, application server, database, framework, and custom code. Developers and system administrators need to work together to ensure all system components are configured properly. Some questions to ask include: are any unnecessary features enabled or installed (e.g., ports, services, pages, accounts, privileges)?   Are default accounts and their passwords still enabled and unchanged? One of the best defenses in this area is to have a repeatable process that makes it fast and easy to deploy another environment that is properly locked down.

 

Sensitive Data Exposure – Attackers typically don’t break encryption directly. They break something else, such as stealing clear text data off the server, while in transit, or from the user’s browser. The most common flaw is simply not encrypting sensitive data. When encryption is employed it is generally weak. The first thing your organization needs to identify is what data is sensitive enough to require extra protection. For example, passwords, credit card numbers, health records, and personal information should be protected.

 

Missing Function Level Access Control – When an attacker, who is an authorized system user, simply changes the URL or a parameter to a privileged function, and it is granted you have a missing function level access control mechanism. Applications do not always protect application functions properly. This can be due to a system misconfiguration or a lack of checks included by the developers. 

 

Cross-Site Request Forgery – When an attacker creates forged requests and tricks a victim into submitting without the victim’s knowledge to gain access to a system. This type of attack takes advantage of the fact that most web applications allow attackers to predict all the details of a particular action, and this attack creates forged requests that are indistinguishable from legitimate ones.  The best defense is to include a unique token in a hidden field. This causes the value to be sent in the body request.

 

Using Components with Known Vulnerabilities – An attacker can identify a weak component in your application and customize and execute an attack. Many applications have these issues because their development teams don’t focus on ensuring the components used in their applications are up to date. Unfortunately, vulnerability reports for commercial or open source software do not always specify exactly which versions of a component are vulnerable in a standard, searchable way. If one of your components does have a vulnerability, you should carefully evaluate whether you are actually vulnerable by checking to see if your code uses the part of the component with the vulnerability and whether the flaw could result in an impact you care about.  Your security plan should establish security policies governing component use, such as requiring certain software development practices, passing security tests, and acceptable licenses.

 

Unvalidated Redirects and Forwards – An attacker links to an unvalidated redirect from your application and tricks victims into clicking it. Victims are more likely to click on it, since the link is to a valid site. Applications frequently redirect users to other pages, or use internal forwards in a similar manner. Sometimes the target page allows attackers to choose the destination page.  The best defense is to simply avoid using redirects and forwards.

Do you know how your web applications are checked for these top 10 risks?  How often are they checked for these risks?  The NCX Group recommends that you check all of your web applications at least quarterly for these risks to ensure that you are not leaving your data unprotected.