Was wir testen
Jeder Scan startet zuerst dieselbe deterministische Engine — keine Zufälligkeit, kein Raten. Baseline (8 Tests) gibt schnelles Feedback bei jedem Push; Deep (430+ Prüfungen) führt das volle Paket nach Zeitplan oder vor dem Release aus. Dazu: KI-gestützte Triage, autonomer Hacker mode und ein Code-Fragebogen (Ask mode, SaaS+) für das, was kein Scanner von außen sieht.
430+ Prüfungen insgesamt: 149 automatisierte Scan-Tests + 280+ Hardening-Review-Fragen.
Baseline — 8 Tests bei jedem Lauf
Fehlerhafte Authentifizierung
Prüft, ob ein Endpunkt, der Authentifizierung erfordert, ohne Token oder mit einem ungültigen Token funktioniert.
Wie: Wiederholt die Anfrage ohne Authorization-Header und mit einem zufälligen Token; 2xx bedeutet, die Auth-Prüfung fehlt oder ist defekt.
Beispiel: GET /users/me liefert 200 ohne Token → jeder kann das Profil lesen.
BOLA / IDOR
Prüft, ob der Austausch einer Ressourcen-ID Zugriff auf fremde Daten gibt (Broken Object-Level Authorization).
Wie: Heuristiken über ID-ähnliche Parameter: probiert andere/typische Identifikatoren und vergleicht Antworten auf Datenlecks.
Beispiel: GET /orders/124 liefert die Bestellung eines anderen Kunden → kritisches Datenleck.
Mass Assignment
Prüft, ob der Server still zusätzliche Felder akzeptiert, die nie dokumentiert wurden.
Wie: Fügt dem Payload zusätzliche Felder hinzu und sucht deren Echo/Persistenz in der Antwort.
Beispiel: POST /users akzeptiert {"is_admin": true} → Rechteeskalation.
Injection (SQL / NoSQL / JSON)
Sondiert Query-Parameter und Body-Felder auf Injection-Schwachstellen.
Wie: Sendet klassische SQL-/NoSQL-/JSON-Payloads und gleicht Fehlersignaturen sowie Timing-Anomalien in Antworten ab.
Beispiel: ' OR '1'='1 in ?search= löst einen SQL-Fehler aus → injizierbarer Parameter.
Rate Limiting
Prüft, ob die API wiederholte Anfragen drosselt.
Wie: Feuert einen Burst identischer Anfragen auf einen Endpunkt; kein 429 bedeutet offene Türen für Brute Force und Scraping.
Beispiel: 12 schnelle POST /login ohne 429 → Credential Stuffing möglich.
CORS-Fehlkonfiguration
Prüft, ob die API beliebige Origins mit erlaubten Credentials widerspiegelt.
Wie: Sendet bösartige Origin-Header und prüft Access-Control-Allow-Origin / Allow-Credentials.
Beispiel: Origin: https://evil.example mit Credentials reflektiert → Session-Diebstahl über den Browser.
Security Header
Prüft fehlende grundlegende HTTP-Security-Header.
Wie: Liest Response-Header (nosniff, Frame Options, HSTS, CSP, Referrer Policy) an jedem Ziel.
Beispiel: Fehlende X-Content-Type-Options und Frame-Schutz → Clickjacking-/MIME-Sniffing-Risiko.
Sensible Parameter
Findet Secrets, Tokens und Passwörter, die im URL-Query-String übergeben werden.
Wie: Scannt Query-Namen auf secret-ähnliche Schlüssel (token, key, password, secret), die in Logs und Browser-Historie lecken.
Beispiel: GET /reset?token=abc123 in der URL → Secret landet in Proxy-Logs.
Deep — 141 weitere Tests für geplante und Release-Scans
Shadow-API-Erkennung
Findet nicht dokumentierte Endpunkte, die hinter Ihrem Rücken antworten (Admin, Debug, alte Versionen, Backups).
Wie: Sondiert gängige Varianten dokumentierter Pfade plus globale Pfade (/health, /swagger.json, /actuator); 2xx/3xx auf einem nicht dokumentierten Pfad ist ein Fund.
Beispiel: /admin/users antwortet 200, steht aber nirgends in der Spezifikation → versteckte Angriffsfläche.
JWT-Schwächen
Greift das Token selbst an: alg=none, unverifizierte Signatur, schwaches HMAC-Secret, fehlendes Ablaufdatum, Key Confusion.
Wie: Zuerst Baseline (gültiges Token funktioniert, Müll wird abgelehnt — sonst ist es schlicht defekte Auth); dann mutierte Tokens nur auf gesicherten Endpunkten wiederholen.
Beispiel: Token mit alg=none akzeptiert → jeder kann Sessions fälschen.
HTTP-Method-Tampering
Prüft, ob Zugriffskontrolle nur an der dokumentierten Methode hängt.
Wie: Probiert denselben Pfad mit anderen Verben (GET→POST/PUT/DELETE); 2xx mit Inhalt bei einer nicht deklarierten Methode ist ein Bypass.
Beispiel: GET /admin → 403, aber POST /admin → 200 → Autorisierungs-Bypass.
Tech-Fingerprint + Versionsaktualität
Identifiziert den Server-Stack aus Headern und Fehlerseiten und markiert Software am End-of-Life.
Wie: Sammelt Server / X-Powered-By aus GET / und einem absichtlichen 404, gleicht mit einer eingebauten Versionstabelle ab; EOL ist hohe Severity.
Beispiel: Server: PHP/7.4 (End-of-Life) → ungepatchte CVEs wahrscheinlich.
Mass Assignment v2 (Read-only-Eskalation)
Geht einen Schritt weiter als v1: beweist Rechteeskalation über Read-only-Felder.
Wie: Sendet Canary-Sonden, ignoriert schema-deklarierte Felder und verlangt ein exaktes Wert-Echo; nur berechtigungsrelevante Felder (role, is_admin) erhöhen auf hoch.
Beispiel: {"role":"admin"} exakt zurückgegeben → bestätigte Eskalation.
Checkliste für Informationslecks
Durchsucht bekannte sensible Pfade (.git, .env, Debug-Konsolen, Actuators, Metriken).
Wie: Inhalt zählt, nicht Status: Ein Fund braucht einen echten Marker im Body; leere Bodies und Login-Seiten bleiben still. Plus Stack-Trace-Erkennung auf einem fehlenden Pfad.
Beispiel: /.git/config gibt Repository-Interna preis → hoch.
Rate-Limit v2 (differentiell + Bypass)
Stellt die unangenehmeren Fragen: Ist Login gedrosselt, wenn der Rest es ist? Lässt sich das Limit mit einem gefälschten IP-Header umgehen?
Wie: Vergleicht einen Auth-Endpunkt mit einem neutralen, dann wiederholt mit X-Forwarded-For-Rotation unter kontrollierten Bedingungen.
Beispiel: Unbegrenzter Login neben limitierter API → Credential Stuffing; XFF-Rotation umgeht 429 → hoch.
Tenant-Header-Replay
Prüft, ob Client-Tenant-Header den Datenzugriff steuern.
Wie: Wiederholt eine Anfrage mit getauschtem X-Tenant-ID/X-Org-ID (max. 2 Anfragen); andere Daten beim selben Token sind mittel — vollständiges Cross-Token-Replay ist eine Hacker-Mission.
Beispiel: Header other9 leakt fremde Zeilen → Tenant serverseitig ableiten.
Hygiene von Token-Claims
Markiert Scan-Tokens ohne Ablaufdatum oder Audience.
Wie: Null Anfragen: dekodiert das Scan-Bearer-JWT; fehlendes exp ist mittel, fehlendes aud niedrig — Cross-API-Replay selbst braucht eine zweite API (Hacker).
Beispiel: Kein exp/aud → kurze TTL + feste Audience.
Verkettung von Angriffspfaden
Verkettet Funde über Kill-Chain-Stufen im Bericht.
Wie: Null Anfragen: Die Engine gruppiert Funde (Auth-Bypass → Datenzugriff → Exfiltration) und gibt eine informative Kette aus — Input für den TTP-Graph.
Beispiel: Juggling → Export → den Kopf der Kette beheben.
CORS- + CSRF-Kette
Greift die Allowlist-Logik selbst an, nicht nur einfache Reflexion.
Wie: Prüft Origin: null, täuschend ähnliche Domains ({host}.evil.example) und Preflight bei Schreibmethoden mit Credentials.
Beispiel: Null-Origin mit Credentials vertraut → Session-Diebstahl über sandboxed iframe.
SSRF-Canary
Prüft, ob die API vom Angreifer gelieferte URLs abruft (Server-Side Request Forgery) — sicher, ausschließlich gegen unseren eigenen Listener.
Wie: Pflanzt unsere Canary-URL in URL-förmige Felder (Webhook, Avatar, Import); ein Callback an unsere Infrastruktur beweist SSRF. Niemand sonst wird angegriffen.
Beispiel: POST /webhooks mit unserer URL → Server ruft zurück → SSRF bestätigt.
Session-Cookie-Flags
Prüft, ob Session-Cookies an Login-Endpunkten Secure, HttpOnly und eine strikte SameSite-Policy tragen.
Wie: Liest Set-Cookie in Login-Antworten; ein Fund pro fehlender Flag. Nur Set-Cookie-Antworten zählen — kein Cookie, kein Fund.
Beispiel: POST /login setzt Session ohne HttpOnly → Diebstahl per XSS.
Vorhersagbare ID-Enumeration
Prüft, ob aufeinanderfolgende Ressourcen-IDs einzeln abgreifbar sind (User-Enumeration).
Wie: Fordert IDs 1/2/3 auf Template-Pfaden an; drei verschiedene Datensätze bedeuten aufzählbare IDs. Einheitliche 404er bleiben still. Einmal pro Scan.
Beispiel: /users/1, /users/2, /users/3 liefern Profile → Nutzerbasis harvestbar.
Response-Time-Oracle
Prüft, ob die Antwortzeit beim Login vom Secret abhängt (Timing-Seitenkanal).
Wie: Wechselt kurze und lange Passwörter (4 Runden); nicht überlappende Zeitfenster mit >200 ms Abstand ergeben einen Low-Severity-Hinweis. Einmal pro Scan.
Beispiel: Lange Passwörter konstant 300 ms langsamer → Timing-Oracle sollte behoben werden.
Path Traversal / LFI
Prüft, ob Dateiparameter das Server-Dateisystem erreichen (Local File Inclusion).
Wie: Sendet ../ und kodierte Varianten; der /etc/passwd-Marker im Body ist ein High-Fund. Max. 2 Sonden pro Ziel.
Beispiel: ?file=../../../../etc/passwd liefert root:x:0: → Serverdateien lesbar.
Open Redirect
Prüft Redirect-Parameter auf Open Redirect zu Angreifer-Hosts (Phishing / Token-Diebstahl).
Wie: Pflanzt https://evil.example in next/url/redirect-Parameter, ohne Redirects zu folgen; ein 3xx Location dorthin ist High.
Beispiel: /goto?next=https://evil.example → 302 dorthin → Login-Code-Diebstahl.
HTTP TRACE / TRACK
Prüft, ob die gefährlichen TRACE/TRACK-Methoden aktiv sind (Cross-Site Tracing).
Wie: Sendet OPTIONS einmal pro Scan; ein Allow-Header mit TRACE/TRACK ergibt einen Low-Fund.
Beispiel: Allow: GET, POST, TRACE, TRACK → Cookies per XST lesbar.
Backup-/Editor-Dateien
Prüft, ob Backup-Kopien (.bak, ~) dokumentierter Pfade mit Quellcode ausgeliefert werden.
Wie: Probiert .bak- und ~-Suffixe; 200 mit Quellcode-Markern ist ein Low-Fund. Max. 8 Requests pro Scan.
Beispiel: /config.js.bak liefert Server-Quellcode → Secrets und Logik geleakt.
Standard-Credentials
Prüft, ob Standard-Logins (admin:admin, admin:password) noch funktionieren.
Wie: Probiert zwei Standard-Paare nur am Login-Endpunkt, einmal pro Scan; ein Login, der ein Token vergibt, ist High. Echte Nutzerkonten werden nie berührt.
Beispiel: POST /session admin:admin → Session-Token → vollständige Übernahme.
Null-Byte-/Unicode-Tricks
Prüft, ob Null-Byte- und Overlong-Unicode-Kodierungen Eingabefilter umgehen.
Wie: Vergleicht eine Baseline-Sonde mit %00- und %c0%ae-Payloads; Dateisystem-Marker oder ein 404→200-Flip ergeben einen Fund.
Beispiel: ..%c0%ae/etc/passwd liefert root:x:0: → Filter-Bypass.
OAuth-Code-Reuse
Prüft, ob ein Authorization Code zweimal eingelöst werden kann (muss einmalig sein).
Wie: Sendet denselben Sonden-Code zweimal an den Token-Endpunkt; zwei Token-Grants bedeuten wiederverwendbare Codes.
Beispiel: Gleicher Code → zwei Access-Tokens → abgefangener Code stirbt nie.
OTP-Reuse
Prüft, ob ein Einmalcode die erste Verifikation überlebt (muss nach Nutzung verbraucht werden).
Wie: Sendet denselben Code zweimal an verify/OTP-Endpunkte; zwei Erfolge bedeuten wiederverwendbares OTP. Verbrauchte Codes bleiben still.
Beispiel: Gleiche 000000 verifiziert zweimal → abgefangener SMS-Code wiederverwendbar.
Forgery signierter Cookies
Prüft, ob das Session-Cookie clientkontrollierte Daten sind, die auf Admin umgeschrieben werden können.
Wie: Loggt ein, dekodiert ein base64/JSON-Cookie, fälscht role→admin und spielt es auf geschützten Pfaden erneut ab; Admin-Marker nur mit gefälschtem Cookie bedeuten unsigniertes Vertrauen. Opake Tokens bleiben still. Einmal pro Scan.
Beispiel: Gefälschtes Session-Cookie → /profile liefert admin:true → vollständige Übernahme.
Unsichere Deserialisierung
Prüft, ob Request-Daten einen serverseitigen Deserializer erreichen (pickle / Java / PHP).
Wie: Sendet Magic Bytes (pickle, Java STREAM_MAGIC, PHP serialized) in Body-Felder; Deserializer-Fehlermarker sind High. Saubere 400er bleiben still.
Beispiel: Magic Bytes → pickle.UnpicklingError → Pfad zur Remote-Code-Ausführung.
Blind SQL Injection (time-based)
Erkennt SQL-Injection über Antwortzeitunterschiede, nicht nur über Fehlermarker.
Wie: Vergleicht einen Baseline-GET mit einem SLEEP(2)-Payload auf demselben Parameter; Δt über 1,5 s ohne Fehler bedeutet Blind Injection. Einmal pro Scan, 2 Requests.
Beispiel: q=1' AND SLEEP(2)-- - → +2,0 s Verzögerung → High.
OS-/LDAP-Kommando-Marker
Prüft, ob Eingaben eine Shell oder einen Directory-Server erreichen (`;id`, `|whoami`, LDAP-Filter).
Wie: Sendet Befehlsseparatoren und einen LDAP-Filter in Query-Parameter; uid=/gid=-Ausgabe oder LDAP-Exceptions (ohne bloße Reflexion) bedeuten Ausführung. Saubere Echos bleiben still.
Beispiel: host=|whoami → uid=0(root) im Body → High.
HTTP Method-Override-Bypass
Prüft, ob X-HTTP-Method-Override den Request an Methodenprüfungen vorbeileitet.
Wie: Sendet einen Baseline-POST und wiederholt ihn mit X-HTTP-Method-Override: DELETE; ein Fehler→Erfolg-Flip mit anderem Body bedeutet, dass der Override akzeptiert wird.
Beispiel: POST → 405, gleicher POST + Override → 200 deleted:true → Medium.
Verschachteltes Mass Assignment
Testet tiefe Objekt-Binder mit {"user":{"role":"admin"}}-Payloads.
Wie: Sendet einen Baseline-POST und einen verschachtelten role=admin-Body; Admin-Marker nur in der verschachtelten Antwort bedeuten, dass der Binder keine rekursive Allowlist hat.
Beispiel: Verschachteltes role=admin → "role":"admin" reflektiert → Medium.
Actuator-Secret-Werte
Liest /actuator/env, /actuator/configprops und /metrics auf offengelegte Secrets.
Wie: Ruft jeden Pfad einmal pro Scan ab; ein Secret-Schlüsselwort plus ein zitierter Wert (nicht nur Status 200) bedeutet, dass der Actuator Credentials leakt.
Beispiel: /actuator/env → "db.password" mit Wert → High.
PII auf Fehlerseiten
Prüft, ob 4xx-Bodies personenbezogene Daten spiegeln (E-Mails, IBAN, PESEL mit Kontext).
Wie: Fordert einmal pro Scan einen nicht existierenden Pfad an und prüft den Fehler-Body per Regex; Bild-/Static-Endungen ausgeschlossen. Generische Fehler bleiben still.
Beispiel: 404 Traceback → [email protected] → Medium (DSGVO).
Secrets in Sourcemaps
Durchsucht öffentliche *.map-Bundles nach eingebetteten API-Keys und Tokens.
Wie: Ruft gängige Map-Pfade einmal pro Scan ab und wendet den Secret-Pattern-Index auf sourcesContent an; Maps ohne Treffer bleiben still.
Beispiel: main.js.map → AKIA… → High Source-Leak.
Auth-to-RCE-Übernahmekette
Spielt die Kill-Chain oracle-forge-escalate-deserialize end-to-end durch: oracle → forge → escalate → deserialize in einem Lauf.
Wie: Loggt ein, fälscht das Session-Cookie auf Admin, bestätigt, dass das Admin-Panel ihm vertraut, und sendet dann pickle-Magic-Bytes an den Admin-Import; jedes Glied muss bestätigen, sonst bleibt es still. 3 Requests, einmal pro Scan.
Beispiel: Gefälschtes Cookie → /admin vertraut → /admin/import deserialisiert → kritische Full-Chain-Übernahme.
Serverversion → CVE-Lookup
Mappt die gefingerprintete Serverversion auf bekannte CVEs aus einem lokalen NVD-Cache (nächtlich aktualisiert).
Wie: Liest Server / X-Powered-By einmal pro Scan und gleicht Release-Linien mit dem Offline-Index ab; Severity folgt dem CVSS-Score. Unbekannte Stacks bleiben still.
Beispiel: Server: nginx/1.18.0 → CVE-2021-23017 (CVSS 7.7, High).
SCA gebündelter Bibliotheken
Findet veraltete JavaScript-Bibliotheken in Bundles und mappt sie auf CVEs (OSV-Advisories).
Wie: Sammelt Same-Origin-Skripte (max. 4 Requests pro Scan), extrahiert Versionen (jQuery, lodash, React, Vue…) und schlägt jede im Offline-Index nach. Moderne Libs bleiben still.
Beispiel: jQuery 3.4.1 im Bundle → CVE-2020-11022/11023 (XSS).
Batch-IDOR
Prüft, ob Bulk-Endpunkte fremde Objekte ohne Autorisierung pro Datensatz zurückgeben.
Wie: Sendet IDs [1,2,3] an Batch-Felder und vergleicht Owner-Keys (user_id, email…); Objekte von 2+ Ownern in einer Antwort sind ein Fund. Single-Owner-Batches bleiben still.
Beispiel: POST /batch/orders → alice, bob und carol in einem Call → Autorisierung pro Datensatz fehlt.
SMS-Toll-Fraud-Schutz
Prüft, ob Messaging-Endpunkte nicht routbare Nummern akzeptieren (fehlender Premium-Range-Guard).
Wie: Sendet eine fiktive +1555-Nummer, die nie routet oder Kosten verursacht; ein „sent/queued“-Urteil bedeutet keinen Toll-Fraud-Schutz. Abgelehnte Nummern bleiben still.
Beispiel: +15550001111 als gesendet gemeldet → Premium-Nummern werden wahrscheinlich auch berechnet.
Secrets in Responses
Scannt Response-Bodies auf geleakte Keys, Tokens und Kartennummern (AWS, GitHub, Stripe, Slack, PEM, PAN).
Wie: Deterministische Muster über bis zu 5 Antworten pro Scan; Kartennummern brauchen Luhn-Check plus Kontext, Samples werden auf die letzten 4 Zeichen maskiert. Saubere Seiten bleiben still.
Beispiel: ghp_… Token in /page → High; rotieren und entfernen.
security.txt-Disclosure-Policy
Prüft, ob die Site einen security.txt-Kontakt für Forscher veröffentlicht.
Wie: Liest /.well-known/security.txt (Fallback /security.txt), max. 2 Requests pro Scan; eine Datei ohne Contact zählt als fehlend. Veröffentlichte Dateien bleiben still.
Beispiel: Beide Pfade 404 → Low; Contact + Disclosure-Policy ergänzen.
DMARC-Durchsetzung
Prüft, ob die Domain DMARC erzwingt (Anti-Spoofing für Exact-From-Phishing).
Wie: Passiver DNS-TXT-Lookup für _dmarc (null HTTP-Requests); fehlender Record ist Medium, eine Policy ohne reject Low, p=reject bleibt still.
Beispiel: Kein _dmarc-Record → Angreifer können Ihre Domain spoofen.
Certificate-Transparency-Recon
Listet Subdomains, die in öffentlichen Certificate-Transparency-Logs auftauchen.
Wie: Ein Request an crt.sh pro Scan; entdeckte Namen (dev, staging…) werden als Attack-Surface-Inventar gemeldet. Offline oder leer bleibt still.
Beispiel: dev.example.com im CT-Log → prüfen oder abschalten.
Enumeration gängiger Subdomains
Prüft, ob erratbare Namen (www, api, dev, staging, admin…) öffentlich auflösen.
Wie: Nur DNS-A-Lookups (null HTTP-Requests, 10-Namen-Wortliste); auflösende Namen werden als Inventar gemeldet. Nichts auflösend bleibt still.
Beispiel: staging.example.com löst auf → ist es geschützt?
WAF/CDN-Fingerprint
Identifiziert den Edge-Stack (Cloudflare, CloudFront, Akamai…) anhand passiver Marker.
Wie: Ein GET / pro Scan, nur Header- und Cookie-Marker (cf-ray, x-amz-cf-id…); informativ, speist die WAF-Ruleset-Frage im Ask Mode.
Beispiel: Edge: Cloudflare → SSRF-Regeln in der WAF bestätigen.
API-Lifecycle-Header (Sunset)
Prüft, ob versionierte Endpunkte (/v1/…) Deprecation ankündigen.
Wie: Nur versionierte GET-Pfade werden geprüft; fehlende Sunset/Deprecation-Header sind informativ. Angekündigte Lifecycles bleiben still.
Beispiel: /v1/orders ohne Sunset → Risiko veralteter Version.
Secrets in OpenAPI-Beispielen
Scannt veröffentlichte OpenAPI/Swagger-Specs auf echt wirkende Secrets in Beispielwerten.
Wie: Liest openapi.json / swagger.json / api-docs (max. 3 Requests), matcht Key-/Token-Muster; saubere Specs bleiben still.
Beispiel: "example": "ghp_…" in der Spec → Medium; Entwickler kopieren es.
JWT-Algorithmus-Confusion
Prüft, ob der Verifier einen Algorithmus pinnt (RS→HS-Confusion, alg=none mit Signatur, fehlendes aud).
Wie: Auf Endpunkten mit funktionierendem Bearer-JWT: spielt die RS/EC-Signatur unter HS256-Header erneut ab, einen alg=none-Token mit Signatur-Bytes, und flaggt fehlenden aud-Claim. Saubere Verifier bekommen nur den Low-Hinweis zu aud.
Beispiel: RS256-Signatur als HS256 akzeptiert → Tokens mit dem Public Key fälschen.
Session Fixation
Prüft, ob die Session-ID beim Login rotiert wird.
Wie: Nimmt ein sid-Cookie vor dem Login, loggt damit ein und vergleicht: dieselbe sid nach dem Login ist Medium. Rotierte oder abgelehnte Logins bleiben still. Max. 2 Requests pro Scan.
Beispiel: sid=abc vor und nach /login → vom Angreifer platzierte Sessions überleben.
Refresh-Token-Validierung
Prüft, ob der Refresh-Endpunkt Tokens für Müll-Eingaben ausstellt.
Wie: Sendet einen ungültigen refresh_token an Refresh-Endpunkte; ein access_token in einer 200-Antwort ist High. Reuse eines gültigen Tokens braucht ein echtes Token → Ask-Fallback.
Beispiel: Müll-Refresh → 200 mit access_token → Validierung defekt.
PKCE-Downgrade
Prüft, ob der Authorize-Endpunkt Codes ohne PKCE ausstellt.
Wie: Liest openid-configuration und fordert dann authorize ohne code_challenge an (keine Redirects verfolgt); ein Code im Location ist Medium. Keine Discovery bleibt still.
Beispiel: 302 mit ?code= und ohne Challenge → Interception-Risiko für Public Clients.
Logout-Replay
Prüft, ob POST /logout das Token tatsächlich invalidiert.
Wie: Baselined ein funktionierendes Token auf /me, ruft Logout auf und wiederholt: weiterhin 200 ist Medium. Funktioniert nur mit dem scan-provided Token (Ihrem eigenen). Max. 3 Requests.
Beispiel: Token nach Logout lebendig → gestohlene Tokens bleiben nutzbar.
Host-Header-Poisoning
Prüft, ob Reset-/Verify-Links aus dem vom Angreifer gelieferten Host gebaut werden.
Wie: Sendet Host: evil.com und X-Forwarded-Host an Login-/Reset-Endpunkte; der Evil-Host in einem Reset-/Verify-/Token-Link ist High. Max. 2 Requests pro Scan.
Beispiel: Reset-Mail verlinkt auf evil.com → Account-Übernahme.
Auth-Bypass per Magic Header
Prüft, ob Proxy-Trust-Header (X-Forwarded-For, X-Original-URL…) die Autorisierung überspringen.
Wie: Baselined ein funktionierendes Token vs. anonymes 401 und wiederholt dann anonym mit 4 Magic-Headern; ein 200 ist High. Öffentliche Endpunkte bleiben still. Max. 6 Requests.
Beispiel: X-Original-URL anonym → 200 → Gateway-Trust-Bug.
Redirect-Validierungs-Evasionen
Prüft die Redirect-Validierung gegen Backslash- und Whitespace-Tricks.
Wie: Spielt 5 kodierte Payloads (/\, %5c, Tab…) in Redirect-Parameter ein, ohne Redirects zu folgen; Evil-Host im Location ist High. Erweitert den einfachen Open-Redirect-Test.
Beispiel: ?next=%5cevil.com → 302 dorthin → naiver Validator.
Mass Assignment über Query String
Prüft, ob ?role=admin in der Query in privilegierte Felder übergeht.
Wie: Sendet denselben Body zweimal (sauber vs. ?role=admin&isAdmin=true) und vergleicht: neue Admin-Marker nur in der Query-Variante sind High. 2 Requests pro Ziel.
Beispiel: POST /users?role=admin → "role":"admin" in der Antwort.
Fehler-Oracle (403 vs. 404)
Prüft, ob Fehlercodes verraten, welche Objekte existieren.
Wie: Vergleicht IDs gleicher Form (1 vs. 999999999) mit einem Token: ein 403/404-Split ist informativ. Einheitliche Antworten bleiben still.
Beispiel: 403 auf /orders/1, 404 auf /orders/9… → ID-Enumeration.
Sort-/Filter-Injection
Prüft, ob sort/filter-Parameter die Query-Engine erreichen.
Wie: Sondiert ?sort=password und filter[$ne]; ein 500 mit Datenbank-Markern ist Medium. Saubere 200er bleiben still. Max. 3 Requests pro Ziel.
Beispiel: ?sort=password → psycopg SyntaxError → Injection-Oberfläche.
Secret in URL-Query
Flaggt GET-Endpunkte, die Secrets im Query-String tragen.
Wie: Passive Spec-Analyse (null Requests): token/reset_token/session in Query-Parametern ist Medium. Secrets gehören in Header oder Body.
Beispiel: GET /reset?reset_token=… → Medium; Leak über Referer/Logs.
MFA-Flag-Bypass
Prüft, ob der Step-up-Endpunkt einem clientseitigen MFA-Flag vertraut.
Wie: Sendet mfa_passed/mfa_verified-Flags an Verify-Endpunkte (max. 3 Requests); ein Token/Success-Urteil ist Critical.
Beispiel: {"mfa_passed":true} → 200 mit Token → dekoratives 2FA.
OAuth-Scope-/Grant-Audit
Auditiert beworbene Scopes und den Token-Endpunkt auf offene Ausstellung.
Wie: Liest openid-configuration (admin-ähnliche Scopes → Info) und versucht dann client_credentials mit falschem Secret + scope=admin; ein Token ist Critical. Max. 2 Requests.
Beispiel: Falsches Secret → access_token → Credential-Prüfung fehlt.
OTP-Brute-Force-Schutz
Prüft, ob Verify-Endpunkte das Raten drosseln.
Wie: Sendet 5 falsche Codes; jedes 429/Lockout/Cooldown bleibt still, fünf einfache Ablehnungen sind Medium. Max. 5 Requests pro Scan.
Beispiel: 5× falscher Code, kein 429 → 6-stelliger Raum aufzählbar.
MFA-Push-Fatigue-Schutz
Prüft, ob Push-Challenges einen Cooldown haben.
Wie: Sendet 3 Push-Requests direkt hintereinander; Cooldown/429 bleibt still, 3 Akzeptanzen sind Medium. Max. 3 Requests.
Beispiel: 3 Pushes sofort akzeptiert → Fatigue-/Phishing-Risiko.
Step-up-Signal bei sensiblen Aktionen
Flaggt sensible Aktionen (Transfer, Payout, Admin), die mit Tokens ohne amr/acr akzeptiert werden.
Wie: Passive JWT-Claim-Prüfung auf sensiblen POST-Pfaden (null Requests); Tokens mit amr/acr bleiben still. Informatives Hardening-Signal.
Beispiel: POST /transfer ohne amr/acr → Step-up serverseitig prüfen.
SSTI-Sonde
Prüft, ob Template-Ausdrücke serverseitig evaluiert werden.
Wie: Sendet {{7*7}} und ${7*7} in Textfelder; eine nackte 49 ohne Echo ist High. Max. ca. 6 Requests pro Scan.
Beispiel: {{7*7}} → 49 → RCE-nahe Template-Injection.
SSTI-Engine-Fingerprint
Identifiziert die Template-Engine hinter einer SSTI anhand enginespezifischer Syntax.
Wie: Probiert ERB/Ruby/Smarty/Twig-Marker je einmal; Evaluation ist High, die Engine wird im Evidence genannt.
Beispiel: <%= 7*7 %> → 49 → ERB-Fingerprint.
XXE-Sonde
Prüft, ob XML-Eingaben externe Entities auflösen.
Wie: Sendet eine DOCTYPE mit interner Entity-Canary als application/xml; Expansion ist High, Parserfehler-Offenlegung Medium. Max. 2 Requests.
Beispiel: &xxe; → XXE_PROBE in der Antwort → Datei-/SSRF-Risiko.
CRLF-/Header-Injection
Prüft, ob CRLF in Parametern zu einem Response-Header wird.
Wie: Injiziert %0d%0a-Payloads in Query-Parameter; ein X-Scan-Probe-Response-Header ist High. Max. 3 Requests.
Beispiel: Injiziertes CRLF → Response-Header → Splitting-Risiko.
Prototype Pollution
Prüft, ob __proto__/constructor-Keys serverseitig persistieren.
Wie: Sendet verschmutzte Keys und liest das Objekt zurück; der Marker im Read-back ist High. 2 Requests.
Beispiel: __proto__ überlebt bis GET → Object Pollution.
HTTP Parameter Pollution
Prüft, wie der Server doppelte Query-Parameter auflöst.
Wie: Vergleicht Antworten für einzeln vs. doppelt (?id=1&id=2); ein Parserfehler durch das Duplikat ist Low und flaggt manuelle Prüfung der Auth-Pfade.
Beispiel: Duplikat → 500 mit DB-Fehler → Parser-Confusion.
SQL-Dialekt-Fingerprint
Identifiziert die Datenbank-Engine am Fehlertext.
Wie: Sendet einmal pro Scan ein einfaches Quote; ein Dialekt-Marker (psycopg, mysql, sqlite, mssql, oracle, mongodb) ist informativ und steuert Folge-Payloads.
Beispiel: ' → psycopg2.SyntaxError → PostgreSQL.
Second-Order-Injection
Pflanzt einen gespeicherten Marker und prüft, ob er unescaped zurückkommt.
Wie: Schreibt eine Canary mit Quote-/Bracket-Zeichen und liest sie zurück; rohe Sonderzeichen sind Medium. 2 Requests. HTML-escaped Output bleibt still.
Beispiel: Gespeicherte Notiz liefert rohe Quotes → Export-/Admin-Sinks gefährdet.
Type-Juggling-Login
Probiert Nicht-String-Passwörter (true, array, $gt, 0) beim Login.
Wie: Baselined mit falschem Passwort (muss 4xx sein) und sendet dann 4 typisierte Sonden; jeder akzeptierte Login ist High. Max. 5 Requests.
Beispiel: password=true → Token → Loose-Comparison-Auth-Bug.
Batch-Atomizität
Prüft, ob ein Batch mit einer ungültigen Operation abgelehnt oder verschluckt wird.
Wie: Sendet [valid, invalid] in einem Batch (1 Request); volle Akzeptanz ohne Fehler pro Element ist Medium.
Beispiel: Ungültige Operation still absorbiert → Teilausführung.
Replay-Schutz
Prüft, ob Idempotency-Key bei geldbewegenden Endpunkten respektiert wird.
Wie: Sendet zweimal denselben Key (2 Requests); zwei verschiedene Ressourcen-IDs sind High, dieselbe ID bleibt still.
Beispiel: Gleicher Key, zwei Order-IDs → Doppelbelastung.
Cart-/Preis-Manipulation
Prüft, ob clientseitige Geld-Felder vertraut werden.
Wie: Mutiert price/amount/total/qty (max. 3 Requests); ein akzeptierter Preis von 0.01 oder eine -1-qty-nahe Mutation ist High.
Beispiel: price=0.01 akzeptiert → Summen werden nicht neu berechnet.
Coupon erraten
Prüft, ob ein Coupon-String beim ersten Versuch einen Rabatt liefert.
Wie: Sendet coupon=SCAN10 einmal; Rabatt-Marker in der Antwort sind Low.
Beispiel: Erratener Code → Rabatt → Testcodes live.
Sub-Cent-Betrag
Prüft, ob fractional Money normalisiert wird.
Wie: Sendet 0.9999999 einmal; Akzeptanz ohne Fehler ist Low (Rounding-Drift-Oberfläche).
Beispiel: 0.9999999 akzeptiert → Integer-Cents verwenden.
Parallele Duplikate
Sendet zwei identische Mutationen parallel in Use-once-Flows.
Wie: Zwei parallele POSTs (2 Requests); Erfolg beider ist Low und flaggt ein TOCTOU-Review (Locks/Idempotenz).
Beispiel: Doppelte Einlösung akzeptiert → Atomicity-Review.
Negative Beträge
Prüft, ob negative qty/amount abgelehnt wird.
Wie: Sendet -1 und -5 (max. 2 Requests); Akzeptanz ist High (Refund-/Credit-Vektor).
Beispiel: qty=-1 akzeptiert → Credit-Manipulation.
Währungs-Swap
Prüft, ob ein falscher Währungscode ungeprüft akzeptiert wird.
Wie: Sendet currency=XXX/xxx (max. 2 Requests); Akzeptanz ist Medium.
Beispiel: XXX akzeptiert → ISO-4217-Allowlist.
Versand-Manipulation
Prüft, ob eine clientseitig gewählte Methode die Versandgebühr auf null setzt.
Wie: Sendet shipping_method=pickup einmal; eine Gebühr von null in der Antwort ist Low.
Beispiel: Client-Methode → Versand 0 → Server-Preistabellen.
CSV-Formel im Export
Prüft Export-Endpunkte auf unescaped formelführende Zellen.
Wie: Fordert CSV einmal an; Zellen, die mit =/+/-/@ beginnen, sind Medium (Spreadsheet-Injection am Sink).
Beispiel: =1+1 im Export → Sinks sanitisieren.
Integer-Grenze
Sondiert numerische Felder mit 32-Bit-Grenzwerten.
Wie: Sendet 2^31 und -(2^31)-1 (max. 2 Requests); ein 500 oder stille Akzeptanz ist Low.
Beispiel: 2^31 → 500 → Overflow-Oberfläche.
Toleranz unbekannter Felder
Prüft, ob Schreibpfade unbekannte Felder ablehnen.
Wie: Fügt ein Extra-Feld hinzu (1 Request); Akzeptanz ist informativ (Drift-/Mass-Assignment-Oberfläche).
Beispiel: Extra-Feld 2xx → strikte Schemas?
Erreichbare Legacy-Version
Prüft, ob /v{n-1} neben /v{n} antwortet.
Wie: Fordert den Legacy-Pfad einmal an; ein 2xx ist Low (Legacy-Auth-/Validierungslücken).
Beispiel: /v1 lebt neben /v2 → abschalten oder backporten.
Workflow-Status überspringen
Versucht, einen terminalen Workflow-Status direkt zu setzen.
Wie: Sendet status=completed/approved (max. 2 Requests); Akzeptanz ist Medium — Übergänge müssen serverseitig gesteuert werden.
Beispiel: status=completed akzeptiert → Übergänge absichern.
UUID-IDOR + Vorhersagbarkeit
Tauscht eine UUID im Pfad gegen eine Null-UUID und vergleicht Objekte.
Wie: Baseline 200, dann alternative UUID (max. 3 Requests); ein anderes Objekt bei 200 ist High — UUIDs sind Identifikatoren, keine Capabilities.
Beispiel: Fremde UUID → 200 mit Daten → fehlende Autorisierung.
Request-Smuggling-Form
Prüft, ob ein Body trotz Content-Length: 0 verarbeitet wird.
Wie: Sendet einen Body mit CL:0 einmal; reflektierte Verarbeitung ist Medium und flaggt eine Raw-Socket-Bestätigung (CL/TE-Desync).
Beispiel: Body mit CL:0 verarbeitet → Desync-Oberfläche.
Subdomain-Takeover-Fingerprint
Prüft die Root-Antwort auf Dangling-Host-Fingerprints.
Wie: Ein GET / pro Scan; 404/410 mit GitHub-Pages/S3/Heroku-Markern ist High — CNAME prüfen.
Beispiel: Dangling-CNAME-Marker → DNS zurückholen.
TLS-Konfiguration (HSTS + Ablauf)
Prüft HSTS auf HTTPS und Zertifikatsablauf.
Wie: Fehlendes HSTS ist Low; ein in 30 Tagen ablaufendes Zertifikat ist Medium (Best-Effort-Socket-Check, offline-sicher).
Beispiel: Kein HSTS → SSL-Stripping-Oberfläche.
Path Confusion
Probiert /../, //, Case-, Trailing-Slash- und Semikolon-Varianten geschützter Pfade.
Wie: Baselined einen 401/403/404-Pfad, dann 6 Varianten; jedes 200 ist High (Normalisierungs-Split zwischen Gateway/Auth).
Beispiel: //ADMIN → 200 → vor Auth normalisieren.
Double-Encoding-Bypass
Probiert %252e-, %c0%ae- und Unicode-Slash-Pfade.
Wie: Drei kodierte Sonden pro Scan; ein 200 ist High — Autorisierung läuft auf der Rohform.
Beispiel: %252e%252e → 200 → Decode-then-Authorize.
WAF-Repräsentations-Bypass
Spielt einen WAF-blockierten Angriff mit Repräsentations-Tweak erneut ab.
Wie: Baselined ein 403 mit WAF-Markern, dann Percent-/Case-Varianten (max. 3 Requests); ein 200 ist High.
Beispiel: Gleicher Payload passiert kodiert → an der WAF normalisieren.
WebSocket-Handshake-Auth
Prüft, ob WS-Endpunkte ohne Credentials upgraden.
Wie: Sendet einen WS-Handshake an Hint-Pfade plus /ws und /socket (max. 2 erreicht); ein 101 ist Medium — Origin + Auth prüfen.
Beispiel: 101 ohne Token → Handshake-Auth-Review.
gRPC-Oberfläche + verbose Fehler
Sondiert gRPC-Framing und reflection-förmige Fehler.
Wie: Sendet einen reflection-förmigen Frame mit application/grpc (max. 2 Requests); grpc-status ist Info, Stack-/SQL-Offenlegung Medium.
Beispiel: grpc-status + Traceback → generische Meldungen.
GraphQL-Alias-Overloading
Prüft, ob 200 aliasierte Felder inline beantwortet werden.
Wie: Eine aliasierte __typename-Query; 100+ Inline-Antworten sind Medium (CPU/DoS — getrennt von Depth-Limits).
Beispiel: 200 Aliase inline → Feldanzahl begrenzen.
Cache Poisoning (unkeyed Input)
Prüft, ob nicht-gekeyte Header in gecachten Antworten landen.
Wie: Sendet X-Forwarded-Host/UA-Canary, dann einen sauberen Request (max. 3); HIT mit Reflexion ist High, Persistenz zum zweiten Client Medium.
Beispiel: Evil-Host gecacht → Caches sicher keyen.
Private-Network-Access-Policy
Prüft, ob Allow-Private-Network breit gewährt wird.
Wie: Ein Preflight mit öffentlichem Origin; ein true-Grant ist informativ — auf Allowlist begrenzen.
Beispiel: PNA true für beliebigen Origin → allowlisten.
Cookie-Domain-Scope
Flaggt Cookie-Domains mit führendem Punkt oder Suffix-Breite.
Wie: Eine passive Set-Cookie-Inspektion pro Scan; breiter Scope ist Low — auf exakten Host pinnen.
Beispiel: Domain=.example.com → Subdomain-Sharing.
Upload-Polyglot / Traversal-Zip
Lädt Double-Extension-, scriptable-SVG- und Traversal-Zip-Sonden hoch.
Wie: Drei inerte Uploads (shell.php.jpg, SVG mit onload, Zip mit ../../-Eintrag); Akzeptanz ohne Ablehnung ist Medium (Low für das Zip, da Extraktion nicht bestätigt). Max. 3 Requests.
Beispiel: shell.php.jpg gespeichert → Typen sniffen + sandboxen.
Stored XSS über API
Pflanzt scriptable Markup und prüft den Read-back.
Wie: Schreibt eine SVG-onload-Canary und GETet das Objekt (2 Requests); rohe Rückgabe ist High, escaped Output bleibt still.
Beispiel: Rohes <svg onload> im GET → Sinks enkodieren + CSP.
Content-Type-Confusion
Spielt einen JSON-Body als Form und XML auf demselben Endpunkt erneut ab.
Wie: Zwei Requests mit alternativem Content-Type pro Scan; ein Success-Urteil ist Medium (Parser-/Validierungs-Split).
Beispiel: Form-Body 2xx auf JSON-Endpunkt → ein Parser.
EICAR-Upload (AV-Check)
Lädt die inerte EICAR-Testsignatur an Datei-Endpunkte hoch.
Wie: Ein Upload pro Scan; ein Malware-/Quarantäne-Urteil bleibt still (gut), Speicherung ohne Urteil ist Low.
Beispiel: EICAR still gespeichert → Uploads scannen.
PII in URL-Pfad / Redirect
Flaggt E-Mails, PESEL-Formen und Secrets in Pfaden und Locations.
Wie: Passive Pfadprüfung plus eine Redirect-Inspektion (follow_redirects=False); ein Treffer ist Medium — Identifikatoren in Header/Body verschieben.
Beispiel: /users/[email protected] → opake IDs verwenden.
Open-Proxy-Relay
Prüft, ob ?url=/redirect-Parameter fremde Hosts ausliefern.
Wie: Richtet Relay-Parameter auf einen nicht routbaren Evil-Host (max. 2 Requests); ein Redirect dorthin ist Medium, ein serverseitiger Fetch High.
Beispiel: ?url=evil → 302 dorthin → C2-Relay-Form.
SSRF über Feature (Error Oracle)
Prüft, ob Webhook-/Import-Funktionen beliebige URLs abrufen.
Wie: Übergibt eine Dead-Host-URL (max. 2 Requests); ein Fetch-Versuchsfehler (DNS/Socket-Text) ist Medium — kein Listener nötig.
Beispiel: getaddrinfo-Canary → Egress bestätigt.
Callback-Kanal-Validierung
Prüft, ob fremde Callback-Domains akzeptiert werden.
Wie: Registriert eine Canary-Callback einmal pro Scan; Akzeptanz ist Low und flaggt eine Listener-Bestätigung im Hacker Mode (N2/S9).
Beispiel: Evil-Callback gespeichert → DNS-Exfil-Form.
Presigned-URL-TTL und Scope
Flaggt ewige oder wildcard-weite Signed URLs.
Wie: Passive Spec-Analyse (null Requests): Ablauf über 7 Tage oder Wildcard-Scope ist Medium.
Beispiel: se=+30d → TTL pro Link verkürzen.
Unbegrenzter Export
Flaggt riesige ungepagte Listen-/Export-Antworten.
Wie: Ein GET pro Kandidat; Bodies über 500 KB ohne Paging-Marker (Head und Tail) sind Low — paginieren und begrenzen.
Beispiel: 546-KB-Flatlist → Bulk-Exfil-Form.
Dateilesen über LOL-Endpoint
Prüft, ob Export-/Preview-Funktionen außerhalb ihres Verzeichnisses lesen.
Wie: Sendet Traversal- und file://-Sonden an Feature-Parameter (max. 2 Requests); /etc/passwd-Marker sind High.
Beispiel: LFI: /preview?path=…/passwd → root:x: → Dateilesen.
Anonymer Dead-Drop
Prüft, ob anonyme Schreibvorgänge anonym lesbar sind.
Wie: Schreibt eine Canary anonym und liest sie anonym zurück (2 Requests); ein Match ist Medium.
Beispiel: Anonyme Notiz lesbar → Dead-Drop für Angreifer.
Webhook Confused Deputy
Prüft, ob Intranet-Webhook-URLs bei der Registrierung akzeptiert werden.
Wie: Registriert Loopback- und Dead-Host-URLs (max. 2 Requests); Akzeptanz ist Medium — Allowlist bei Registrierung.
Beispiel: http://127.0.0.1:9 gespeichert → Deputy-SSRF.
JWT-kid-Traversal / jku-Fetch
Sondiert kid-Path-Traversal und jku-Fetch über Fehler-Oracle.
Wie: Sendet alg=none-Tokens mit ../../-kid und Dead-Host-jku beim Login (max. 2 Requests); Dateisystem-/Netzwerkfehler sind Medium.
Beispiel: ENOENT bei kid → Sink bestätigt.
Cache Deception (auth vs. anon)
Vergleicht eine authentifizierte Antwort mit einer anonymen auf Cachebarkeit.
Wie: Ruft dieselbe URL mit und ohne Credentials ab (2 Requests); identische PII-Bodies plus HIT-Marker sind High. Braucht Auth-Kontext, sonst übersprungen.
Beispiel: Anonym bekommt /me aus dem Cache → Nutzerdaten öffentlich.
Cache-Key-Confusion (Host)
Prüft, ob ein gespoofter Host im Shared Cache landet.
Wie: Sendet Host/X-Forwarded-Host evil, dann einen sauberen Request (max. 3); Reflexion in einem HIT ist High, Persistenz zum sauberen Client Medium.
Beispiel: Evil-Host gecacht → vergiftet andere.
CORS-Cache-Poisoning
Prüft, ob ein reflektierter Angreifer-Origin gecacht wird.
Wie: Sendet Origin evil, dann einen sauberen Request (max. 3); reflektiertes ACAO in einem HIT ist High, Persistenz Medium.
Beispiel: Evil-ACAO gecacht → CORS-Vergiftung des Opfers.
Throttle-Signal bei schnellem Paar
Prüft, ob schnelle Requests irgendein Throttling-Signal zeigen.
Wie: Zwei schnelle GETs pro Scan; ein 429 bleibt still (gut), kein Counter und kein 429 ist Low und flaggt ein Boundary-Burst-Review.
Beispiel: Kein 429, keine Counter → Limits prüfen.
Redirect- + CORS-Kombi
Prüft, ob ein fremder Redirect auch ein vertrauenswürdiges CORS-Grant trägt.
Wie: Richtet einen Relay-Parameter auf einen Evil-Host mit Evil-Origin (max. 2 Requests); 302 dorthin plus reflektiertes ACAO ist Medium.
Beispiel: 302 evil + ACAO evil → Phishing-Kombi.
OAuth Device Flow
Prüft, ob ein Device-Code-Poll Tokens ohne Genehmigung ausstellt.
Wie: Liest Discovery (Endpoint beworben → Info) und pollt dann mit fabriziertem Code (max. 2 Requests); ein Token ist High.
Beispiel: Fake device_code → Token → Approval binden.
OAuth state/nonce erforderlich
Prüft, ob authorize Codes ohne state ausstellt.
Wie: Ruft authorize ohne state/nonce auf (max. 2 Requests); ein Code ohne zurückgegebenen state ist Medium.
Beispiel: Code ohne state → Login-CSRF-Oberfläche.
JWT-x5c-Vertrauen
Prüft, ob ein selbst geliefertes x5c-Zertifikat vertraut wird.
Wie: Sendet ein Login-Token mit Angreifer-x5c (1 Request); Akzeptanz ist High — Keys serverseitig pinnen.
Beispiel: Eigenes Cert akzeptiert → Key-Confusion.
JWE-/Plaintext-Confusion
Prüft, ob eine unsignierte Plaintext-Tokenform akzeptiert wird.
Wie: Sendet ein alg:dir-Plaintext-Token beim Login (1 Request); Akzeptanz ist High.
Beispiel: Unsignierte Form passiert → ein Token-Typ.
DPoP-Downgrade
Prüft, ob DPoP-gehintete Pfade einen einfachen Bearer akzeptieren.
Wie: Fordert einen dpop-Pfad ohne DPoP-Proof an (1 Request); ein 200 ist Medium.
Beispiel: Kein Proof, 200 → Bindung erzwingen.
Ewiges Session-Cookie
Flaggt Session-/Auth-Cookies, die monatelang gültig sind.
Wie: Eine passive Set-Cookie-Inspektion pro Scan; Max-Age über 90 Tage ist Low — mit Step-up-Re-Auth verkürzen.
Beispiel: Max-Age 10 Jahre → Sessions rotieren.
Presigned-URL-Methoden-Reuse
Prüft, ob eine Signatur mit einer anderen HTTP-Methode funktioniert.
Wie: Spielt eine Sig-URL mit der Gegenmethode erneut ab (max. 2 Requests); Erfolg ist High — Methode+Pfad+Ablauf binden.
Beispiel: GET-Sig funktioniert als POST → binden.
Tiefes JSON-Nesting
Sendet einmal pro Scan einen 100-Ebenen-tiefen JSON-Body.
Wie: Ein 500 ist Medium, ein langsames 2xx (>5 s) Low; schnelle Ablehnungen bleiben still. Kleiner Body, große Form.
Beispiel: Nesting → 500 → Depth begrenzen.
Schema-/Boundary-Fuzz
Mutiert ein Textfeld mit Typ-Swaps und Grenzwerten.
Wie: Fünf Sonden (2^63, bool, null, 10k-String, 5k-Array); ein 500 mit Internals oder stille Akzeptanz des falschen Typs ist Low.
Beispiel: bool für String 2xx → strikte Typen.
GraphQL-Suggestion-Leak
Prüft, ob ein Tippfehler Feldsuggestions auslöst.
Wie: Eine falsch geschriebene Query; didYouMean/Passwort-Hinweise sind informativ — Suggestions in Prod deaktivieren.
Beispiel: Tippfehler → „meinten Sie password?“.
Persisted-Query-Auth-Bypass
Prüft, ob ein gespeicherter Query-Hash anonym antwortet.
Wie: Sendet einen APQ-sha256-Hash ohne Credentials (max. 2 Requests); Daten ohne Fehler sind Medium.
Beispiel: Hash → Daten ohne Auth → Hashes absichern.
WAF-Evasion (3 Repräsentationen)
Spielt einen blockierten XSS-Payload doppelt kodiert und case-mutiert erneut ab.
Wie: Baselined ein 403 mit WAF-Markern, dann zwei mutierte Replays (max. 4 Requests); ein reflektiertes 200 ist High.
Beispiel: Gleicher Payload passiert kodiert → normalisieren.
Framework-Mass-Assignment
Probiert Rails-/Laravel-/Django-Binder-Formen (Brackets, _method, __dict__).
Wie: Drei Mutanten pro Scan; Privileg-Marker in der Antwort sind Medium.
Beispiel: user[admin] → admin:true → Binder absichern.
Cursor-Manipulation
Prüft, ob ein fremder/negativer Cursor Daten zurückgibt.
Wie: Vergleicht eine Baseline-Seite mit cursor=-1 (2 Requests); abweichende Daten sind Low — Cursor signieren und scopen.
Beispiel: cursor=-1 → andere Zeilen → opake Cursor.
Kontrolle des Mail-Empfängers
Prüft, ob der Mail-Empfänger aus der Eingabe stammt.
Wie: Injiziert eine Evil-Adresse (max. 2 Requests); ein Echo oder Blind-Versand ist Medium, ein fester Empfänger bleibt still.
Beispiel: To: aus Input → allowlisten.
Token in externer URL / Fehler
Flaggt Tokens, die in externen Links oder Fehlerseiten eingebettet sind.
Wie: Prüft eine normale Seite plus eine 404 mit Token-Sonde (max. 2 Requests); token-tragende hrefs sind Medium, Fehler-Echos Low.
Beispiel: href mit ?token= → Referer-Leak.
Invite-Code-Enumeration
Probiert Invite-/Referral-Codes beim ersten Versuch.
Wie: Sendet 000000/123456/invite-1/test (max. 4 Requests); ein Validierungs-Urteil ist Medium.
Beispiel: 000000 gültig → Entropie + Ablauf.
Offener Storage-Bucket
Prüft, ob Bucket-URLs aus API-Bodies anonym listen.
Wie: Extrahiert S3/GCS/Azure-URLs aus einer Seite und ruft eine anonym ab (max. 2 Requests); ein Listing ist Medium.
Beispiel: S3-URL → ListBucketResult → schließen.
Password-Spray-Signal
Prüft, ob Cross-Account-Raten beobachtbar ist.
Wie: Probiert ein Passwort bei drei Usern (3 Requests); einfache Ablehnungen ohne 429/CAPTCHA sind Low.
Beispiel: Kein Spray-Signal → Velocity-Checks.
Versionsaushandlung
Prüft, ob Legacy-Versionen über Header antworten.
Wie: Vergleicht Baseline mit X-API-Version:1-Request (2 Requests); ein abweichendes 200 ist Low.
Beispiel: v1 per Header → abschalten.
Cookie-Tossing-Form
Flaggt Session-Cookies ohne __Host--Präfix.
Wie: Eine passive Set-Cookie-Inspektion pro Scan; ein Session-Cookie ohne Präfix ist Low — Subdomains könnten es platzieren.
Beispiel: sess ohne __Host- → Präfix setzen.
Tenant-Header-Replay
Prüft, ob Client-Tenant-Header den Datenzugriff steuern.
Wie: Spielt einen Request mit getauschtem X-Tenant-ID/X-Org-ID erneut ab (max. 2 Requests); andere Daten beim selben Token sind Medium — vollständiges Cross-Token-Replay ist eine Hacker-Mission.
Beispiel: Header eines anderen Tenants leakt fremde Zeilen → Tenant serverseitig ableiten.
Token-Claims-Hygiene
Flaggt Scan-Tokens ohne Ablauf oder Audience.
Wie: Null Requests: dekodiert das Scan-Bearer-JWT; fehlendes exp ist Medium, fehlendes aud Low — Cross-API-Replay braucht eine zweite API (Hacker Mode).
Beispiel: Kein exp/aud → kurze TTL + gepinnte Audience.
Attack-Path-Chaining
Verkettet Findings über Kill-Chain-Stufen im Report.
Wie: Null Requests: die Engine gruppiert Findings (Auth-Bypass → Datenzugriff → Exfil) und gibt eine informative Kette aus — Input für den TTP-Graph.
Beispiel: Juggling → Export → Head der Kette fixen.
Hacker mode (AI) — autonomer Pentest im menschlichen Stil
Destruktiver autorisierter Test — nur Dev/Staging, niemals Produktion. Verifizierte Domain erforderlich (localhost und private IPs ausgenommen).
Planen & überarbeiten: Das LLM führt einen expliziten Angriffsplan (IDOR → Eskalation → Secrets → Injections) und überarbeitet ihn, während es lernt — Sie sehen den Plan und jede Revision im Scan-Bericht.
Sondieren & anpassen: Der Agent sendet Anfragen, liest redigierte Antwortausschnitte und korrigiert sich nach Blockaden (401/404/429) — einschließlich eigenem Exploit-Code in einer eingeschränkten Sandbox (15 s Timeout, 30 Anfragen, kein Systemzugriff).
Ketten-Playbooks: Richten Sie ihn auf Cookies, Sessions oder Orakel und er führt die Kette Orakel → Fälschung → Eskalation aus (Timing-Orakel → Session-Cookie dekodieren → Rolle→Admin fälschen → auf geschützten Endpunkten bestätigen), wobei Deserialisierung nur über Fehlermarker bestätigt wird — niemals RCE-Payloads. Business-Logic-Missionen funktionieren genauso: Preis-/Coupon-/Mengenmissbrauch, Race/Double-Spend, Toll-Fraud (nur fiktive Zahlen), indirekte Prompt-Injection-Canaries, Stored-Value-Schleifen und Modell-Extraktions-Treue — jeweils mit in den Plan eingebauten Sicherheitsregeln.
Geführte Ziele: Richten Sie ihn auf „prüfe /users auf IDOR“ oder „versuche zu Admin zu eskalieren“; mit gespeicherten Zugangsdaten testet er authentifizierte Zugriffskontrolle (Ihre Daten vs. die eines anderen Benutzers).
Privacy by Design: Das Modell sieht ausschließlich anonymisierte relative Pfade, Status und Ausschnitte — niemals Ihre URLs oder Zugangsdaten. Anfragen laufen serverseitig mit Auth außerhalb des Modellkontexts.
Urteil: Die Session endet mit einer KI-Bewertung (Risikostufe, Narration des Testverlaufs, Empfehlungen) plus jedem Schritt im Scan-Bericht.
KI-Schicht — Payloads, Triage, Interpretation
Intelligente Payloads
Vor dem Scan liest das LLM Ihre OpenAPI-Shapes und erzeugt passende Payloads pro Endpunkt (IDs, zusätzliche Felder, Injections) — die deterministische Engine feuert sie dann ab. Kein Key oder Ausfall? Die Engine fällt auf integrierte Defaults zurück.
Triage & Urteile
Jeder Fund erhält eine KI-Zweitmeinung (Severity-Vorschlag, False-Positive-Flag, Priorität). Ergebnisse werden pro Fundsignatur gecacht und durch ein Token-Budget pro Scan begrenzt — der deterministische Kern funktioniert immer ohne KI.
Agent-Erkennung
Ein LLM-gesteuerter Browser-Agent (Playwright) durchsucht die Website wie ein Mensch, schlägt zusätzliche Sondierungspfade vor und speist entdeckte Endpunkte in den Scan ein — auch ohne OpenAPI.
Ask mode — 320 Sicherheitsfragen zu Ihrem Code (SaaS+)
Der Scanner sieht Ihren Code nie — daher fragt Ask mode Sie (oder Ihren Coding-Assistenten): 270 prüfbare Fragen zu Authentifizierung, Autorisierung, Eingabevalidierung, Datenschutz, Geschäftslogik, Tenant-Isolation, Sessions, API-Design, Logging, Supply Chain und SDLC — jeweils mit Severity (critical → low) und Hinweis zur Verifikation des Fixes. Die KI ergänzt passende Folgefragen für Ihre Endpunkte und bohrt bei fehlgeschlagenen Antworten über mehrere Runden nach. Antworten Sie pass / fail / n/a mit Datei- und Funktionsnachweis, gaten Sie CI auf dem Ergebnis und exportieren Sie einen Markdown-Bericht.
Starten Sie es über die CLI (liveapisec ask) oder den Fragebogen im Dashboard — kein Quellcode verlässt jemals Ihren Rechner.
Alles Weitere rund um die Tests
Erkennung & Drift
Automatische Endpunkt-Erkennung (OpenAPI-Auto-Erkennung, JS-Bundles, Sitemaps, KI-Sondierungspfade) plus Drift-Erkennung zwischen Scans (Regressionen, behoben, neue High/Critical, Änderungen des Konfigurations-Fingerprints) — und ein CI-Verdict-Endpunkt, der nur bei neuen Funden gegenüber der Baseline fehlschlägt.
Risikobasierte Priorisierung (KEV + EPSS)
Jeder Fund trägt CVE-IDs, ein CISA-Known-Exploited-Flag (automatisch erhöhte Severity, nur im Panel — nie auf der öffentlichen Trust Page), den EPSS-Exploitability-Score und einen Risikoscore (0,55·Severity + 0,30·CVSS + 0,15·EPSS·10). Die Findings-API unterstützt ?sort=risk, damit die am besten ausnutzbaren Probleme zuerst erscheinen. Feeds aktualisieren sich nächtlich; Scans lesen immer den lokalen Cache und warten nie auf das Netzwerk.
Externe Tools & Compliance
Optionale ZAP- und Nuclei-Integrationen speisen zusätzliche Funde in denselben Bericht; jeder offene Fund wird in der Compliance-Ansicht auf PCI DSS 4.0, SOC 2, ISO 27001, GDPR und NIS2 gemappt.