@blamejs/core 0.15.58 → 0.15.60

package/CHANGELOG.md

@@ -8,6 +8,10 @@ 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.
 
 - v0.15.57 (2026-06-29) — **The RFC 9421 HTTP-message-signature verifier now enforces a required-coverage floor by default, refusing a signature whose covered set omits `@method` / `@target-uri` (and `content-digest` for bodied requests).** b.crypto.httpSig.verify built the signature base entirely from the covered-component list carried in the message's own Signature-Input header and never checked that the signature actually covered the security-relevant parts of the request (RFC 9421 §3.2). A signature covering only @authority therefore verified even after the method, target URI, or body were changed — so a captured signature could be replayed across a different method and path, or a request body swapped, under an otherwise-valid signature. verify now refuses a signature whose covered set omits a required component, returning { valid: false, reason: "missing-required-component", missing: [...] } before the cryptographic check. By default (security-on, not opt-in) it requires @method and @target-uri on every request, plus content-digest when the request carries a body; an operator can pass requiredComponents to assert an exact set, or requiredComponents: [] to waive the floor (the signature itself is still verified). **Security:** *httpSig.verify enforces a required-coverage floor (RFC 9421 §3.2)* — The verifier trusted the covered-component list from the message's Signature-Input header without requiring that any particular component be covered, so an under-covered signature (e.g. covering only @authority) verified while the method, target URI, and body were free to change — a captured signature replayed across method+path, or a swapped body, passed verification. verify now refuses a signature missing a required component with reason "missing-required-component" (and a missing[] list) before the crypto check. The default floor is @method + @target-uri on every request plus content-digest for bodied requests; requiredComponents overrides it explicitly, and requiredComponents: [] waives the floor for callers that intentionally sign a narrower set (the signature itself is still verified). **Migration:** *Signers must cover @method + @target-uri (and content-digest for bodied requests)* — If you verify HTTP message signatures with b.crypto.httpSig.verify, signatures whose covered set omits @method or @target-uri (or content-digest on a request with a body) now fail with reason "missing-required-component". Broaden the signer's covered set to include them (recommended), pass requiredComponents to assert the exact components your application requires, or pass requiredComponents: [] to keep the prior behavior of accepting whatever the signer covered. Verifying a fully-covered signature is unchanged.

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/lib/network-tls.js

@@ -857,6 +857,16 @@ var OID_BASIC_OCSP_RESPONSE = "1.3.6.1.5.5.7.48.1.1";
 // OCSP nonce extension — id-pkix-ocsp-nonce.
 var OID_OCSP_NONCE          = "1.3.6.1.5.5.7.48.1.2";
 var OID_SHA1                = "1.3.14.3.2.26";                                   // SHA-1 algorithm OID arc
+// RFC 6960 §4.1.1 CertID hashAlgorithm OIDs → node hash name. SHA-1 is the
+// universally-supported default (buildOcspRequest emits it); the SHA-2 family is
+// §4.3-optional but accepted when a responder uses it. An unknown OID is refused
+// (fail closed) rather than skipping the issuer binding.
+var OCSP_CERTID_HASH_OID_TO_NODE = {
+  "1.3.14.3.2.26":          "sha1",     // id-sha1
+  "2.16.840.1.101.3.4.2.1": "sha256",   // id-sha256
+  "2.16.840.1.101.3.4.2.2": "sha384",   // id-sha384
+  "2.16.840.1.101.3.4.2.3": "sha512",   // id-sha512
+};
 var OID_RSA_SHA256          = "1.2.840.113549.1.1.11";
 var OID_RSA_SHA384          = "1.2.840.113549.1.1.12";
 var OID_RSA_SHA512          = "1.2.840.113549.1.1.13";
