websea II

The Android application includes a hardcoded encryption key within the source code. This key is used to encrypt and decrypt sensitive data stored locally on the device. Embedding cryptographic keys directly into the application makes them easily retrievable by anyone with access to the APK, such as through reverse engineering or decompilation.

The Android application is designed to create a cryptographic key from the Keystore. However, the Keystore entries currently lack sufficient protection, as several security flags are not enabled: - `isTrustedUserPresenceRequired` - `isUserAuthenticationRequired` - `isUserAuthenticationRequirementEnforcedBySecureHardware` - `isUserConfirmationRequired` These flags are intended to ensure that the Keystore entries are protected against unauthorized access.

The application does not implement certificate pinning. Certificate pinning is the act of associating a host with its expected certificate within the application. When the application connects to the host, the stored certificate is compared to the certificate held by the remote host. If the two certificates do not match, the request is dropped. Currently, the application only verifies that the server presents a TLS certificate that is trusted by the Android or iOS trust stores, not validating that the TLS certificate is in fact the one known to be deployed on the servers.

The session cookies `EXUU` and `sharedToken` are not properly protected by the "HTTPOnly" and "SameSite" attributes.

The mobile applications store the session token in memory during the user session but fail to clear it upon logout. As a result, even after a successful logout, the session token remains accessible in the app's memory until the application is terminated or the memory is cleared by the system. If the device is lost, compromised, or transferred to another user, an attacker could potentially retrieve the session token and use it to re-authenticate or access protected resources without user consent.

The application is hosted behind Cloudflare, which by default adheres to the `Cache‑Control: max‑age=14400` header and will cache JSON responses for a duration of up to four hours. The endpoint `/webApi/user/detail` typically requires a valid `Token` header and returns user‑specific data in JSON format. However, because Cloudflare treats any URL ending in a common static‑file extension (for example, `.css`) as cacheable, appending a fake extension to the dynamic endpoint causes that sensitive JSON to be stored in the CDN cache. When a legitimate and authenticated user requests `/webApi/user/detail;asd.css`, Cloudflare fails to distinguish it from a benign CSS file request and consequently caches the entire JSON payload. Subsequently, an attacker can exploit this vulnerability by requesting the same URL without any credentials, thereby directly accessing the victim’s private data from Cloudflare’s cache. _The vulnerability was categorized as Informational risk because the session token is transmitted via the HTTP `Token` header. Therefore, even if the user accesses a malicious URL, the session token will not be sent, and sensitive user data will not be cached. However, it is recommended to address this issue to mitigate potential exploitation in future modifications to the application or in conjunction with other vulnerabilities._