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 revisions of "Top 10 2010-A3-Broken Authentication and Session Management"
(4 intermediate revisions by the same user not shown) | |||
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|prev=A2-Cross-Site Scripting (XSS)|usenext=2010NextLink|next=A4-Insecure Direct Object References}} | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | Also consider the business impact of public exposure of the vulnerability. | + | {{Top_10_2010:SummaryTableHeaderBeginTemplate}} |
− | + | {{Top_10_2010:SummaryTableValue-2-Template|Exploitability|AVERAGE}} | |
− | + | {{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}} | |
− | {{Top_10_2010: | + | {{Top_10_2010:SummaryTableValue-2-Template|Detectability|AVERAGE}} |
+ | {{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}} | ||
+ | {{Top_10_2010:SummaryTableHeaderEndTemplate}} | ||
+ | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>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.</td> | ||
+ | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Attacker uses leaks or flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to impersonate users.</td> | ||
+ | <td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>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.</td> | ||
+ | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>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.</td> | ||
+ | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the business value of the affected data or application functions.<br/><br/>Also consider the business impact of public exposure of the vulnerability.</td> | ||
+ | {{Top_10_2010:SummaryTableEndTemplate}} | ||
+ | |||
+ | {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=1|risk=3}} | ||
The primary assets to protect are credentials and session IDs. | The primary assets to protect are credentials and session IDs. | ||
# Are credentials always protected when stored using hashing or encryption? [[Top_10_2010-A7 | See A7]]. | # Are credentials always protected when stored using hashing or encryption? [[Top_10_2010-A7 | See A7]]. | ||
Line 35: | Line 24: | ||
# Are passwords, session IDs, and other credentials sent only over TLS connections? [[Top_10_2010-A9 | See A9]]. | # 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. | See the [http://www.owasp.org/index.php/ASVS#tab=Downloads ASVS] requirement areas V2 and V3 for more details. | ||
− | {{Top_10_2010: | + | {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=2|risk=3}} |
The primary recommendation for an organization is to make available to developers: | 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: | # A single set of strong authentication and session management controls. Such controls should strive to: | ||
Line 41: | Line 30: | ||
## 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. | ## 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]]. | # 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: | + | {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=3|risk=3}} |
<u>Scenario #1</u>: Airline reservations application supports URL rewriting, putting session IDs in the URL: | <u>Scenario #1</u>: Airline reservations application supports URL rewriting, putting session IDs in the URL: | ||
− | : | + | {{Top_10_2010:ExampleBeginTemplate}}<nowiki>http://example.com/sale/saleitems</nowiki>;<span style="color:red;"><br/>jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV</span><br/>?dest=Hawaii{{Top_10_2010:ExampleEndTemplate}} |
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. | 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. | ||
Line 50: | Line 39: | ||
<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. | <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. | ||
− | {{Top_10_2010: | + | {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=4|risk=3}} |
{{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)] | 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)] | ||
Line 60: | Line 49: | ||
{{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/287.html CWE Entry 287 on Improper Authentication] | ||
− | {{Top_10_2010: | + | {{Top_10_2010:BottomAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|useprev=2010PrevLink|prev=A2-Cross-Site Scripting (XSS)|usenext=2010NextLink|next=A4-Insecure Direct Object References}} |
[[Category:OWASP Top Ten Project]] | [[Category:OWASP Top Ten Project]] |
Latest revision as of 05:26, 2 May 2010
NOTE: THIS IS NOT THE LATEST VERSION. Please visit the OWASP Top 10 project page to find the latest edition.
← A2-Cross-Site Scripting (XSS) | Top 10 Risks |
A4-Insecure Direct Object References → |
Threat Agents | Attack Vectors | Security Weakness | Technical Impacts | Business Impacts | |
---|---|---|---|---|---|
Application Specific | Exploitability AVERAGE |
Prevalence COMMON |
Detectability AVERAGE |
Impact SEVERE |
Application / Business Specific |
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. | Attacker uses leaks or flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to impersonate users. | 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. | 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. | Consider the business value of the affected data or application functions. Also consider the business impact of public exposure of the vulnerability. |
Am I Vulnerable To 'Broken Authentication and Session Management'?
The primary assets to protect are credentials and session IDs.
See the ASVS requirement areas V2 and V3 for more details. |
How Do I Prevent 'Broken Authentication and Session Management'?
The primary recommendation for an organization is to make available to developers:
|
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. |
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)
External |
← A2-Cross-Site Scripting (XSS) | Top 10 Risks |
A4-Insecure Direct Object References → |
![CC-by-sa-3 0-88x31.png](/images/6/64/CC-by-sa-3_0-88x31.png)