Package Instance

Duplicate
This advisory duplicates another.

Session Token in URL in directus
### Impact

When reaching the /files page, a JWT is passed via GET request. Inclusion of session tokens in URLs poses a security risk as URLs are often logged in various places (e.g., web server logs, browser history). Attackers gaining access to these logs may hijack active user sessions, leading to unauthorized access to sensitive information or actions on behalf of the user.

### Patches

_Has the problem been patched? What versions should users upgrade to?_

### Workarounds

There's no workaround available.

### References

_Are there any links users can visit to find out more?_

URL Redirection to Untrusted Site in OAuth2/OpenID in directus
### Summary
The authentication API has a `redirect` parameter that can be exploited as an open redirect vulnerability as the user tries to log in via the API URL https://docs.directus.io/reference/authentication.html#login-using-sso-providers /auth/login/google?redirect for example.

### Details
There's a redirect that is done after successful login via the Auth API GET request to `directus/auth/login/google?redirect=http://malicious-fishing-site.com`, which I think is here: https://github.com/directus/directus/blob/main/api/src/auth/drivers/oauth2.ts#L394. While credentials don't seem to be passed to the attacker site, the user can be phished into clicking a legitimate directus site and be taken to a malicious site made to look like a an error message "Your password needs to be updated" to phish out the current password.

### PoC
Turn on any auth provider in Directus instance. Form a link to `directus-instance/auth/login/:provider_id?redirect=http://malicious-fishing-site.com`, login and get taken to malicious-site. Tested on the `ory` OAuth2 integration.

### Impact
Users who login via OAuth2 into Directus.

Directus version number disclosure
### Impact

Currently the exact Directus version number is being shipped in compiled JS bundles which are accessible without authentication. With this information a malicious attacker can trivially look for known vulnerabilities in Directus core or any of its shipped dependencies in that specific running version.

### Patches

The problem has been resolved in versions 10.8.3 and newer

### Workarounds

None

Exposure of Sensitive Information to an Unauthorized Actor
Directus is a real-time API and App dashboard for managing SQL database content. In versions prior to 9.16.0 users with read access to the `password` field in `directus_users` can extract the argon2 password hashes by brute forcing the export functionality combined with a `_starts_with` filter. This allows the user to enumerate the password hashes. Accounts cannot be taken over unless the hashes can be reversed which is unlikely with current hardware. This problem has been patched by preventing any hashed/concealed field to be filtered against with the `_starts_with` or other string operator in version 9.16.0. Users are advised to upgrade. Users unable to upgrade may mitigate this issue by ensuring that no user has `read` access to the `password` field in `directus_users`.

Insertion of Sensitive Information into Log File
Directus is a real-time API and App dashboard for managing SQL database content. Prior to version 9.23.3, the `directus_refresh_token` is not redacted properly from the log outputs and can be used to impersonate users without their permission. This issue is patched in version 9.23.3.

Directus has MySQL accent insensitive email matching
## Password reset vulnerable to accent confusion

The password reset mechanism of the Directus backend is implemented in a way where combined with (specific, need to double check if i can work around) configuration in MySQL or MariaDB. As such, it allows attackers to receive a password reset email of a victim user, specifically having it arrive at a similar email address as the victim with a one or more characters changed to use accents. 

This is due to the fact that by default MySQL/MariaDB are configured for accent-insenstive and case-insensitve comparisons.

MySQL weak comparison:
```sql
select 1 from directus_users where 'julian@cure53.de' = 'julian@cüre53.de';
```

This is exploitable due to an error in the API using the supplied email address for sending the reset password mail instead of using the email from the database.

### Steps to reproduce:

1. If the attacker knows the email address of the victim user, i.e., `julian@cure53.de`. (possibly just the domain could be enough for an educated guess)
2. A off-by-one accented domain `cüre53.de` can be registered to be able to receive emails.
3. With this email the attacker can request a password reset for `julian@cüre53.de`. 
```http
POST /auth/password/request HTTP/1.1
Host: example.com
[...]
{"email":"julian@cüre53.de"}
```
4. The supplied email (julian@cüre53.de) gets checked against the database and will match the non-accented email `julian@cure53.de` and will continue to email the password reset link to the provided email address instead of the saved email address.
5. With this email the attacker can log into the target account and use it for nefarious things

### Workarounds
Should be possible with collations but haven't been able to confirm this. 

### References
- https://www.monolune.com/articles/what-is-the-utf8mb4_0900_ai_ci-collation/
- https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-sets.html

Directus affected by VM2 sandbox escape vulnerability
### Impact
In vm2 for versions up to 3.9.19, Promise handler sanitization can be bypassed, allowing attackers to escape the sandbox and run arbitrary code. Within Directus this applies to the "Run Script" operation in flows being able to escape the sandbox running code in the main nodejs context.

### Patches
Patched in v10.6.0 by replacing `vm2` with `isolated-vm`

### Workarounds
None

### References
https://github.com/patriksimek/vm2/security/advisories/GHSA-cchq-frgv-rjh5