Beim Test einer Webanwendung stieß ich auf eine interessante Diskrepanz zwischen WAF und Backend. Die WAF blockierte Anfragen mit einem bestimmten Authentifizierungs-Header. Intern war die Regel als einfacher String-Vergleich gegen das erste Vorkommen von X-Custom-Auth umgesetzt.
HTTP-Header müssen nicht nur einmal vorkommen. Viele Server und Frameworks erlauben doppelte Header und wenden eigene Logik an, welcher Wert gilt: manche verketten, manche behalten den ersten Wert, manche bevorzugen den letzten.
Hier prüfte die WAF nur die erste Header-Instanz, während das Backend-Framework den letzten Wert verwendete. Dadurch entstand eine Lücke zwischen dem, was die WAF glaubte, und dem, wie die Anwendung die Anfrage wirklich interpretierte.
Zum Test habe ich zwei Header gesendet:
X-Custom-Auth: test | X-Custom-Auth: real-auth-tokenDie WAF sah den ersten Wert, hielt ihn für harmlos und ließ die Anfrage durch. Der Anwendungsserver nutzte dann den zweiten Headerwert als gültiges Auth-Token.
Das ist kein neues Thema, aber ein guter Reminder: Sicherheitskontrollen hängen oft daran, dass mehrere Schichten eine Anfrage konsistent parsen. Wenn die Schichten unterschiedlich interpretieren, sind Umgehungen möglich.
Ich nenne das Produkt absichtlich nicht — das Problem ist generisch und taucht in verschiedenen Implementierungen auf.
Für die Verteidigung gilt im Kern:
- Header vor der Inspektion normalisieren.
- Klares Verhalten für doppelte Header definieren.
- Sicherheitsschicht und Anwendungsframework auf dieselbe Interpretation trimmen.
Anzunehmen, ein Header komme nur einmal vor, ist bequem aber unsicher. HTTP erlaubt Duplikate — und genau dort testen Angreifer.