@stonyx/oauth 0.1.1-alpha.20 → 0.1.1-alpha.21

package/dist/auth-request.d.ts

@@ -134,8 +134,12 @@ export default class AuthRequest extends Request {
      * on. `Secure`, `HttpOnly` and `SameSite` do not constrain that: the attacker
      * is writing, not reading.
      *
-     * Bounded at `MAX_BINDING_COOKIE_CANDIDATES`, so the work an unauthenticated
-     * caller can ask for is capped whatever the header contains.
+     * Every value is returned, with no cap. A cap here does not bound an attack,
+     * it *is* one: truncating the list reinstates exactly the denial above its
+     * own threshold, because the planted cookies are the ones that sort first.
+     * The work is already bounded by Node's 16 KB header limit — at most 779
+     * hashable candidates, 0.32 ms to parse and hash all of them. See
+     * `constants.ts` for the measurement.
      */
     readBindingCookies(req: RouteRequest): string[];
     clearBindingCookie(req: RouteRequest): void;

package/dist/auth-request.js

@@ -1,7 +1,7 @@
 import { Request } from '@stonyx/rest-server';
 import log from 'stonyx/log';
 import { StateRejection } from './state-store.js';
-import { MAX_BINDING_COOKIE_CANDIDATES, STATE_COOKIE_NAME, STATE_COOKIE_PATH, STATE_COOKIE_SAME_SITE, STATE_TTL_MS, } from './constants.js';
+import { STATE_COOKIE_NAME, STATE_COOKIE_PATH, STATE_COOKIE_SAME_SITE, STATE_TTL_MS, } from './constants.js';
 /**
  * Hosts treated as a development origin by exact match, and — together with
  * `127.0.0.0/8` and the IPv4-mapped IPv6 spellings of it — the only ones exempt
@@ -306,8 +306,12 @@ export default class AuthRequest extends Request {
      * on. `Secure`, `HttpOnly` and `SameSite` do not constrain that: the attacker
      * is writing, not reading.
      *
-     * Bounded at `MAX_BINDING_COOKIE_CANDIDATES`, so the work an unauthenticated
-     * caller can ask for is capped whatever the header contains.
+     * Every value is returned, with no cap. A cap here does not bound an attack,
+     * it *is* one: truncating the list reinstates exactly the denial above its
+     * own threshold, because the planted cookies are the ones that sort first.
+     * The work is already bounded by Node's 16 KB header limit — at most 779
+     * hashable candidates, 0.32 ms to parse and hash all of them. See
+     * `constants.ts` for the measurement.
      */
     readBindingCookies(req) {
         const header = req.headers.cookie;
@@ -315,8 +319,6 @@ export default class AuthRequest extends Request {
             return [];
         const values = [];
         for (const part of header.split(';')) {
-            if (values.length >= MAX_BINDING_COOKIE_CANDIDATES)
-                break;
             const separator = part.indexOf('=');
             if (separator === -1)
                 continue;

package/dist/constants.d.ts

@@ -6,14 +6,28 @@ export declare const STATE_TTL_MS: number;
 /** Entropy of the client-held binding value, in bytes. */
 export declare const BINDING_VALUE_BYTES = 32;
 /**
- * Most values carrying `STATE_COOKIE_NAME` that a single callback will try.
+ * There is deliberately no cap on how many values carrying `STATE_COOKIE_NAME`
+ * a callback will try.
  *
- * A client can hold more than one cookie of the same name — a sibling
- * subdomain can set one on the parent domain, and the browser sends every
- * applicable cookie in one header. All of them are tried, so a planted cookie
- * cannot deny login by sorting ahead of the real one; the cap bounds the work
- * an unauthenticated caller can ask for. It is not a brute-force control: the
- * pending record is consumed on recognition, so a state gets one attempt
- * whatever the cap.
+ * A client can hold more than one cookie of the same name — a sibling subdomain
+ * can set one on the parent domain — and the browser sends every applicable
+ * cookie in one header, so all of them must be tried or a planted cookie denies
+ * login by sorting ahead of the real one (RFC 6265 section 5.4).
+ *
+ * A cap of 8 was tried and withdrawn: it *reinstated* that denial above its own
+ * threshold. Measured on the pre-change tree, 7 shadow cookies still minted a
+ * session and 8 failed permanently — the same outcome as the original defect,
+ * with the attacker's cost raised from one planted cookie to eight. That is
+ * reachable: RFC 6265 section 5.4 orders by path length then creation time, so
+ * a 4-label API host with a foothold beneath it gets 3 settable parent domains
+ * x 3 usable paths = 9 candidates ahead of the real one.
+ *
+ * What the cap was defending is already bounded, structurally and for free.
+ * Node caps the whole header block at `http.maxHeaderSize`, 16 KB by default,
+ * and the shortest segment that can reach the hash is `stonyx_oauth_state=x` at
+ * 20 bytes, so a request cannot present more than 779 hashable candidates.
+ * Parsing and SHA-256-hashing all 779 costs 0.32 ms median / 0.81 ms worst of 9
+ * runs (Node 24.13.0, Apple silicon). Paying a permanent, unauthenticated
+ * denial of login to avoid a third of a millisecond is the wrong trade, so the
+ * bound is left where it already was: the header size limit.
  */
-export declare const MAX_BINDING_COOKIE_CANDIDATES = 8;

package/dist/constants.js

@@ -15,14 +15,28 @@ export const STATE_TTL_MS = 10 * 60 * 1000;
 /** Entropy of the client-held binding value, in bytes. */
 export const BINDING_VALUE_BYTES = 32;
 /**
- * Most values carrying `STATE_COOKIE_NAME` that a single callback will try.
+ * There is deliberately no cap on how many values carrying `STATE_COOKIE_NAME`
+ * a callback will try.
  *
- * A client can hold more than one cookie of the same name — a sibling
- * subdomain can set one on the parent domain, and the browser sends every
- * applicable cookie in one header. All of them are tried, so a planted cookie
- * cannot deny login by sorting ahead of the real one; the cap bounds the work
- * an unauthenticated caller can ask for. It is not a brute-force control: the
- * pending record is consumed on recognition, so a state gets one attempt
- * whatever the cap.
+ * A client can hold more than one cookie of the same name — a sibling subdomain
+ * can set one on the parent domain — and the browser sends every applicable
+ * cookie in one header, so all of them must be tried or a planted cookie denies
+ * login by sorting ahead of the real one (RFC 6265 section 5.4).
+ *
+ * A cap of 8 was tried and withdrawn: it *reinstated* that denial above its own
+ * threshold. Measured on the pre-change tree, 7 shadow cookies still minted a
+ * session and 8 failed permanently — the same outcome as the original defect,
+ * with the attacker's cost raised from one planted cookie to eight. That is
+ * reachable: RFC 6265 section 5.4 orders by path length then creation time, so
+ * a 4-label API host with a foothold beneath it gets 3 settable parent domains
+ * x 3 usable paths = 9 candidates ahead of the real one.
+ *
+ * What the cap was defending is already bounded, structurally and for free.
+ * Node caps the whole header block at `http.maxHeaderSize`, 16 KB by default,
+ * and the shortest segment that can reach the hash is `stonyx_oauth_state=x` at
+ * 20 bytes, so a request cannot present more than 779 hashable candidates.
+ * Parsing and SHA-256-hashing all 779 costs 0.32 ms median / 0.81 ms worst of 9
+ * runs (Node 24.13.0, Apple silicon). Paying a permanent, unauthenticated
+ * denial of login to avoid a third of a millisecond is the wrong trade, so the
+ * bound is left where it already was: the header size limit.
  */
-export const MAX_BINDING_COOKIE_CANDIDATES = 8;

package/dist/state-store.d.ts

@@ -103,9 +103,11 @@ export default class StateStore {
      *
      * Accepting any match gives an attacker nothing: they would have to present
      * the victim's own binding value, which is the property being checked. The
-     * candidate list is bounded by `MAX_BINDING_COOKIE_CANDIDATES` at the point
-     * it is parsed, and the record is consumed on recognition, so a state still
-     * gets exactly one attempt.
+     * record is consumed on recognition, so a state still gets exactly one
+     * attempt however many candidates were presented, and the candidate count is
+     * bounded by Node's header size limit rather than by a cap here — a cap
+     * truncates the list from the wrong end and reinstates the denial this method
+     * exists to close. See `constants.ts`.
      *
      * The loop does not short-circuit, so the work is a function of how many
      * values were presented and not of which one matched.

package/dist/state-store.js

@@ -129,9 +129,11 @@ export default class StateStore {
      *
      * Accepting any match gives an attacker nothing: they would have to present
      * the victim's own binding value, which is the property being checked. The
-     * candidate list is bounded by `MAX_BINDING_COOKIE_CANDIDATES` at the point
-     * it is parsed, and the record is consumed on recognition, so a state still
-     * gets exactly one attempt.
+     * record is consumed on recognition, so a state still gets exactly one
+     * attempt however many candidates were presented, and the candidate count is
+     * bounded by Node's header size limit rather than by a cap here — a cap
+     * truncates the list from the wrong end and reinstates the denial this method
+     * exists to close. See `constants.ts`.
      *
      * The loop does not short-circuit, so the work is a function of how many
      * values were presented and not of which one matched.

package/package.json

@@ -4,7 +4,7 @@
     "stonyx-async",
     "stonyx-module"
   ],
-  "version": "0.1.1-alpha.20",
+  "version": "0.1.1-alpha.21",
   "description": "OAuth2 authentication module for the Stonyx framework",
   "repository": {
     "type": "git",
@@ -55,13 +55,13 @@
   },
   "dependencies": {
     "@stonyx/events": "0.1.1-beta.52",
-    "stonyx": "0.2.3-beta.76"
+    "stonyx": "0.2.3-beta.77"
   },
   "peerDependencies": {
     "@stonyx/rest-server": ">=0.2.1-beta.11"
   },
   "devDependencies": {
-    "@stonyx/rest-server": "0.2.1-beta.82",
+    "@stonyx/rest-server": "0.2.1-beta.83",
     "@stonyx/utils": "0.2.3-beta.26",
     "@stonyx/logs": "1.0.1-beta.19",
     "@types/qunit": "^2.19.13",

package/src/auth-request.ts

@@ -2,7 +2,6 @@ import { Request } from '@stonyx/rest-server';
 import log from 'stonyx/log';
 import { StateRejection } from './state-store.js';
 import {
-  MAX_BINDING_COOKIE_CANDIDATES,
   STATE_COOKIE_NAME,
   STATE_COOKIE_PATH,
   STATE_COOKIE_SAME_SITE,
@@ -397,8 +396,12 @@ export default class AuthRequest extends Request {
    * on. `Secure`, `HttpOnly` and `SameSite` do not constrain that: the attacker
    * is writing, not reading.
    *
-   * Bounded at `MAX_BINDING_COOKIE_CANDIDATES`, so the work an unauthenticated
-   * caller can ask for is capped whatever the header contains.
+   * Every value is returned, with no cap. A cap here does not bound an attack,
+   * it *is* one: truncating the list reinstates exactly the denial above its
+   * own threshold, because the planted cookies are the ones that sort first.
+   * The work is already bounded by Node's 16 KB header limit — at most 779
+   * hashable candidates, 0.32 ms to parse and hash all of them. See
+   * `constants.ts` for the measurement.
    */
   readBindingCookies(req: RouteRequest): string[] {
     const header = req.headers.cookie;
@@ -407,8 +410,6 @@ export default class AuthRequest extends Request {
     const values: string[] = [];
 
     for (const part of header.split(';')) {
-      if (values.length >= MAX_BINDING_COOKIE_CANDIDATES) break;
-
       const separator = part.indexOf('=');
       if (separator === -1) continue;
       if (part.slice(0, separator).trim() !== STATE_COOKIE_NAME) continue;

package/src/constants.ts

@@ -19,14 +19,28 @@ export const STATE_TTL_MS = 10 * 60 * 1000;
 export const BINDING_VALUE_BYTES = 32;
 
 /**
- * Most values carrying `STATE_COOKIE_NAME` that a single callback will try.
+ * There is deliberately no cap on how many values carrying `STATE_COOKIE_NAME`
+ * a callback will try.
  *
- * A client can hold more than one cookie of the same name — a sibling
- * subdomain can set one on the parent domain, and the browser sends every
- * applicable cookie in one header. All of them are tried, so a planted cookie
- * cannot deny login by sorting ahead of the real one; the cap bounds the work
- * an unauthenticated caller can ask for. It is not a brute-force control: the
- * pending record is consumed on recognition, so a state gets one attempt
- * whatever the cap.
+ * A client can hold more than one cookie of the same name — a sibling subdomain
+ * can set one on the parent domain — and the browser sends every applicable
+ * cookie in one header, so all of them must be tried or a planted cookie denies
+ * login by sorting ahead of the real one (RFC 6265 section 5.4).
+ *
+ * A cap of 8 was tried and withdrawn: it *reinstated* that denial above its own
+ * threshold. Measured on the pre-change tree, 7 shadow cookies still minted a
+ * session and 8 failed permanently — the same outcome as the original defect,
+ * with the attacker's cost raised from one planted cookie to eight. That is
+ * reachable: RFC 6265 section 5.4 orders by path length then creation time, so
+ * a 4-label API host with a foothold beneath it gets 3 settable parent domains
+ * x 3 usable paths = 9 candidates ahead of the real one.
+ *
+ * What the cap was defending is already bounded, structurally and for free.
+ * Node caps the whole header block at `http.maxHeaderSize`, 16 KB by default,
+ * and the shortest segment that can reach the hash is `stonyx_oauth_state=x` at
+ * 20 bytes, so a request cannot present more than 779 hashable candidates.
+ * Parsing and SHA-256-hashing all 779 costs 0.32 ms median / 0.81 ms worst of 9
+ * runs (Node 24.13.0, Apple silicon). Paying a permanent, unauthenticated
+ * denial of login to avoid a third of a millisecond is the wrong trade, so the
+ * bound is left where it already was: the header size limit.
  */
-export const MAX_BINDING_COOKIE_CANDIDATES = 8;

package/src/state-store.ts

@@ -161,9 +161,11 @@ export default class StateStore {
    *
    * Accepting any match gives an attacker nothing: they would have to present
    * the victim's own binding value, which is the property being checked. The
-   * candidate list is bounded by `MAX_BINDING_COOKIE_CANDIDATES` at the point
-   * it is parsed, and the record is consumed on recognition, so a state still
-   * gets exactly one attempt.
+   * record is consumed on recognition, so a state still gets exactly one
+   * attempt however many candidates were presented, and the candidate count is
+   * bounded by Node's header size limit rather than by a cap here — a cap
+   * truncates the list from the wrong end and reinstates the denial this method
+   * exists to close. See `constants.ts`.
    *
    * The loop does not short-circuit, so the work is a function of how many
    * values were presented and not of which one matched.