Mail (webmail): a look at the security model, a few small suggestions

[imc67]

Hi @nebulon , I've been using the new Mail app on one of our Cloudrons for a few weeks and it has quickly become my daily driver: sign in once with Cloudron and every mailbox I have access to is right there. Before rolling it out to more users I read through the code that runs in the container (1.1.1) with security in mind. Short version: it's very nicely done. A few notes and small suggestions below.

What I really like

• No master credential. The app has no password for the mail server at all: it uses the user's own OIDC token with a dedicated mailclient scope as the IMAP/SMTP/Sieve password, and the mail server checks per mailbox whether that token may access it. Even a bug in the app can't open a mailbox the user has no rights to. That is a better model than classic webmail, where the user types their mail password into the web app.
• Login through Cloudron OIDC with PKCE and state, so Cloudron's 2FA applies automatically and nobody ever types a mail password into the webmail.
• Mail HTML is rendered in a sandboxed iframe without allow-scripts, and the frame document gets its own CSP with script-src 'none'. Two locks, either one is enough.
• Remote images and other external content are blocked by default, with a per-sender/per-domain allowlist. Great for tracking pixels.
• Session cookie is HttpOnly and SameSite=Lax, and HSTS is on.

Small suggestions

1. Tokens in the session store end up in backups. Sessions are kept by tegel's file store in /app/data/.session.store, and each session file holds the access token, the refresh token (offline_access) and the mailclient token in plain text, valid for 14 rolling days. Since /app/data is backed up, anyone with access to a backup (unencrypted backups are not unusual) could use those tokens until they expire or are revoked. Sessions are disposable, so the simplest fix might be to keep the session store outside the backup (e.g. /run or a path excluded from backup) — after a restore users just sign in again. Encrypting the tokens at rest would also work.
2. The session cookie has no Secure flag. tegel sets secure: process.env.NODE_ENV === 'production', and NODE_ENV is not set in the container. HSTS covers most of it, but setting NODE_ENV=production (together with trust proxy, since TLS ends at nginx) would close it.
3. No CSP or frame protection on the app itself. The message frame has a strict CSP, but the main page sends no Content-Security-Policy and no X-Frame-Options/frame-ancestors, so the webmail can be framed by another site (clickjacking). A frame-ancestors 'self' would already help, and the app looks like it could live with a fairly strict CSP.
4. Minor, defence in depth: sanitizeHtml() in MessageView only strips external content; scripts and event handlers stay in the HTML and are neutralised by the sandbox + CSP. That is fine as long as those stay in place; a DOMPurify pass would be a third lock if the frame setup ever changes.

A question about 1.2.0

1.2.0 mentions "token exchange authentication" and needs Cloudron 10.1.1, so I can't try it yet. Does it change what is kept in the session (e.g. no refresh token any more, or a short-lived exchanged token only)? If so, point 1 may already be (partly) solved.

Thanks for building this, it's a really pleasant client to use already.

[nebulon]

Thanks for all the points! The next version has secure cookies set when deployed, as well as setting frame-ancestores: none by default (tegel change so our other apps also benefit from this).

Regarding the tokens, the mailbox listing and mail password via the mailclient scope got removed and the mail server now uses tokens whicih the mail app can get for a user via the cloudron app bridge (hence the new cloudron version requirement). This means nothing mail related ends up in the session store and the oidc related parts there are only for the login bits of the webui.

For the last part about HTML sanitizing, we will have to do some more work on mail rendering and will look into that then.