@kirrosh/zond 0.23.0 → 0.26.1

package/src/core/checks/checks/negative_data_rejection.ts

@@ -3,13 +3,39 @@
  * The runner builds a single-site negative case (one mutation against
  * a valid body, see `_negative_mutator.ts`); if the server still
  * accepts it (status outside 4xx/5xx + 401/403/404 admin set), we
- * raise a finding — *unless* an anti-FP guard fires (see `_anti_fp.ts`).
+ * raise a finding with raw evidence. The agent triages / re-severitizes.
  *
  * Default expected: 400 / 401 / 403 / 404 / 422 / 428 / 5xx.
  *   2xx and 3xx with our payload are findings.
+ *
+ * Severity matrix (ARV-284, dispatched per finding via outcome.severity
+ * — see `severityForEvidence` below):
+ *
+ *   - MEDIUM: concrete schema breach silently accepted (maxLength+1,
+ *             type-mismatch, pattern-violation, format-invalid,
+ *             drop-required, uniqueItems-violation, drop-required-query).
+ *             Server should reject; evidence single-signal but breach
+ *             is concrete.
+ *   - LOW:    `additionalProperties-violation` (unknown body fields
+ *             silently dropped is documented forward-compat in many
+ *             APIs — Stripe by design) and `wrong-type` query params
+ *             on GET list endpoints (often "invalid id → empty
+ *             result" documented behaviour). Single-signal, ambiguous
+ *             intent.
+ *
+ * Note: 5xx on a negative mutation does NOT escalate this check —
+ * `not_a_server_error` (separate check, severity HIGH by design) owns
+ * the 5xx signal, and `ACCEPTABLE()` below treats 5xx as a non-silent
+ * accept so this check passes for those cases. Avoids double-counting.
+ *
+ * Per ARV-250's proof-cap principle (no evidence → no high severity):
+ * single-signal proof caps at LOW; concrete schema breach escalates to
+ * MEDIUM. The declared `severity: "low"` is the natural fallback /
+ * proof-cap baseline; stronger findings use `outcome.severity` to
+ * override. The agent re-severitizes from the raw evidence.
  */
-import type { Check } from "../types.ts";
-import { applyAntiFp } from "../../anti-fp/index.ts";
+import type { Check, CheckOutcome } from "../types.ts";
+import type { Severity } from "../../severity/index.ts";
 
 const ACCEPTABLE = (status: number): boolean => {
   if (status === 400 || status === 401 || status === 403 || status === 404 || status === 422 || status === 428) return true;
@@ -17,29 +43,106 @@ const ACCEPTABLE = (status: number): boolean => {
   return false;
 };
 
+/** Body-boundary labels we treat as LOW (often by-design vendor
+ *  behaviour, single-signal, ambiguous intent). All other boundary
+ *  labels emitted by `coverage-phase.ts:enumerateBoundaryCases` —
+ *  maxLength+1, pattern-violation, uuid-invalid, drop-required:X, etc.
+ *  — are concrete schema breaches and stay MEDIUM. */
+const LOW_BODY_BOUNDARIES: ReadonlySet<string> = new Set([
+  "additionalProperties-violation",
+]);
+
+/** Param-scenario labels (`coverage-phase.ts:enumerateParamBoundaryCases`)
+ *  we treat as LOW. `wrong-type` is the classic "Stripe returns empty
+ *  list for invalid id" pattern — many APIs document this; flagging
+ *  HIGH/MEDIUM produces noise. `drop-required-query` stays MEDIUM (a
+ *  declared-required param being silently optional is a concrete
+ *  contract gap, not vendor convention). */
+const LOW_PARAM_SCENARIOS_ON_GET: ReadonlySet<string> = new Set([
+  "wrong-type",
+]);
+
+interface MutationMeta {
+  mutation?: string;
+  boundary?: string;
+  param_scenario?: string;
+  param_location?: string;
+}
+
+function severityForEvidence(
+  meta: MutationMeta | undefined,
+  method: string,
+): Severity {
+  if (!meta) return "low";
+
+  // Param-side mutations (query / path wrong-type, drop-required-query).
+  if (meta.mutation === "param-boundary") {
+    const scenario = meta.param_scenario ?? "";
+    if (
+      meta.param_location === "query"
+      && method.toUpperCase() === "GET"
+      && LOW_PARAM_SCENARIOS_ON_GET.has(scenario)
+    ) {
+      return "low";
+    }
+    // drop-required-query, wrong-type on non-GET, wrong-type on path
+    // params: concrete contract violations server should reject.
+    return "medium";
+  }
+
+  // Body-boundary mutations (additionalProperties, maxLength+1, etc).
+  if (meta.mutation === "boundary") {
+    const boundary = meta.boundary ?? "";
+    if (LOW_BODY_BOUNDARIES.has(boundary)) return "low";
+    return "medium";
+  }
+
+  // Unknown mutation kind — single-signal fallback.
+  return "low";
+}
+
 export const negativeDataRejection: Check = {
   id: "negative_data_rejection",
-  severity: "high",
+  // ARV-284: declared severity is the *natural* tier (proof-cap baseline
+  // per ARV-250 — single-signal caps at LOW). Per-finding severity is
+  // dispatched via `outcome.severity` in `run()` below, so summary
+  // tables can show HIGH for 5xx and MEDIUM for concrete schema breach
+  // without globally setting the check to HIGH (which masks calibration).
+  severity: "low",
   defaultExpected: "Server must reject invalid bodies with 400/401/403/404/422/428 (or 5xx)",
   references: [{ id: "OWASP-API-08" }],
   caseKinds: ["negative_data"],
   applies: (op) => Boolean(op.requestBodySchema),
-  run({ case: c, response }) {
-    if (ACCEPTABLE(response.status)) return { kind: "pass" };
-    const skip = applyAntiFp(c, "check:negative_data_rejection");
-    if (skip) {
-      return { kind: "skip", reason: `${skip.ruleId}: ${skip.reason}` };
+  run({ case: c, response }): CheckOutcome {
+    const meta = c.meta as MutationMeta | undefined;
+    const method = c.operation.method.toUpperCase();
+    const bodyless = method === "GET" || method === "HEAD" || method === "DELETE";
+    // ARV-345 (scope fix, like ARV-340): don't manufacture "accepted an invalid
+    // body" findings on methods with no request-body semantics. A GET/HEAD/DELETE
+    // that 2xx's a mutated body simply ignored the body — correct, not a gap.
+    if (bodyless && meta?.mutation === "boundary") {
+      return { kind: "skip", reason: "body mutation not applicable on GET/HEAD/DELETE (no request-body semantics)" };
+    }
+    // ARV-345: an unknown / wrong-type QUERY param a GET tolerates (2xx) is
+    // documented leniency ("invalid id → empty list"), not a rejectable invalid.
+    // drop-required-query stays in scope — a declared-required param silently
+    // optional IS a concrete contract gap.
+    if (
+      bodyless
+      && meta?.mutation === "param-boundary"
+      && meta?.param_location === "query"
+      && LOW_PARAM_SCENARIOS_ON_GET.has(meta?.param_scenario ?? "")
+    ) {
+      return { kind: "skip", reason: "unknown/wrong-type query param on GET is documented leniency, not a validation gap" };
     }
+    if (ACCEPTABLE(response.status)) return { kind: "pass" };
     return {
       kind: "fail",
       message: `Server accepted an invalid body (status ${response.status}) — single-site mutation: ${
-        // eslint-disable-next-line @typescript-eslint/no-explicit-any
-        (c.meta as any)?.mutation
-      } @ ${
-        // eslint-disable-next-line @typescript-eslint/no-explicit-any
-        (c.meta as any)?.field_path
-      }`,
-      evidence: { status: response.status, mutation: c.meta },
+        meta?.mutation ?? "unknown"
+      } @ ${meta?.boundary ?? meta?.param_scenario ?? "?"}`,
+      evidence: { status: response.status, mutation: meta },
+      severity: severityForEvidence(meta, c.operation.method),
     };
   },
 };

package/src/core/checks/checks/not_a_server_error.ts

@@ -13,6 +13,14 @@ export const notAServerError: Check = {
   references: [
     { id: "RFC-9110-15.6", url: "https://www.rfc-editor.org/rfc/rfc9110#name-server-error-5xx" },
   ],
+  // ARV-340: evaluate malformed-input cases too, not just the positive
+  // baseline. A negative_data / missing-header request is still a
+  // well-formed HTTP request the server must handle with a 4xx — a 5xx
+  // there is an unhandled crash (live Stripe: GET /v1/billing/alerts 500
+  // on a bad query param slipped through when this defaulted to positive
+  // only). `unsupported_method` is excluded on purpose: 501/405 to an
+  // undeclared method is legitimate, not a server error.
+  caseKinds: ["positive", "negative_data", "missing_required_header"],
   applies: () => true,
   run({ response }) {
     if (response.status >= 500 && response.status < 600) {

package/src/core/checks/checks/open_cors_on_sensitive.ts

@@ -99,30 +99,59 @@ export const openCorsOnSensitive: AuthStatefulCheck = {
     const originIsStar = allowOrigin === "*";
     const originReflects = allowOrigin === PROBE_ORIGIN;
 
-    // The smoking guns.
-    if (credsTrue && originIsStar) {
-      return {
-        kind: "fail",
-        message:
-          "CORS misconfiguration: Allow-Origin: * with Allow-Credentials: true allows cross-origin reads of authenticated data",
-        evidence: {
-          request_origin: PROBE_ORIGIN,
-          access_control_allow_origin: allowOrigin,
-          access_control_allow_credentials: allowCreds,
-          variant: "wildcard+credentials",
-        },
-      };
-    }
-    if (credsTrue && originReflects) {
+    // HIGH requires two independent pieces of evidence that authed data is
+    // actually CORS-readable by an attacker site:
+    //
+    // ARV-312: a 2xx response served real content under the reflected
+    //   Origin. On a non-2xx (401/403/4xx/5xx) *this* response exposed no
+    //   authenticated payload. Recording the real status also kills the
+    //   phantom `response_summary.status: 0` (auth checks don't otherwise
+    //   thread their response back to the runner).
+    //
+    // ARV-316: an AMBIENT credential the browser auto-attaches cross-origin
+    //   — i.e. a cookie (apiKey-in-cookie scheme, or a Set-Cookie observed
+    //   on the probe). `Allow-Credentials: true` is only exploitable with
+    //   one: for bearer/header/oauth2 token auth the attacker's page can't
+    //   set the victim's Authorization header, so a reflected Origin is a
+    //   hygiene nit, not a data leak (Stripe et al are bearer-auth).
+    //
+    // Without both, cap at LOW per the m-21 "no evidence → no high" matrix.
+    const status = resp.status;
+    const isTwoXx = status >= 200 && status < 300;
+    const schemes = (h.doc?.components?.securitySchemes ?? {}) as Record<
+      string,
+      OpenAPIV3.SecuritySchemeObject | OpenAPIV3.ReferenceObject
+    >;
+    const usesCookieAuth = op.security.some((name) => {
+      const s = schemes[name];
+      return !!s && !("$ref" in s) && s.type === "apiKey" && s.in === "cookie";
+    });
+    const setCookie = getHeader(resp.headers, "set-cookie");
+    const ambientCredential = usesCookieAuth || setCookie !== undefined;
+    const authExposed = isTwoXx && ambientCredential;
+    const impactNote = authExposed
+      ? "any attacker site can read authed cross-origin responses"
+      : !isTwoXx
+        ? `observed on a ${status} response — cross-origin CORS is misconfigured but authed-data exposure is unproven`
+        : "no ambient (cookie) credential — bearer/token auth isn't auto-attached cross-origin, so the reflection isn't exploitable as a data leak";
+
+    if (credsTrue && (originIsStar || originReflects)) {
+      const variant = originIsStar ? "wildcard+credentials" : "reflected+credentials";
+      const shape = originIsStar
+        ? "Allow-Origin: * with Allow-Credentials: true"
+        : "response reflects arbitrary Origin with Allow-Credentials: true";
       return {
         kind: "fail",
-        message:
-          "CORS misconfiguration: response reflects arbitrary Origin with Allow-Credentials: true — any attacker site can read authed responses",
+        severity: authExposed ? "high" : "low",
+        responseStatus: status,
+        message: `CORS misconfiguration: ${shape} — ${impactNote}`,
         evidence: {
           request_origin: PROBE_ORIGIN,
+          response_status: status,
           access_control_allow_origin: allowOrigin,
           access_control_allow_credentials: allowCreds,
-          variant: "reflected+credentials",
+          ambient_credential: ambientCredential,
+          variant,
         },
       };
     }