Session Management (SMQ)
Салим может обойти управление сессиями, потому что оно не применяется всесторонне и последовательно по всему приложению
Incomplete and inconsistent session management across different parts of an application enables attackers to exploit gaps, bypass session controls, and hijack or spoof user sessions. See Session Management (SMK) for what session management routines to use.
Scenario: Salim’s Bypass of Inconsistent Session Management
Envision a situation where Salim takes advantage of an application’s inconsistent application of session management. This vulnerability arises because:
- Inconsistent Application Across Features: Different parts of the application implement session management with varying degrees of rigor.
- Comprehensive Coverage Lacking: Certain areas or functionalities of the application lack proper session management controls.
Example
Salim targets a multi-faceted web application that has robust session management for its main features, like user profiles and dashboards. However, he discovers that the newer modules, such as a recently added chat function, lack similar session controls. He exploits these less secure areas to gain unauthorized access, manipulating session tokens or hijacking sessions where the system’s oversight is most pronounced.
Threat Modeling
STRIDE
This scenario maps primarily to STRIDE: Spoofing.
Spoofing is about impersonating a legitimate user or entity. Salim exploits areas of the application where session management is not applied consistently, allowing him to bypass session checks and act as an authenticated user without proper authorization. The attack’s core is unauthorized impersonation via gaps in session enforcement, making Spoofing the correct primary category.
What can go wrong?
Inconsistencies in session management across an application can lead to unauthorized access and potential exploitation of the less secure areas, compromising overall system security.
For more things that can go wrong, see the Common Attack Patterns related to this card in the table below.
What are we going to do about it?
Every part of the application and type of request should verify that the user has a valid current session (if required) and thus their privileges, before undertaking any other data validation and processing.
- Ensure uniform implementation of session management controls across all areas and functionalities of the application.
- Conduct thorough security reviews and testing, especially when integrating new features or modules, to ensure they meet established session management standards.
- Regularly update and harmonize session management practices to maintain comprehensive and consistent security coverage.
For detailed advice on how to mitigate threats related to the card, see the ASVS and OWASP Developer Guide requirements in the table below.
Mappings
OWASP ASVS (v5.0): 4.4.3,7.1.1,7.1.2,7.1.3,7.2.1,7.2.2,7.2.3,7.2.4,7.3.1,7.3.2,7.4.1,7.4.2,7.4.3,7.4.4,7.4.5,7.5.1,7.5.2,7.5.3,7.6.1,10.1.1,10.1.2,10.2.1,10.2.2,10.2.3,10.3.1,10.3.2,10.3.3,10.3.4,10.3.5,10.4.1,10.4.2,10.4.3,10.4.4,10.4.5,10.4.6,10.4.7,10.4.8,10.4.9,10.4.10,10.4.11,10.4.12,10.4.13,10.4.14,10.4.15,10.4.16,10.5.1,10.5.2,10.5.3,10.5.4,10.5.5,10.6.1,10.6.2,10.7.1,10.7.2,10.7.3
OWASP DevGuide: SM1
STRIDE: Spoofing
CAPEC Map
| Code | Title | ASVS |
|---|---|---|
| 21 | Exploitation of Trusted Identifiers | 4.4.3,7.1.1,7.1.2,7.1.3,7.2.1,7.2.2,7.2.3,7.2.4,7.3.1,7.3.2,7.4.1,7.4.2,7.4.3,7.4.4,7.4.5,7.5.1,7.5.2,7.5.3,7.6.1 |
| 633 | Token Impersonation | 4.4.3,10.1.1,10.1.2,10.2.1,10.2.2,10.2.3,10.3.1,10.3.2,10.3.3,10.3.4,10.3.5,10.4.1,10.4.2,10.4.3,10.4.4,10.4.5,10.4.6,10.4.7,10.4.8,10.4.9,10.4.10,10.4.11,10.4.12,10.4.13,10.4.14,10.4.15,10.4.16,10.5.1,10.5.2,10.5.3,10.5.4,10.5.5,10.6.1,10.6.2,10.7.1,10.7.2,10.7.3 |
ASVS (5.0) Cheat Sheet Series Index
No attacks registered!