@@ -1032,7 +1042,20 @@ function parseOcspResponse(der) {
     if (sr.length < 3) continue;                                                 // minimum SingleResponse fields
     // sr[0] = certID SEQUENCE, sr[1] = certStatus CHOICE, sr[2] = thisUpdate.
     var certIdChildren = asn1.readSequence(sr[0].value);
-    // certID = SEQUENCE { hashAlgorithm, issuerNameHash, issuerKeyHash, serialNumber }
+    // certID = SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash
+    //                     OCTET STRING, issuerKeyHash OCTET STRING,
+    //                     serialNumber INTEGER }  (RFC 6960 §4.1.1)
+    // Capture ALL FOUR fields. A response binds to the cert under validation by
+    // (issuerNameHash, issuerKeyHash, serialNumber): a serial is unique only
+    // PER ISSUER, so a "good" for serial-S under a different issuer (a delegated
+    // responder, or a CA key spanning issuer identities) must not be accepted as
+    // proof for serial-S under the issuer we actually asked about.
+    var certIdHashAlgOid = certIdChildren.length >= 1
+      ? asn1.readOid(asn1.readSequence(certIdChildren[0].value)[0]) : null;
+    var issuerNameHash = certIdChildren.length >= 2
+      ? asn1.readOctetString(certIdChildren[1]) : null;
+    var issuerKeyHash = certIdChildren.length >= 3
+      ? asn1.readOctetString(certIdChildren[2]) : null;
     var serialHex = certIdChildren.length >= 4
       ? certIdChildren[3].value.toString("hex")
       : null;
@@ -1053,10 +1076,13 @@ function parseOcspResponse(der) {
       nextUpdate = _parseTime(asn1.readNode(sr[3].value, 0));
     }
     responses.push({
-      certIdSerialHex: serialHex,
-      certStatus:      certStatus,
-      thisUpdate:      thisUpdate,
-      nextUpdate:      nextUpdate,
+      certIdSerialHex:  serialHex,
+      certIdHashAlgOid: certIdHashAlgOid,
+      issuerNameHash:   issuerNameHash,
+      issuerKeyHash:    issuerKeyHash,
+      certStatus:       certStatus,
+      thisUpdate:       thisUpdate,
+      nextUpdate:       nextUpdate,
     });
   }
 
@@ -1169,6 +1195,40 @@ function evaluateOcspResponse(ocspDer, opts) {
     return { ok: false, status: parsed.status, signatureValid: true,
              errors: ["OCSP response has no entry for the requested cert serial"] };
   }
+  // Bind the matched SingleResponse to the ISSUER of the cert under validation,
+  // not the serial alone. RFC 6960 §4.1.1: CertID is (hashAlgorithm,
+  // issuerNameHash, issuerKeyHash, serialNumber); a serial is unique only per
+  // issuer. Without this, a "good" for serial-S signed by a key that also serves
+  // a DIFFERENT issuer (delegated responder, or a CA key spanning issuer
+  // identities) is accepted as proof for serial-S under the issuer we asked
+  // about. opts.issuerCertDer is the issuer cert (DER) whose DN + SPKI we hash;
+  // both built-in consumer paths forward it from the issuer cert they hold.
+  if (opts.issuerCertDer) {
+    if (!Buffer.isBuffer(opts.issuerCertDer)) {
+      return { ok: false, status: parsed.status, signatureValid: true,
+               errors: ["evaluateOcspResponse: opts.issuerCertDer must be a Buffer (issuer cert DER)"] };
+    }
+    if (!match.issuerNameHash || !match.issuerKeyHash) {
+      return { ok: false, status: parsed.status, signatureValid: true,
+               errors: ["OCSP CertID is missing issuerNameHash/issuerKeyHash — cannot bind the response to the issuer"] };
+    }
+    var expected;
+    try { expected = _expectedOcspCertIdHashes(opts.issuerCertDer, match.certIdHashAlgOid); }
+    catch (e) {
+      return { ok: false, status: parsed.status, signatureValid: true,
+               errors: [(e && e.message) || String(e)] };
+    }
+    if (expected.nameHash.length !== match.issuerNameHash.length ||
+        !bCrypto.timingSafeEqual(expected.nameHash, match.issuerNameHash)) {
+      return { ok: false, status: parsed.status, signatureValid: true,
+               errors: ["OCSP CertID issuerNameHash does not match the issuer of the cert under validation (RFC 6960 §4.1.1 — wrong-issuer response)"] };
+    }
+    if (expected.keyHash.length !== match.issuerKeyHash.length ||
+        !bCrypto.timingSafeEqual(expected.keyHash, match.issuerKeyHash)) {
+      return { ok: false, status: parsed.status, signatureValid: true,
+               errors: ["OCSP CertID issuerKeyHash does not match the issuer of the cert under validation (RFC 6960 §4.1.1 — wrong-issuer response)"] };
+    }
+  }
   // Optional nonce echo verification (RFC 8954 / RFC 6960 §4.4.1).
   // When opts.expectedNonce is supplied, the response MUST carry an
   // OCSP nonce extension equal to the expected bytes — defends against
@@ -1321,6 +1381,27 @@ function _extractIssuerNameDerAndKeyBitString(certDer) {
   };
 }
 
