@blamejs/core 0.15.59 → 0.15.60

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.15.x
 
+- v0.15.60 (2026-06-29) — **`requireStepUp` binds the elevation grant to the authenticated principal, refusing a grant minted for a different user (cross-user step-up replay).** The b.middleware.requireStepUp gate accepts an operator-issued step-up elevation grant from the X-Step-Up-Grant header and verifies it with b.auth.stepUp.grant.verify. An elevation grant carries the subject it was minted for (payload.sub), but the middleware verified only the grant's signature, expiry, and scope — never that the grant's subject matched the request's authenticated principal. A grant minted for one user (and then leaked through a shared cache, a log line, a referrer, or a shared device) therefore satisfied the step-up requirement for ANY other authenticated user who presented it, elevating their session to the granted assurance level without ever completing a step-up ceremony. requireStepUp now passes the resolved principal as the grant's required subject, so the grant satisfies step-up only for the user it was issued to. The principal is resolved from whichever shape the authenticator populated — a session's req.user.id / req.user.userId, or the JWT subject (req.user.claims.sub / req.user.sub) set by bearerAuth with an external verifier — so a grant legitimately minted for a JWT subject still binds. A request with no resolvable principal cannot bind the grant and falls through to the claims-based challenge. **Security:** *Step-up elevation grants are bound to the authenticated principal* — requireStepUp's grant path called b.auth.stepUp.grant.verify with only the grant scope, not the subject, so any holder of a valid, unexpired, scope-matching elevation grant passed the step-up gate regardless of which user the request was authenticated as — a leaked or shared grant elevated a different user's session (cross-user step-up replay). The grant already binds a subject at mint time and the verifier supports a subject check; the middleware now supplies the request's principal as the required subject, refusing a grant whose subject does not match. The principal is read from whichever field the authenticator set — a session's id/userId or the JWT subject (claims.sub / sub) from bearerAuth's external verifier — so a grant minted for any of those binds correctly. A request with no authenticated principal cannot bind a grant and is handled by the normal claims-based step-up challenge. The grant verifier's signature/expiry/scope/jti-revocation checks are unchanged.
+
 - v0.15.59 (2026-06-29) — **OCSP response validation binds the response to the certificate's issuer (issuerNameHash + issuerKeyHash), not the serial number alone, refusing a wrong-issuer "good".** An OCSP SingleResponse identifies the certificate it covers by a CertID of (hashAlgorithm, issuerNameHash, issuerKeyHash, serialNumber) — RFC 6960 §4.1.1. b.network.tls.ocsp.evaluate matched a response to the certificate under validation by the serial number alone and never compared the CertID's issuer hashes. Because a serial number is unique only within one issuer, a responder key that serves more than one issuer identity — a delegated OCSP responder, or a CA key spanning issuers — could have a signed "good" response for serial-S under issuer-Y accepted as proof for the serial-S certificate under issuer-X. The evaluator now recomputes the expected issuerNameHash and issuerKeyHash from the issuer certificate and refuses a response whose CertID issuer hashes do not match. b.network.tls.ocsp.fetch supplies the issuer certificate automatically (its issuerPem is the leaf's issuer); ocsp.requireGood and direct ocsp.evaluate callers pass the issuer cert explicitly as the new issuerCertDer (requireGood's issuerPem may be a delegated OCSP responder rather than the issuer, so it is not used as the issuer), and a response with no issuer certificate available stays bound on serial plus signature as before. **Security:** *OCSP evaluate binds the response CertID to the issuer, not the serial alone (RFC 6960 §4.1.1)* — b.network.tls.ocsp.evaluate selected the matching SingleResponse by normalized serial number only, ignoring the CertID's issuerNameHash and issuerKeyHash. Since serials are unique only per issuer, a "good" response signed by a key that also serves a different issuer (a delegated id-kp-OCSPSigning responder, or a shared CA key) could be replayed as proof for a same-serial certificate under another issuer. evaluate now recomputes the expected issuerNameHash = Hash(issuer DN) and issuerKeyHash = Hash(issuer public key) under the CertID's own hash algorithm and refuses the response if either differs ("wrong-issuer response"). b.network.tls.ocsp.fetch forwards the issuer certificate automatically (its issuerPem is the leaf's issuer); ocsp.requireGood and a direct ocsp.evaluate caller enable the binding by passing issuerCertDer (the issuer cert DER) — requireGood's issuerPem may be a delegated OCSP responder, so the issuer cert is taken explicitly rather than derived from it — and a call without an issuer certificate retains the prior serial-plus-signature binding.
 
 - v0.15.58 (2026-06-29) — **File-upload content-safety scanning now also runs the gate for a file's magic-byte-detected type, so a mislabeled file can't dodge the scanner for its real type by choosing the extension.** b.fileUpload selected the per-extension content-safety gate purely from the upload's filename extension, which the uploader controls. A file whose magic bytes identify one type but whose name carries another extension (e.g. a PDF named photo.png) was therefore scanned by the gate for the named extension — or, when no gate was registered for that extension, not scanned at all — so an uploader could dodge the scanner configured for the file's real type by renaming it. When a fileType detector is wired, finalize now also runs the content-safety gate for the type the magic bytes identify, in addition to the filename-extension gate, so the scanner for the real type runs even under a mismatched name. Magic-byte-less text formats (HTML, SVG, CSV) cannot be classified this way; that residual is covered by serving uploads with an explicit Content-Type plus X-Content-Type-Options: nosniff and by registering a content-safety gate for every accepted extension. **Security:** *Content-safety gate selection follows the sniffed type, not just the filename extension* — finalize chose the content-safety gate from nodePath.extname(filename), so a file's real type could be hidden behind a chosen extension: a PDF named photo.png ran the .png gate (or, with no .png gate, skipped scanning) and never reached the .pdf scanner. When opts.fileType is wired, finalize now detects the magic-byte type and, if it differs from the filename extension and a gate is registered for it, runs that gate too (alongside the filename-extension gate), refusing or sanitizing per the gate's decision. Existing behavior is unchanged when no fileType detector is wired or the detected type matches the extension. Formats without magic bytes (HTML/SVG/CSV/plain text) remain undetectable by content sniffing — defend those by serving stored files with a fixed Content-Type and X-Content-Type-Options: nosniff, and by registering a content-safety gate for each accepted extension.

package/lib/middleware/require-step-up.js

@@ -64,6 +64,30 @@ function _defaultGetClaims(req) {
   return null;
 }
 
+// Resolve the authenticated principal an elevation grant must be bound to.
+// The principal subject lives under different keys depending on the
+// authenticator: a session populates req.user.id / req.user.userId, while
+// bearerAuth with an external JWT verifier (auth.jwt.verifyExternal)
+// populates req.user.claims.sub (or a flattened req.user.sub) — the same
+// shapes _defaultGetClaims reads. Resolving all of them keeps a grant
+// legitimately minted for a claims.sub principal from being silently
+// dropped to a 401. Returns undefined when no principal is resolvable, in
+// which case the caller refuses the grant path (fail-closed: an unbound or
+// mismatched subject can only narrow what a grant satisfies, never widen).
+function _resolveStepUpPrincipal(req) {
+  if (!req || typeof req !== "object" || !req.user || typeof req.user !== "object") {
+    return undefined;
+  }
+  var u = req.user;
+  if (u.id != null)     return u.id;
+  if (u.userId != null) return u.userId;
+  if (u.claims && typeof u.claims === "object" && u.claims.sub != null) {
+    return u.claims.sub;
+  }
+  if (u.sub != null)    return u.sub;
+  return undefined;
+}
+
 function _writeChallenge(res, challenge, body, statusCode) {
   if (res.headersSent) return;
   var json = JSON.stringify(body);
@@ -159,7 +183,22 @@ function create(opts) {
       if (typeof grantToken === "string" && grantToken.length > 0) {
         var verifyOpts = {};
         if (grantScope) verifyOpts.scope = grantScope;
-        var grantResult = elevation().verify(grantToken, verifyOpts);
+        // Bind the grant to the authenticated principal: an elevation grant
+        // carries its subject (payload.sub) and must only satisfy step-up for
+        // THAT subject. Without this, a grant minted for one user (leaked via a
+        // shared cache / log / kiosk) elevates ANY other authenticated user's
+        // session — a cross-user step-up replay. When no principal is resolvable
+        // the grant cannot be bound, so the grant path is refused (the request
+        // falls through to the claims-based path / 401 challenge).
+        var stepUpPrincipal = _resolveStepUpPrincipal(req);
+        var grantResult;
+        if (stepUpPrincipal == null) {
+          grantResult = { ok: false, error: "no_principal",
+                          reason: "step-up grant requires an authenticated principal to bind to" };
+        } else {
+          verifyOpts.subject = stepUpPrincipal;
+          grantResult = elevation().verify(grantToken, verifyOpts);
+        }
         if (grantResult.ok) {
           if (auditOn) {
             try {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/core",
-  "version": "0.15.59",
+  "version": "0.15.60",
   "description": "The Node framework that owns its stack.",
   "license": "Apache-2.0",
   "author": "blamejs contributors",

package/sbom.cdx.json

@@ -2,10 +2,10 @@
   "$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
   "bomFormat": "CycloneDX",
   "specVersion": "1.5",
-  "serialNumber": "urn:uuid:81180df0-93d0-4b26-b1a8-ac46819c5783",
+  "serialNumber": "urn:uuid:9f023375-6f18-4c24-a12a-74b1fc204f53",
   "version": 1,
   "metadata": {
-    "timestamp": "2026-06-29T14:03:52.612Z",
+    "timestamp": "2026-06-29T15:45:36.020Z",
     "lifecycles": [
       {
         "phase": "build"
@@ -19,14 +19,14 @@
       }
     ],
     "component": {
-      "bom-ref": "@blamejs/core@0.15.59",
+      "bom-ref": "@blamejs/core@0.15.60",
       "type": "application",
       "name": "blamejs",
-      "version": "0.15.59",
+      "version": "0.15.60",
       "scope": "required",
       "author": "blamejs contributors",
       "description": "The Node framework that owns its stack.",
-      "purl": "pkg:npm/%40blamejs/core@0.15.59",
+      "purl": "pkg:npm/%40blamejs/core@0.15.60",
       "properties": [],
       "externalReferences": [
         {
@@ -54,7 +54,7 @@
   "components": [],
   "dependencies": [
     {
-      "ref": "@blamejs/core@0.15.59",
+      "ref": "@blamejs/core@0.15.60",
       "dependsOn": []
     }
   ]