Session Management (SMK)
Peter pode contornar os controles de gerenciamento de sessão porque eles foram construídos internamente e/ou são fracos, ao invés de usar um framework padrão ou módulo aprovado e testado
Relying on self-built, inadequately tested session management instead of a standard, vetted framework lets attackers bypass controls and hijack user sessions. See Session Management (SMQ) for application-wide coverage.
Scenario: Peter’s Exploitation of Self-Built Weak Session Controls
Imagine a scenario where Peter exploits vulnerabilities in an application that relies on self-built, potentially weak session management controls instead of using a standard, well-tested framework or module. This situation arises due to:
- Self-Built Session Management Systems: The application uses custom-built session management mechanisms that may not adhere to industry best practices.
- Lack of Standard Framework Implementation: Instead of leveraging proven and tested frameworks or modules, the system relies on in-house solutions that might lack robustness.
Example
Peter discovers that a bespoke website uses a custom session management system developed in-house. This system, while functional, does not incorporate the latest security practices and is vulnerable to session hijacking and fixation attacks. Capitalizing on these weaknesses, Peter manipulates session tokens to gain unauthorized access to user accounts, bypassing the inadequate session control mechanisms.
Threat Modeling
STRIDE
This scenario maps primarily to STRIDE: Spoofing.
Spoofing is about impersonating a legitimate user or entity. Peter exploits weaknesses in a self-built or weak session management system, allowing him to bypass session controls and assume the identity of legitimate users. The attack is centered on unauthorized impersonation via inadequate session enforcement, making Spoofing the correct primary category.
What can go wrong?
Custom-built session management systems that lack the rigor of standard frameworks can lead to serious security breaches, including unauthorized access and data theft.
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?
Centralized session management routines are a good programming practice, but like other routines, developers need to understand how they work, how to use them and any limitations. These should preferably be the framework's in-built session management support. If third party session management libraries are used, it is important to test each routine before its implementation.
- Where possible, replace self-built session management systems with standard, well-tested frameworks or modules known for robust security.
- If a custom solution is necessary, ensure it is developed according to industry best practices and undergoes rigorous security testing.
- Regularly review and update the session management system to incorporate the latest security advancements and patches.
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
STRIDE: Spoofing
OWASP ASVS: 4.4.3,7.2.1,7.2.2,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,13.2.1,16.3.3,16.3.4
CAPEC™ Map
| Code | Title | ASVS |
|---|---|---|
| 21 | Exploitation of Trusted Identifiers | 4.4.3,7.2.1,7.2.2,13.2.1,16.3.3,16.3.4 |
| 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,13.2.1,16.3.3,16.3.4 |
