99 lines
3.1 KiB
Plaintext
99 lines
3.1 KiB
Plaintext
|
== Analysis
|
||
|
|
|
||
|
|
For the analysis section, the project will be evaluated under the scope of the V3 (Session Management) chapter of the OWASP ASVS, using version v4.0.3. This will include an assessment of the session management mechanisms implemented, as well as any vulnerabilities identified and possible mitigations.
|
||
|
|
|
||
|
|
=== Session Management
|
||
|
|
|
||
|
|
==== Fundamental Session Management Security
|
||
|
|
|
||
|
|
[cols="^1,10,^1,^1", options="header", source]
|
||
|
|
|===
|
||
|
|
| Requirement | Description | Applicable | Implemented
|
||
|
|
|
||
|
|
| 3.1.1
|
||
|
|
| Verify the application never reveals session tokens in URL parameters.
|
||
|
|
| ✔
|
||
|
|
| ✔
|
||
|
|
|
||
|
|
|===
|
||
|
|
|
||
|
|
===== 3.1.1
|
||
|
|
|
||
|
|
The current implementation meets the requirement, as the session tokens are not exposed in the URL parameters but instead are sent in the Authorization header.
|
||
|
|
|
||
|
|
==== Session Binding
|
||
|
|
|
||
|
|
[cols="^1,10,^1,^1", options="header", source]
|
||
|
|
|===
|
||
|
|
| Requirement | Description | Applicable | Implemented
|
||
|
|
|
||
|
|
| 3.2.1
|
||
|
|
| Verify the application generates a new session token on user authentication.
|
||
|
|
| ✔
|
||
|
|
| ✔
|
||
|
|
|
||
|
|
| 3.2.2
|
||
|
|
| Verify that session tokens possess at least 64 bits of entropy.
|
||
|
|
| ✔
|
||
|
|
| ✔
|
||
|
|
|
||
|
|
| 3.2.3
|
||
|
|
| Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3.4) or HTML 5 session storage.
|
||
|
|
| ✗
|
||
|
|
| ✗
|
||
|
|
|
||
|
|
| 3.2.4
|
||
|
|
| Verify that session tokens are generated using approved cryptographic algorithms.
|
||
|
|
| ✔
|
||
|
|
| ✔
|
||
|
|
|===
|
||
|
|
|
||
|
|
===== 3.2.1, 3.2.2, 3.2.4
|
||
|
|
|
||
|
|
The application generates a new session token on session creation when a user logs in.
|
||
|
|
|
||
|
|
This token is generated using the `secrets.token_hex(128)`
|
||
|
|
function, which generates a 256-character hexadecimal string, providing more than 64 bits of entropy. This function has been certified as secure by OWASP in their https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#secure-random-number-generation[cheat sheet series].
|
||
|
|
|
||
|
|
This generation is implemented in the code as follows:
|
||
|
|
|
||
|
|
[source,python]
|
||
|
|
----
|
||
|
|
include::create_session.py[]
|
||
|
|
----
|
||
|
|
|
||
|
|
==== Session Termination
|
||
|
|
|
||
|
|
[cols="^1,10,^1,^1", options="header", source]
|
||
|
|
|===
|
||
|
|
| Requirement | Description | Applicable | Implemented
|
||
|
|
|
||
|
|
| 3.3.1
|
||
|
|
| Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties.
|
||
|
|
| ✔
|
||
|
|
| ✔
|
||
|
|
|
||
|
|
| 3.3.2
|
||
|
|
| If authenticators permit users to remain logged in, verify that re-authentication occurs periodically both when actively used or after an idle period.
|
||
|
|
| ✔
|
||
|
|
| ✗
|
||
|
|
|
||
|
|
| 3.3.3
|
||
|
|
| Verify that the application gives the option to terminate all other active sessions after a successful password change (including change via password reset/recovery), and that this is effective across the application, federated login (if present), and any relying parties.
|
||
|
|
| ✗
|
||
|
|
| ✗
|
||
|
|
|
||
|
|
| 3.3.4
|
||
|
|
| Verify that users are able to view and (having re-entered login credentials) log out of any or all currently active sessions and devices.
|
||
|
|
| ✔
|
||
|
|
| ✔
|
||
|
|
|===
|
||
|
|
|
||
|
|
==== Cookie-based Session Management
|
||
|
|
|
||
|
|
==== Token-based Session Management
|
||
|
|
|
||
|
|
==== Federated Re-authentication
|
||
|
|
|
||
|
|
==== Defenses Against Session Management Exploits
|