This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between pages "Top 10 2010-A3-Broken Authentication and Session Management" and "Top 10 2010-A2-Cross-Site Scripting (XSS)"

From OWASP
(Difference between pages)
Jump to: navigation, search
 
 
Line 1: Line 1:
−
{{Top_10_2010:TopTemplate|useprev=2010PrevLink|prev=A2-Cross-Site Scripting (XSS)|usenext=2010NextLink|next=A4-Insecure Direct Object References}}
+
{{Top_10_2010:TopTemplate|useprev=2010PrevLink|usenext=2010NextLink|prev=A1-Injection|next=A3-Broken Authentication and Session Management}}
 +
 
 
<center>
 
<center>
 
{| style="align:center; text-align:center; border:2px solid #4F81BD; background-color:#F2F2F2; padding=2;"  
 
{| style="align:center; text-align:center; border:2px solid #4F81BD; background-color:#F2F2F2; padding=2;"  
 
|- style="background-color: #4F81Bd; color: #FFFFFF;"
 
|- style="background-color: #4F81Bd; color: #FFFFFF;"
−
! Threat Agents !! Attack Vectors
+
! width="16.5%" | Threat Agents  
−
! colspan="2" | Security Weakness
+
! width="16.5%" | Attack Vectors
−
! Technical Impacts
+
! width="16.5%" colspan="2" | Security Weakness
−
! Business Impacts
+
! width="16.5%" | Technical Impacts
 +
! width="16.5%" | Business Impacts
 
|-  
 
|-  
 
| style="background-color: #D9D9D9; color: #000000;" | ______
 
| style="background-color: #D9D9D9; color: #000000;" | ______
 
| style="background-color: #FFB200; color: #000000;" | '''Exploitability<br>AVERAGE
 
| style="background-color: #FFB200; color: #000000;" | '''Exploitability<br>AVERAGE
−
| style="background-color: #FFB200; color: #000000;" | '''Prevalence<br>COMMON
+
| style="background-color: #FF00FF; color: #000000;" | '''Prevalence<br>VERY WIDESPREAD
−
| style="background-color: #FFB200; color: #000000;" | '''Detectability<br>AVERAGE
+
| style="background-color: #FF0000; color: #000000;" | '''Detectability<br>EASY
−
| style="background-color: #FF0000; color: #000000;" | '''Impact<br>SEVERE
+
| style="background-color: #FFB200; color: #000000;" | '''Impact<br>MODERATE
 
| style="background-color: #D9D9D9; color: #000000;" | ______
 
| style="background-color: #D9D9D9; color: #000000;" | ______
−
|-
+
|-valign="top"
−
| style="text-align: left; border: 2px solid #FFFFFF;" | Consider anonymous external attackers, as well as users with their own accounts, who may attempt to steal accounts from others. Also consider insiders wanting to disguise their actions.
+
| style="text-align: left; border: 2px solid #FFFFFF;" | Consider anyone who can send untrusted data to the system, including external users, internal users, and administrators.
−
| style="text-align: left; border: 2px solid #FFFFFF;" | Attacker uses leaks or flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to impersonate users.
+
| style="text-align: left; border: 2px solid #FFFFFF;" | Attacker sends text- based attack scripts that exploit the interpreter in the browser. Almost any source of data can be an attack vector, including internal sources such as data from the database.
−
| colspan="2" style="text-align: left;border: 2px solid #FFFFFF;" | Developers frequently build custom authentication and session management schemes, but building these correctly is hard. As a result, these custom schemes frequently have flaws in areas such as logout, password management, timeouts, remember me, secret question, account update, etc. Finding such flaws can sometimes be difficult, as each implementation is unique.
+
| colspan="2" style="text-align: left;border: 2px solid #FFFFFF;" | [[Cross-site_Scripting_(XSS) | XSS]] is the most prevalent web application security flaw. XSS flaws occur when an application includes user supplied data in a page sent to the browser without properly validating or escaping that content. There are three known types of XSS flaws: 1) [[Cross-site_Scripting_(XSS)#Stored_XSS_Attacks | Stored]], 2) [[Cross-site_Scripting_(XSS)#Reflected_XSS_Attacks | Reflected]], and 3) [[DOM_Based_XSS | DOM based XSS]].
−
| style="text-align: left; border: 2px solid #FFFFFF;" | Such flaws may allow some or even all accounts to be attacked. Once successful, the attacker can do anything the victim could do. Privileged accounts are frequently targeted.
+
 
−
| style="text-align: left; border: 2px solid #FFFFFF;" | Consider the business value of the affected data or application functions.
+
Detection of most XSS flaws is fairly easy via testing or code analysis.
 +
| style="text-align: left; border: 2px solid #FFFFFF;" | Attackers can execute scripts in a victim’s browser to hijack user sessions, deface web sites, insert hostile content, redirect users, hijack the user’s browser using malware, etc.
 +
| style="text-align: left; border: 2px solid #FFFFFF;" | Consider the business value of the affected system and all the data it processes.
  
 
Also consider the business impact of public exposure of the vulnerability.
 
Also consider the business impact of public exposure of the vulnerability.
 
|}
 
|}
 
</center>
 
</center>
−
{{Top_10_2010:SubsectionVulnerableTemplate|Broken Authentication and Session Management|}}
+
{{Top_10_2010:SubsectionVulnerableTemplate|XSS|
−
The primary assets to protect are credentials and session IDs.
+
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.
−
# Are credentials always protected when stored using hashing or encryption? [[Top_10_2010-A7 | See A7]].
+
 
−
# Can credentials be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password, weak session IDs)?
+
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.
−
# Are session IDs exposed in the URL (e.g., URL rewriting)?
 
−
# Are session IDs vulnerable to session fixation attacks?
 
−
# Do session IDs timeout and can users log out?
 
−
# Are session IDs rotated after successful login?
 
−
# Are passwords, session IDs, and other credentials sent only over TLS connections? [[Top_10_2010-A9 | See A9]].
 
−
See the [http://www.owasp.org/index.php/ASVS#tab=Downloads ASVS] requirement areas V2 and V3 for more details.
 
−
{{Top_10_2010:SubsectionPreventionTemplate|Broken Authentication and Session Management|}}
 
−
The primary recommendation for an organization is to make available to developers:
 
−
# A single set of strong authentication and session management controls. Such controls should strive to:
 
−
## meet all the authentication and session management requirements defined in OWASP’s [http://www.owasp.org/index.php/ASVS#tab=Downloads Application Security Verification Standard] (ASVS) areas V2 (Authentication) and V3 (Session Management).
 
−
## have a simple interface for developers. Consider the [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Authenticator.html ESAPI Authenticator and User APIs] as good examples to emulate, use, or build upon.
 
−
# Strong efforts should also be made to avoid XSS flaws which can be used to steal session IDs. [[Top_10_2010-A2 | See A2]].
 
−
{{Top_10_2010:SubsectionExampleTemplate|Broken Authentication and Session Management|}}
 
−
<u>Scenario #1</u>: Airline reservations application supports URL rewriting, putting session IDs in the URL:
 
−
:<b><nowiki>http://example.com/sale/saleitems</nowiki>;<span style="color:red;">jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV</span>?dest=Hawaii</b>
 
−
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.
 
  
−
<u>Scenario #2</u>: 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.
+
Web 2.0 technologies, such as AJAX, make XSS much more difficult to detect via automated tools.
 +
}}
 +
{{Top_10_2010:SubsectionPreventionTemplate|XSS|
 +
Preventing XSS requires keeping untrusted data separate from active browser content.
 +
# 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 [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | OWASP XSS Prevention Cheat Sheet]] for more information about data escaping techniques.
 +
# Positive or “whitelist” input validation with appropriate canonicalization and decoding is also recommended as it helps protect against XSS, but is <u>not a complete defense</u> 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.
 +
}}
 +
{{Top_10_2010:SubsectionExampleTemplate|XSS|}}
 +
The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:
 +
:[[File:Xss-snippet-1.png]]
 +
The attacker modifies the ‘CC’ parameter in their browser to:
 +
:[[File:Xss-snippet-2.png]]
 +
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.
  
−
<u>Scenario #3</u>: Insider or external attacker gains access to the system’s password database. User passwords are not encrypted, exposing every users’ password to the attacker.
+
Note that attackers can also use XSS to defeat any automated CSRF defense the application might employ. See [[Top_10_2010-A5 | A5 for info on CSRF]].
  
−
{{Top_10_2010:SubsectionReferencesTemplate|Broken Authentication and Session Management}}
+
{{Top_10_2010:SubsectionReferencesTemplate|XSS}}
 
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
 
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
−
For a more complete set of requirements and problems to avoid in this area, see the [http://www.owasp.org/index.php/ASVS#tab=Downloads ASVS requirements areas for Authentication (V2) and Session Management (V3)]
+
* [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | OWASP XSS Prevention Cheat Sheet]]
−
* [[Authentication_Cheat_Sheet | OWASP Authentication Cheat Sheet]]
+
* [[Cross-site_Scripting_(XSS) | OWASP Cross-Site Scripting Article]]
−
* [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Authenticator.html ESAPI Authenticator API]
+
* [[ESAPI | ESAPI Project Home Page]]
−
* [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/User.html ESAPI User API]
+
* [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Encoder.html ESAPI Encoder API]
−
* [[Guide_to_Authentication | OWASP Development Guide: Chapter on Authentication]]
+
* [http://www.owasp.org/index.php/ASVS#tab=Downloads ASVS: Output Encoding/Escaping Requirements (V6)]
−
* [[Testing_for_authentication | OWASP Testing Guide: Chapter on Authentication]]
+
* [http://www.owasp.org/index.php/ASVS#tab=Downloads ASVS: Input Validation Requirements (V5)]
 +
* [[Testing_for_Data_Validation | Testing Guide: 1st 3 Chapters on Data Validation Testing]]
 +
* [[Reviewing_Code_for_Cross-site_scripting | OWASP Code Review Guide: Chapter on XSS Review]]
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate}}
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate}}
−
* [http://cwe.mitre.org/data/definitions/287.html CWE Entry 287 on Improper Authentication]
+
* [http://cwe.mitre.org/data/definitions/79.html CWE Entry 79 on Cross-Site Scripting]
−
{{Top_10_2010:BottomTemplate|useprev=2010PrevLink|prev=A2-Cross-Site Scripting (XSS)|usenext=2010NextLink|next=A4-Insecure Direct Object References}}
+
* [http://ha.ckers.org/xss.html RSnake's XSS Attack Cheat Sheet]
 +
{{Top_10_2010:BottomTemplate|useprev=2010PrevLink|usenext=2010NextLink|prev=A1-Injection|next=A3-Broken Authentication and Session Management}}
  
 
[[Category:OWASP Top Ten Project]]
 
[[Category:OWASP Top Ten Project]]

Revision as of 06:10, 23 April 2010

NOTE: THIS IS NOT THE LATEST VERSION. Please visit the OWASP Top 10 project page to find the latest edition.

← A1-Injection
Top 10 Introduction
Top 10 Risks
 A3-Broken Authentication and Session Management →
Threat Agents Attack Vectors Security Weakness Technical Impacts Business Impacts
______ Exploitability
AVERAGE 		Prevalence
VERY WIDESPREAD 		Detectability
EASY 		Impact
MODERATE 		______
Consider anyone who can send untrusted data to the system, including external users, internal users, and administrators. Attacker sends text- based attack scripts that exploit the interpreter in the browser. Almost any source of data can be an attack vector, including internal sources such as data from the database. XSS is the most prevalent web application security flaw. XSS flaws occur when an application includes user supplied data in a page sent to the browser without properly validating or escaping that content. There are three known types of XSS flaws: 1) Stored, 2) Reflected, and 3) DOM based XSS.

Detection of most XSS flaws is fairly easy via testing or code analysis.

Attackers can execute scripts in a victim’s browser to hijack user sessions, deface web sites, insert hostile content, redirect users, hijack the user’s browser using malware, etc. Consider the business value of the affected system and all the data it processes.

Also consider the business impact of public exposure of the vulnerability.

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.

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.

Example Attack Scenarios

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

Xss-snippet-1.png

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

Xss-snippet-2.png

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 automated CSRF defense the application might employ. See A5 for info on CSRF.

References

OWASP

External

← A1-Injection
Top 10 Introduction
Top 10 Risks
 A3-Broken Authentication and Session Management →
© 2002-2010 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. Some rights reserved. CC-by-sa-3 0-88x31.png
Retrieved from "https://wiki.owasp.org/index.php?title=Top_10_2010-A3-Broken_Authentication_and_Session_Management&oldid=82307"