|Threat Agents||Attack Vectors||Security Weakness||Technical Impacts||Business Impacts|
|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’?
Are session management assets like user credentials and session IDs properly protected? You may be vulnerable if:
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:
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 properly hashed, exposing every users’ password to the attacker.
Support ls /blog