/** * Payload sets specific to auth-attack scenarios. We reuse the * generic `SQLI_PAYLOADS` / `XSS_PAYLOADS` exports from * `../payloads.ts` but add purpose-built lists for weak passwords * and an internal helper for generating one-shot test emails. */ /** * Top entries from NIST / Have-I-Been-Pwned breach datasets, capped * to the kind of password a casual user might pick. NIST SP 800-63B * §5.1.1.2 explicitly requires checking against this kind of list * before accepting a new password. If your signup flow accepts any * of these, that requirement is unmet. */ export declare const WEAK_PASSWORDS: ReadonlyArray; /** * Credentials we use as "definitely-doesn't-exist" inputs for * username-enumeration probes. The `.invalid` TLD is reserved by * RFC 2606 so this can never match a real address even by accident. */ export declare const NONEXISTENT_USERNAME = "chaosbringer-noexist-9f3c@example.invalid"; /** Generate a one-shot test email so repeated signups never collide. */ export declare function freshTestEmail(salt?: string): string; /** * SQL error fragments that signal the server piped raw input into a * database driver. Conservative — these are SQL-y enough to be high * signal (we don't want to flag legitimate copy mentioning the word * "syntax"). */ export declare const SQL_ERROR_SIGNATURES: ReadonlyArray; /** * A small SQLi shortlist tailored to auth bypass attempts. The * generic `SQLI_PAYLOADS` includes broader payloads that aren't * useful in a username/password context (e.g. UNION-based exfil). */ export declare const SQLI_AUTH_BYPASS_PAYLOADS: ReadonlyArray; /** * XSS payloads for the credential / display-name attack. We use a * marker the page can publish to `window.__cb_xss_fired = true` — * the attack reads that marker via `page.evaluate()` to confirm * execution. This avoids relying on `dialog` events which apps may * block or ignore. */ export declare const XSS_AUTH_MARKER = "__cb_xss_fired"; export declare const XSS_CREDENTIAL_PAYLOADS: ReadonlyArray; //# sourceMappingURL=payloads.d.ts.map