📄 Bichon 1.0.2 Bearer Access Token Disclosure

Bichon 1.0.2 Bearer Access Token Accepted via Query String + Logged
    ===================================================================
    
    Vendor:        rustmailer
    Product:       Bichon - self-hosted email archiving server (Rust + TypeScript)
    Project URL:   https://github.com/rustmailer/bichon
    Affected:      All versions through HEAD as of 2026-05-18
                   Commit:  9daab241b0220e81e43d4b98616d77fa45ad58c7
                   Release: 1.0.2
    Patched:       Pending vendor fix
    Severity:      Medium
    CVSS 3.1:      6.5  (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N)
    CWE:           CWE-598 (Use of GET Request Method With Sensitive
                            Query Strings)
                   CWE-532 (Insertion of Sensitive Information into
                            Log File)
                   CWE-522 (Insufficiently Protected Credentials)
    CVE:           Pending (requested via GitHub CNA)
    Discovered:    2026-05-18 (manual source review + live verification)
    Researcher:    AoxLir  <[email protected]>
    Disclosure:    Coordinated (Project Zero 90-day standard)
    
    
    I. Background
    =============
    
    Bichon's REST API uses opaque Bearer access tokens (issued by the
    /api/login endpoint or the /api/v1/access-token endpoint) for
    authorization on /api/v1/* paths.  The standard delivery mechanism is
    the Authorization: Bearer header.
    
    
    II. Vulnerability Detail
    ========================
    
    In crates/server/src/common/auth.rs lines 97-106
    (extract_client_context):
    
        let bearer = req
            .headers()
            .typed_get::<Authorization<Bearer>>()
            .map(|auth| auth.0.token().to_string())
            .or_else(|| req.params::<Param>()
                           .ok()
                           .map(|param| param.access_token));
        /*  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            Fallback: token read from the URL query string */
    
        let token = bearer.ok_or_else(|| {
            create_api_error_response("Valid access token not found",
                                      ErrorCode::PermissionDenied)
        })?;
    
    Where Param is:
    
        #[derive(Deserialize)]
        struct Param {
            access_token: String,
        }
    
    This is explicitly discouraged by RFC 6750 (sections 2.3 and 5.3) due
    to leakage via access logs, browser history, Referer headers, and
    shared screenshots.
    
    Live testing additionally confirmed that Bichon's own logger
    (bichon_server::common::log) writes the full token to stdout on every
    request - meaning that running `docker logs bichon` (which any
    container operator has access to) exposes valid bearer tokens of all
    users.
    
    
    III. Proof of Concept
    =====================
    
    Verified live against rustmailer/bichon:1.0.2 (Docker).
    
    Step 1: Make an authenticated API call using ONLY the query string
            (no Authorization header):
    
      $ curl -i \
          'http://localhost:15630/api/v1/current-user?access_token=mFa5HSBUHDjG5vTDqBYAADXH'
    
      HTTP/1.1 200 OK
      content-type: application/json; charset=utf-8
      ...
    
      {"username":"bob","email":"[email protected]", ...}
    
      The query-string fallback fully replaces the header.
    
    Step 2: Inspect Bichon's own application log:
    
      $ docker logs bichon-poc 2>&1 | grep current-user | tail -2
      2026-05-18T12:01:53.748+00:00  INFO  request{remote_addr=172.17.0.1
          method=GET path=/api/v1/current-user
          query=Some("access_token=mFa5HSBUHDjG5vTDqBYAADXH")
          referer=None content_length=None}:
          request completed successfully status=200 duration=53.351us
    
      The token is written verbatim to stdout by the application itself.
      No reverse proxy, CDN, or browser is needed to leak it.
    
    
    IV. Impact
    ==========
    
      * Any operator with `docker logs` / `journalctl -u bichon` access
        immediately obtains every active bearer token.  Bichon
        deployments commonly include a non-Bichon operator (DevOps, SRE,
        log aggregator service account).  Such operator can impersonate
        any user, including admin, until the token is revoked or expires.
    
      * Log shippers (Datadog, CloudWatch, Splunk, ELK, Loki, Promtail)
        forward the raw stdout - tokens land in third-party log
        repositories where retention, ACLs, and indexing may not be
        aligned with the trust model of Bichon's user data.
    
      * The legacy URL-leakage paths (nginx access log, browser history,
        Referer to third parties) remain valid additional vectors.
    
    
    V. Solution
    ===========
    
    Two changes are recommended:
    
    1. Remove the URL-query fallback in extract_client_context():
    
           let bearer = req
               .headers()
               .typed_get::<Authorization<Bearer>>()
               .map(|auth| auth.0.token().to_string());
           /* drop .or_else(...) */
    
       If a separate code path genuinely needs a download-friendly token
       in the URL (e.g. signed share links), implement a separate
       short-lived, single-use download-token mechanism with its own scope.
    
    2. Redact sensitive query parameters in the request-log middleware:
    
       In bichon_server::common::log, before emitting the `query` field,
       sanitize any `access_token`, `token`, `api_key`, or `password`
       parameter to a placeholder such as "[REDACTED]".
    
    VI. Credit
    ===========
    
    Discovered and reported by MrOruc, independent security researcher.
    GitHub: https://github.com/MrOruc
    Email:  [email protected]