Top 10 2013-A2-Broken Authentication and Session Management

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

[[Top 10 {{{year}}}-Injection|← Injection]]

[[Top 10 {{{year}}}-Table of Contents | {{{year}}} Table of Contents]] [[Top_10_{{{year}}}-Top 10|{{{year}}} Top 10 List]]

[[Top 10 {{{year}}}-Cross-Site Scripting (XSS)|Cross-Site Scripting (XSS) →]]

Threat Agents	Attack Vectors	Security Weakness		Technical Impacts	Business Impacts
Application Specific	Exploitability AVERAGE	Prevalence WIDESPREAD	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. Are credentials always protected when stored using hashing or encryption? See A6. Can credentials be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password, weak session IDs)? 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? See A6. 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: 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 Application Security Verification Standard (ASVS) areas V2 (Authentication) and V3 (Session Management). have a simple interface for developers. Consider the 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. See A3. blankBullet1 blankBullet2

Example Attack Scenarios blank blank code blank http://example.com/app/accountView?id=' or '1'='1 blank

References OWASP OWASP SQL Injection Prevention Cheat Sheet ESAPI Encoder API External CWE Entry 77 on Command Injection CWE Entry 89 on SQL Injection

[[Top 10 {{{year}}}-Injection|← Injection]]

[[Top 10 {{{year}}}-Table of Contents | {{{year}}} Table of Contents]] [[Top_10_{{{year}}}-Top 10|{{{year}}} Top 10 List]]

[[Top 10 {{{year}}}-Cross-Site Scripting (XSS)|Cross-Site Scripting (XSS) →]]

---

© 2002-2013 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. Some rights reserved. [[Category:OWASP Top Ten {{{year}}} Project]]