fix(ssh-ca): refuse cross-site POSTs on /ssh/sign, /ssh/myrevoke, /ssh/revoke

[guimard]

Closes #62. Stacked on #88 → #87; merge those first.

The hole

The three POST routes parsed their body with from_json( $req->content ),
bypassing Common/PSGI/Request.pm's jsonBodyToObj and therefore its
Content-Type: application/json requirement. An HTML form can only send
application/x-www-form-urlencoded, multipart/form-data or text/plain, and
a text/plain body containing JSON parsed cleanly — so a cross-site form POST
was accepted. There is no CSRF token for plugin REST routes in the core.

Reachable only where the SSO cookie is SameSite=None, which LLNG sets when
issuerDBSAMLActivation or samlIDPMetaDataXML is set. No shipped
open-bastion configuration does, so as delivered this was not exploitable.

What it was worth to an attacker

Not the certificate: it is returned only in a response body a cross-origin page
cannot read (Access-Control-Allow-Origin is emitted only for the portal's own
origin), and it is never persisted — only serial, key_id, label, fingerprint,
principals and dates are.

The residual is a forced state change: re-signing a victim's publicly known
public key supersedes their live certificate and KRL-revokes the old serial,
locking them out of SSH across the fleet. A forced /ssh/myrevoke is the same
shape in one step.

The fix

One helper, _jsonBodyOrReject, used by all three routes:

1. Origin present and not the portal's own → 403, audited as
   SSH_CA_CROSS_ORIGIN_REFUSED. Browsers attach Origin to every
   cross-origin POST; non-browser callers (the ssh-ca CLI, curl, ob-*
   tooling) send none and are unaffected.
2. Body through $req->jsonBodyToObj, so Content-Type: application/json is
   required → 400 otherwise.

Compatibility

Any caller already sending Content-Type: application/json — which is what the
plugin has always documented, and what the shipped /ssh page and the CLI do —
is unaffected. A caller posting JSON under another content type now gets 400.

Tests

ssh-ca 570 assertions, green. New coverage in t/01: text/plain and
urlencoded bodies refused on /ssh/sign and /ssh/myrevoke, a foreign
Origin refused, and the portal's own Origin still served.

https://claude.ai/code/session_01GfBG36HfzjGy8W9rJQbxBL

[guimard]

Reviewed against the core: _isSelfOrigin matches _checkSelfCors (Portal/Main/Run.pm:1491 — scheme + host_port), jsonBodyToObj enforces the content type (Common/PSGI/Request.pm:104), and the sticky error setter makes the delete $req->{error} necessary (Request.pm:75).

One nit: /ssh/revoke isn't exercised by the new tests (the helper is shared, so the risk is low) — a two-line test would pin it.

[guimard]

Added: 02-SSHCA-admin.t PART 7b pins /ssh/revoke (commit 4f15f1f). It had to go there rather than in 01-SSHCA-mycerts.t — the route is behind sshCaAdminRule, so the refusals only prove something about the CSRF gate when the caller is the administrator, which is what that portal gives us (rtyler).

Three cases: form content type → 400, foreign Origin → 403 Cross-origin request refused, portal Origin → passes the gate and reaches the handler (404 on the deliberately unknown session).

https://claude.ai/code/session_01GfBG36HfzjGy8W9rJQbxBL