OWASP - The Top 10 Most Critical Web Application Security Risks 2010

Web Application Security Risks

OWASP Top 10 – 2010The Top 10 Most Critical Web Application Security Risks

Dave Wichers COO, Aspect Security OWASP Board Member dave.wichers@ dave.wichers@Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.

The OWASP Foundation/

Web Application Security Risks

What’s Changed?

OWASP - 2010

Web Application Security Risks

Mapping from 2007 to 2010 Top 10OWASP Top 10 – 2007 (Previous)A2 – Injection Flaws A1 – Cross Site Scripting (XSS) A7 – Broken Authentication and Session Management A4 – Insecure Direct Object Reference A5 – Cross Site Request Forgery (CSRF) <was T10 2004 A10 – Insecure Configuration Management> A8 – Insecure Cryptographic Storage A10 – Failure to Restrict URL Access A9 – Insecure Communications <not in T10 2007> A3 – Malicious File Execution A6 – Information Leakage and Improper Error Handling

OWASP Top 10 – 2010 (New)A1 – Injection A2 – Cross Site Scripting (XSS) A3 – Broken Authentication and Session Management

= A4 – Insecure Direct Object References = A5 – Cross Site Request Forgery (CSRF) + A6 – Security Misconfiguration (NEW)A7 – Insecure Cryptographic Storage A8 – Failure to Restrict URL Access

= A9 – Insufficient Transport Layer Protection + A10 – Unvalidated Redirects and Forwards (NEW)

-

<dropped from T10 2010> <dropped from T10 2010>

OWASP - 2010

Web Application Security Risks

OWASP Top 10 Risk Rating Methodology

Threat Agent

Attack Vector

Weakness Prevalence Widespread Common Uncommon

Weakness Detectability Easy Average Difficult

Technical Impact Severe Moderate Minor

Business Impact

?

1 2 3

Easy Average Difficult

?

1

2 1.66

2 *

1 1

Injection Example

1.66 weighted risk ratingOWASP - 2010

Web Application Security Risks

OWASP Top Ten (2010 Edition)

/index.php/Top_10

OWASP - 2010

Web Application Security Risks

A1 – Injection

OWASP - 2010

Web Application Security Risks

SQL Injection – IllustratedCommunication Knowledge Mgmt E-Commerce Bus. Functions

Legacy Systems

Administration Transactions

Application Layer

Human Resrcs

Web Services

Directories

Accounts Finance

Databases

HTTP request APPLICATIONATTACK

HTTP SQL response queryCustom Code

DB Table

Billing

"SELECT * FROM Account Summary Account: Account: accounts WHERE SKU: acct=‘’ OR 1=1-Acct:5424-6066-2134-4334 Acct:4128-7574-3921-0192 ’"Acct:5424-9383-2039-4029 Acct:4128-0004-1234-0293

1. Application presents a form to the attacker 2. Attacker sends an attack in the form data 3. Application forwards attack to the database in a SQL query 4. Database runs query containing attack and sends encrypted results back to application 5. Application decrypts data as normal and sends results to the userOWASP - 2010

App Server Web Server Network Layer Hardened OS

Firewall

Firewall

Web Application Security Risks

A1 – Avoiding Injection FlawsRecommendations1. Avoid the interpreter entirely, or 2. Use an interface that supports bind variables (e.g., prepared statements, or stored procedures),Bind variables allow

the interpreter to distinguish between code and data

3. Encode all user input before passing it to the interpreter Always perform ‘white list’ input validation on all user supplied input Always minimize database privileges to reduce the impact of a flaw

ReferencesFor more details, read the new/index.php/SQL_Injection_Prevention_Cheat_Sheet OWASP - 2010

Web Application Security Risks

A2 – Cross-Site Scripting (XSS)

OWASP - 2010

Web Application Security Risks

Cross-Site Scripting Illustrated1 Attacker sets the trap – update my profile Application with stored XSS vulnerability

2

Script runs inside victim’s browser with full access to the DOM and cookies

3

Script silently sends attacker Victim’s session cookieOWASP - 2010

Accounts Finance

Victim views page – sees attacker profile

Custom Code

Communication Knowledge Mgmt E-Commerce Commerce Bus. Functions

Attacker enters a malicious script into a web page that stores the data on the server

Administration Transactions

Web Application Security Risks

A2 – Avoiding XSS FlawsRecommendationsEliminate FlawDon’t include user supplied input in the output page

