ghsa-g65h-35f3-x2w3
Vulnerability from github
Summary
Currently session tokens function like the other JWT tokens where they are not actually invalidated when logging out. The directus_session gets destroyed and the cookie gets deleted but if you captured the cookie value it will still work for the entire expiry time which is set to 1 day by default. Making it effectively a long lived unrevokable stateless token instead of the stateful session token it was meant to be.
When authenticating a session token JWT, Directus should also check whether the associated directus_session both still exists and has not expired (although the token should expire at the same time or before the session) to ensure leaked tokens are not valid indefinitely.
Steps to reproduce
- Copy the current session token from the cookie
- Refresh and or log out
- Use the saved session token to check if it is still valid
Impact
The lack of proper session expiration may improve the likely success of certain attacks. For example, a user might access a web site from a shared computer (such as at a library, Internet cafe, or open work environment). Incorrect token invalidation could allow an attacker to use the browser's history to access a Directus instance session previously accessed by the victim.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "directus"
},
"ranges": [
{
"events": [
{
"introduced": "10.10.0"
},
{
"fixed": "10.11.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-34709"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-13T19:59:39Z",
"nvd_published_at": "2024-05-14T15:39:31Z",
"severity": "MODERATE"
},
"details": "### Summary\nCurrently session tokens function like the other JWT tokens where they are not actually invalidated when logging out. The `directus_session` gets destroyed and the cookie gets deleted but if you captured the cookie value it will still work for the entire expiry time which is set to 1 day by default. Making it effectively a long lived unrevokable stateless token instead of the stateful session token it was meant to be.\nWhen authenticating a session token JWT, Directus should also check whether the associated `directus_session` both still exists and has not expired (although the token should expire at the same time or before the session) to ensure leaked tokens are not valid indefinitely.\n\n## Steps to reproduce\n- Copy the current session token from the cookie\n- Refresh and or log out\n- Use the saved session token to check if it is still valid\n\n### Impact\nThe lack of proper session expiration may improve the likely success of certain attacks. For example, a user might access a web site from a shared computer (such as at a library, Internet cafe, or open work environment). Incorrect token invalidation could allow an attacker to use the browser\u0027s history to access a Directus instance session previously accessed by the victim.",
"id": "GHSA-g65h-35f3-x2w3",
"modified": "2024-05-14T20:04:30Z",
"published": "2024-05-13T19:59:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/directus/directus/security/advisories/GHSA-g65h-35f3-x2w3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34709"
},
{
"type": "WEB",
"url": "https://github.com/directus/directus/commit/a6172f8a6a0f31a6bf4305a090de172ebfb63bcf"
},
{
"type": "PACKAGE",
"url": "https://github.com/directus/directus"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Directus Lacks Session Tokens Invalidation"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.