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-2017 A2-Broken Authentication"

From OWASP
Jump to: navigation, search
(Updated PrevLink and NextLink)
Line 1: Line 1:
 
{{Top_10_2013:TopTemplate
 
{{Top_10_2013:TopTemplate
−
     |usenext=2013NextLink
+
     |usenext=2017NextLink
 
     |next=A3-{{Top_10_2010:ByTheNumbers
 
     |next=A3-{{Top_10_2010:ByTheNumbers
 
               |3
 
               |3
 
               |year=2017
 
               |year=2017
 
               |language=en}}
 
               |language=en}}
−
     |useprev=2013PrevLink
+
     |useprev=2017PrevLink
 
     |prev=A1-{{Top_10_2010:ByTheNumbers
 
     |prev=A1-{{Top_10_2010:ByTheNumbers
 
               |1
 
               |1

Revision as of 00:19, 12 December 2017

← A1-Injection
2017 Table of Contents

PDF version

A3-Sensitive Data Exposure →
Threat Agents / Attack Vectors Security Weakness Impacts
App Specific Exploitability
AVERAGE		 Prevalence
COMMON		 Detectability
AVERAGE		 Impact
SEVERE		 Business ?

Consider anonymous external attackers, as well as authorized users, who may attempt to steal accounts from others. Also consider insiders wanting to disguise their actions.

Attackers use leaks or flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to temporarily or permanently 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, create account, change password, forgot password, 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'?

Are session management assets like user credentials and session IDs properly protected? You may be vulnerable if:

  1. User authentication credentials aren’t properly protected when stored using hashing or encryption. See 2017-A6.
  2. Credentials can be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password, weak session IDs).
  3. Session IDs are exposed in the URL (e.g., URL rewriting).
  4. Session IDs are vulnerable to session fixation attacks.
  5. Session IDs don’t timeout, or user sessions or authentication tokens (particularly single sign-on (SSO) tokens) aren’t properly invalidated during logout.
  6. Session IDs aren’t rotated after successful login.
  7. Passwords, session IDs, and other credentials are sent over unencrypted connections. See 2017-A6.

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

How Do I Prevent 'Broken Authentication'?

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.
  2. Strong efforts should also be made to avoid XSS flaws which can be used to steal session IDs. See 2017-A3.
Example Attack Scenarios

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

http://example.com/sale/saleitems;
sessionid=268544541&dest=Hawaii

An authenticated user of the site wants to let their friends know about the sale. User e-mails the above link without knowing they are also giving away their session ID. When the friends use the link they use user’s 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. An attacker uses the same browser an hour later, and that browser is still authenticated.

Scenario #3: An insider or external attacker gains access to the system’s password database. User passwords are not properly hashed and salted, exposing every users’ password.

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

← A1-Injection
2017 Table of Contents

PDF version

A3-Sensitive Data Exposure →
© 2002-2017 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-2017_A2-Broken_Authentication&oldid=236174"