Defend Against the FlawPrimary Recommendation: Output encode all user supplied input (Use OWASP’s ESAPI to output encode: /index.php/ESAPI Perform ‘white list’ input validation on all user input to be included in page For large chunks of user supplied HTML, use OWASP’s AntiSamy to sanitize this HTML to make it safe See: /index.php/AntiSamy

ReferencesFor how to output encode properly, read the new/index.php/XSS_(Cross Site Scripting) Prevention Cheat Sheet OWASP - 2010

(AntiSamy)

Web Application Security Risks

Safe Escaping Schemes in Various HTML Execution Contexts#1: ( &, <, >, " ) &entity; ( ', / ) ESAPI: encodeForHTML() &#xHH;

HTML Element Content(e.g., <div> some text to display </div> )

#2: All non-alphanumeric < 256 &#xHH ESAPI: encodeForHTMLAttribute()

HTML Attribute Values(e.g., <input name='person' type='TEXT' value='defaultValue'> ) #3: All non-alphanumeric < 256 \xHH ESAPI: encodeForJavaScript()

JavaScript Data(e.g., <script> some javascript </script> )

HTML Style Property Values(e.g., .pdiv a:hover {color: red; text-decoration: underline} )

#4: All non-alphanumeric < 256 ESAPI: encodeForCSS()

\HH

URI Attribute Values(e.g., <a href="javascript:toggle('lesson')" )

#5: All non-alphanumeric < 256 ESAPI: encodeForURL()

%HH

ALL other contexts CANNOT include Untrusted DataRecommendation: Only allow #1 and #2 and disallow all others See: /index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet for more OWASP - 2010 details

Web Application Security Risks

A3 – Broken Authentication and Session Management

OWASP - 2010

Web Application Security Risks

Broken Authentication IllustratedCommunication Knowledge Mgmt E-Commerce Bus. Functions Administration Transactions

1

User sends credentialsAccounts Finance

?JSESSIONID=9FA1DB9EA... Site uses URL rewriting (i.e., put session in URL) 2

Custom Code

3

User clicks on a link to

in a forum

Hacker checks referer logs on and finds user’s JSESSIONID 5 Hacker uses JSESSIONID and takes over victim’s account

4

OWASP - 2010

Web Application Security Risks

A3 – Avoiding Broken Authentication and Session ManagementVerify your architectureAuthentication should be simple, centralized, and standardized Use the standard session id provided by your container Be sure SSL protects both credentials and session id at all times

Verify the implementationForget automated analysis approaches Check your SSL certificate Examine all the authentication-related functions Verify that logoff actually destroys the session Use OWASP’s WebScarab to test the implementation

Follow the guidance from/index.php/Authentication_Cheat_SheetOWASP - 2010

Web Application Security Risks

A4 – Insecure Direct Object ReferencesHow do you protect access to your data? This is part of enforcing proper “Authorization”, along with A7 – Failure to Restrict URL Access A common mistake … Only listing the ‘authorized’ objects for the current user, or Hiding the object references in hidden fields … and then not enforcing these restrictions on the server side This is called presentation layer access control, and doesn’t work Attacker simply tampers with parameter value Typical Impact Users are able to access unauthorized files or dataOWASP - 2010

Web Application Security Risks

Insecure Direct Object References Illustratedhttps:///user?acct=6065

Attacker notices his acct parameter is 6065 ?acct=6065 He modifies it to a nearby number ?acct=6066 Attacker views the victim’s account informationOWASP - 2010

Web Application Security Risks

A4 – Avoiding Insecure Direct Object ReferencesEliminate the direct object referenceReplace them with a temporary mapping value (e.g. 1, 2, 3) ESAPI provides support for numeric & random mappingsIntegerAccessReferenceMap & RandomAccessReferenceMap

http://app?file=Report123.xls http://app?file=1 http://app?id=9182374 http://app?id=7d3J93

Access Reference Map

Report123.xls Acct:9182374

Validate the direct object referenceVerify the parameter value is properly formatted Verify the user is allowed to access the target objectQuery constraints work great!

Verify the requested mode of access is allowed to the target object (e.g., read, write, delete)OWASP - 2010

Web Application Security Risks

A5 – Cross Site Request Forgery (CSRF)Cross Site Request Forgery An attack where the victim’s browser is tricked into issuing a command to a vulnerable web application Vulnerability is caused by browsers automatically including user authentication data (session ID, IP address, Windows domain credentials, …) with each request Imagine… What if a hacker could steer your mouse and get you to click on links in your online banking application? What could they make you do? Typical Impact Initiate transactions (transfer funds, logout user, close account) Access sensitive data Change account detailsOWASP - 2010

Web Application Security Risks

CSRF Vulnerability PatternThe Probl

emWeb browsers automatically include most credentials with each request Even for requests caused by a form, script, or image on another site

All sites relying solely on automatic credentials are vulnerable!(almost all sites are this way)

Automatically Provided CredentialsSession cookie Basic authentication header IP address Client side SSL certificates Windows domain authenticationOWASP - 2010

Web Application Security Risks

CSRF Illustrated1 Attacker sets the trap on some website on the internet (or simply via an e-mail)

2

While logged into vulnerable site, victim views attacker site

Custom Code

3 <img> tag loaded by browser – sends GET request (including credentials) to vulnerable site Vulnerable site sees legitimate request from victim and performs the action requestedOWASP - 2010

Communication Knowledge Mgmt E-Commerce Commerce Bus. Functions

Hidden <img> tag contains attack against vulnerable site

Application with CSRF vulnerability

Administration Transactions

Accounts Finance

本文来源：https://www.bwwdw.com/article/1soe.html