Cross-Site Request Forgery (CSRF) in hMailServer

Overview

Cross-site request forgery in the REST API of Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a remote attacker to make an authenticated user's browser perform a state-changing request. The REST API accepts HTTP Basic authentication and answers a browser with a Basic sign-in box; a browser caches the credential once the box is answered and sends it with later requests to that origin, including a top-level form post from another site, and the server reads a request body whatever its declared content type. The cross-site protection covered only the cookie session (a header a cross-site form cannot set, and a SameSite=Strict cookie); HTTP Basic was not held to it. A page under an attacker's control, visited by a user whose browser holds a cached Basic credential for the REST API - typically an administrator who signed in through the box - could therefore cause a state-changing request such as creating a domain, an account or an API key, or changing a setting, with the victim's credential. The attacker cannot read the cross-origin response, so the forgery is blind.

Affected

• hMailServer >= 6.0.0 <= 6.3.6

Remediation

Upgrade to hMailServer 6.3.7, which refuses a credentialed state-changing REST request a browser reports as cross-site (by Sec-Fetch-Site, or an Origin whose host is not the server's own), covering HTTP Basic and bearer credentials as the cookie session was already covered. Until then, reach the REST API and the Deck from a dedicated browser or profile closed after use so no cached Basic credential is present while browsing other sites; keep the REST API off (RestApiPort=0, the default) or bound to the loopback where it is not needed; and prefer an API key (a Bearer token a cross-site page cannot set) over the Basic box for automated clients. An upgrade does not undo a request already forged: review API keys, accounts, domains and settings for changes nobody made, and revoke any key nobody issued.