+// Compute the EXPECTED CertID issuerNameHash + issuerKeyHash for an issuer cert
+// (DER), under the hash algorithm the responder used. RFC 6960 §4.1.1:
+// issuerNameHash = Hash(issuer DN, DER); issuerKeyHash = Hash(issuer
+// subjectPublicKey BIT STRING contents — the key bytes, not the SPKI SEQUENCE).
+// Reuses _extractIssuerNameDerAndKeyBitString (the same inputs buildOcspRequest
+// hashes) so the request-build and the response-bind hash IDENTICAL bytes.
+function _expectedOcspCertIdHashes(issuerCertDer, certIdHashAlgOid) {
+  var nodeHash = OCSP_CERTID_HASH_OID_TO_NODE[certIdHashAlgOid];
+  if (!nodeHash) {
+    throw new TlsTrustError("tls/ocsp-bad-certid-hash-alg",
+      "OCSP CertID hashAlgorithm OID '" + certIdHashAlgOid +
+      "' is not a recognized hash (RFC 6960 §4.1.1)");
+  }
+  var iss = _extractIssuerNameDerAndKeyBitString(issuerCertDer);
+  // lgtm[js/weak-cryptographic-algorithm] — RFC 6960 §4.1.1 CertID lookup hash over the PUBLIC issuer name; a name/key lookup, not an integrity or secrecy operation.
+  var nameHash = nodeCrypto.createHash(nodeHash).update(iss.issuerNameDer).digest(); // lgtm[js/weak-cryptographic-algorithm]
+  // lgtm[js/weak-cryptographic-algorithm] — RFC 6960 §4.1.1 CertID lookup hash over the PUBLIC issuer key; a name/key lookup, not an integrity or secrecy operation.
+  var keyHash = nodeCrypto.createHash(nodeHash).update(iss.issuerKey).digest(); // lgtm[js/weak-cryptographic-algorithm]
+  return { nameHash: nameHash, keyHash: keyHash };
+}
+
 function _extractLeafSerial(leafCertDer) {
   var top = asn1.readNode(leafCertDer);
   if (top.tag !== asn1.TAG.SEQUENCE) {
@@ -1470,6 +1551,9 @@ async function fetchOcspResponse(opts) {
   }
   var evald = evaluateOcspResponse(res.body, {
     issuerPem:     opts.issuerPem,
+    // Bind the response's CertID to the actual issuer (RFC 6960 §4.1.1), not
+    // the serial alone — issuerX is the issuer cert we already parsed.
+    issuerCertDer: issuerX.raw,
     // Bind to the leaf being checked (its serial), not whatever the response
     // happens to carry — defaults to leafX.serialNumber when not overridden.
     serialHex:     opts.serialHex || leafX.serialNumber,
@@ -1510,8 +1594,16 @@ var ocsp = Object.freeze({
       throw new TlsTrustError("tls/ocsp-empty",
         "OCSP response was empty");
     }
+    // opts.issuerPem is the OCSP-SIGNING cert, which may be a DELEGATED responder
+    // (not the leaf's issuing CA). The CertID issuer hashes are computed over the
+    // leaf's issuer, so the RFC 6960 §4.1.1 binding needs the actual issuer cert,
+    // supplied explicitly as opts.issuerCertDer. Deriving it from issuerPem would
+    // hash the responder and wrongly reject valid delegated-responder staples, so
+    // when issuerCertDer is absent the bind stays on serial + signature only.
+    var rgIssuerCertDer = Buffer.isBuffer(opts.issuerCertDer) ? opts.issuerCertDer : null;
     var evald = evaluateOcspResponse(rv.ocspBytes, {
       issuerPem: opts.issuerPem,
+      issuerCertDer: rgIssuerCertDer,
       // Bind to the connected peer's certificate serial (not the response's own
       // entry) — without it evaluateOcspResponse fails closed.
       serialHex: opts.serialHex || (rv.peerCert && rv.peerCert.serialNumber) || null,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/core",
-  "version": "0.15.58",
+  "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:35ef4bd7-07c5-42a5-b080-7b6950504f68",
+  "serialNumber": "urn:uuid:9f023375-6f18-4c24-a12a-74b1fc204f53",
   "version": 1,
   "metadata": {
-    "timestamp": "2026-06-29T12:31:38.470Z",
+    "timestamp": "2026-06-29T15:45:36.020Z",
     "lifecycles": [
       {
         "phase": "build"
@@ -19,14 +19,14 @@
       }
     ],
     "component": {
-      "bom-ref": "@blamejs/core@0.15.58",
+      "bom-ref": "@blamejs/core@0.15.60",
       "type": "application",
       "name": "blamejs",
-      "version": "0.15.58",
+      "version": "0.15.60",
       "scope": "required",
       "author": "blamejs contributors",
       "description": "The Node framework that owns its stack.",
-      "purl": "pkg:npm/%40blamejs/core@0.15.58",
+      "purl": "pkg:npm/%40blamejs/core@0.15.60",
       "properties": [],
       "externalReferences": [
         {
@@ -54,7 +54,7 @@
   "components": [],
   "dependencies": [
     {
-      "ref": "@blamejs/core@0.15.58",
+      "ref": "@blamejs/core@0.15.60",
       "dependsOn": []
     }
   ]