auth-header-trust-rules

Ein kleines Semgrep-Regelpaket, das Code erkennt, der Authentifizierungs-, Autorisierungs- oder Vertrauensentscheidungen auf Basis von HTTP-Request-Headern trifft, die ein Angreifer kontrollieren kann.

Das kanonische Beispiel für diese Schwachstellenklasse ist CVE-2025-29927: Next.js vertraute dem x-middleware-subrequest-Header, um zu entscheiden, ob Middleware ausgeführt wurde – und jede eingehende Anfrage mit einem manipulierten Wert konnte die Middleware vollständig umgehen. Dieses Muster tritt in verschiedenen Frameworks und Ökosystemen immer wieder auf.

Dieses Paket enthält Regeln für zwei Sprachfamilien und drei Unterklassen des Bugs. Es ist als Code-Review-Hilfe gedacht, nicht als vollständig abgestimmte CI-Absicherung. Die Regeln legen Wert auf hohe Erkennungsrate (Recall) statt Präzision und werden am besten interaktiv ausgeführt, wobei ein Mensch über jeden Fund entscheidet.

Eine ausführlichere Beschreibung der Schwachstellenklasse und der Designentscheidungen hinter diesem Paket finden Sie unter bk-security.github.io.

Regelbestand

Schnellstart

Semgrep installieren:

pip install semgrep

Das Paket gegen ein Ziel ausführen:

semgrep --config /path/to/auth-header-trust-rules/rules /path/to/target

Oder eine einzelne Regel ausführen:

semgrep --config /path/to/auth-header-trust-rules/rules/nodejs/header-flag-auth-bypass.yaml /path/to/target

Die Regeln gegen die mitgelieferten Testfixtures validieren:

semgrep --test --config rules/ tests/

Erwartete Ausgabe:

6/6: ✓ All tests passed

Was die Regeln erkennen und was nicht

Die Regeln gleichen eine kuratierte Liste von Headernamen ab, die bekanntermaßen gefährlich sind, wenn man ihnen vertraut. Sie werden die häufigen Fälle erkennen. Sie werden jedoch nicht erkennen:

• Frameworks, bei denen der Header-Lesezugriff in einer Hilfsfunktion versteckt ist, deren Name die Header-Zeichenfolge nicht enthält. Ein benutzerdefinierter Helfer wie getInternalFlag(req), der x-some-novel-name liest, wird nicht erfasst.
• Headernamen, die nicht auf der kuratierten Liste stehen. Die Klasse CVE-2025-29927 kann grundsätzlich jeden Headernamen verwenden; wir legen Wert auf Erkennungsrate durch Muster wie x-internal-*, x-trust-* und x-bypass-*, aber neue Namen werden durchschlüpfen.
• Auth-Entscheidungen auf Basis von Cookies, Query-Parametern oder Request-Body-Feldern. Dies sind zwar dieselbe Schwachstellenklasse, erfordern aber eigene Regeln.
• Auth-Entscheidungen auf Basis des Fehlens eines Headers. Manche Anwendungen überspringen Auth-Prüfungen, wenn ein Header nicht vorhanden ist (ein falsch konfiguriertes Allowlist-Muster). Die aktuellen Regeln erkennen das Vorhandensein und die Verwendung, nicht das Fehlen.

Wenn das Paket für eine bestimmte Codebasis erweitert wird, sind die wertvollsten Ergänzungen in der Regel frameworkspezifische Helfer-Funktionsmuster. Wenn eine Codebasis einen Helfer isInternalRequest(req) hat, ist die Regel, die ihn erfasst, eine einzige Zeile YAML.

Hinzufügen einer Regel

1. Erstellen Sie die Regel unter rules/<lang>/<name>.yaml.
2. Erstellen Sie ein Testfixture unter tests/<lang>/<name>.<ext> mit positiven Beispielen, die mit # ruleid: <rule-id> gekennzeichnet sind, und negativen Beispielen, die mit # ok: <rule-id> gekennzeichnet sind.
3. Führen Sie semgrep --test --config rules/ tests/ aus. Die neue Regel und das Fixture werden automatisch erkannt; Tests müssen bestanden sein, bevor eine Änderung eingereicht wird.

Lizenz

MIT.

Autor

Bruce Kang. Der Quellcode des Begleitblogbeitrags befindet sich unter bk-security.github.io.