HTTP Method Tampering

Warum es wichtig ist

Zugriffskontrollen bewachen oft nur die Türen, von denen Entwickler erwarten, dass Angreifer sie nutzen. Eine Login-Wand vor GET und POST kann HEAD, OPTIONS, PUT und TRACE weit offen lassen, und ein Angreifer, der einfach das Verb wechselt, spaziert geradewegs hinein. Weil die Kontrolle in einem normalen Browser, in dem jeder Request ein GET oder ein POST ist, weiterhin korrekt aussieht, kann dieser Fehler in der Produktion jahrelang überleben.

HTTP Method Tampering ist eine Lehrbuchform von Broken Access Control, dem Risiko Nummer eins in den OWASP Top 10, und es ist trivial zu testen, sobald du einen Request mit einem Proxy wie Burp Suite abfängst.

Wie es funktioniert

Eine geschützte Admin-Ressource gibt im Browser 401 zurück. Der Tester fängt den Request ab und sendet ihn mit verschiedenen Methoden erneut, ohne sonst etwas zu ändern:

GET     /admin   ->  401 Unauthorized
POST    /admin   ->  401 Unauthorized
HEAD    /admin   ->  200 OK
OPTIONS /admin   ->  200 OK

Das 200 bei HEAD bedeutet, dass der Server den Request als gültig verarbeitet hat. Die zugrunde liegende Fehlkonfiguration sieht meist wie ein Apache-Block aus, der nur zwei Methoden auflistet:

<Limit GET POST>
  require valid-user
</Limit>

Alles, was nicht benannt ist, HEAD, OPTIONS, TRACE und PUT, überspringt die Authentifizierungsprüfung vollständig. Eine verwandte Variante missbraucht Frameworks, die eine unerwartete Methode an denselben Handler routen, aber einen anderen, schwächeren Autorisierungspfad anwenden.

Warum es fortbesteht

Der Bug überlebt, weil Entwickler über die zwei Methoden nachdenken, die ein Browser tatsächlich nutzt, und den Rest der HTTP-Spezifikation vergessen. Eine Allow-List fühlt sich sicher an, doch jede Methode, die von der Liste fehlt, erbt keinen Schutz. Load Balancer, alte mod_auth-Regeln und kopierte Konfigurationsschnipsel verbreiten dasselbe Muster über viele Anwendungen hinweg.

Wie du darauf testest

Sende für jeden geschützten Endpunkt den Request über den vollständigen Methodensatz erneut: GET, POST, PUT, DELETE, HEAD, OPTIONS, PATCH und TRACE. Achte auf jede Methode, die einen 200 oder einen abweichenden Body zurückgibt, und vergleiche Statuscodes sorgfältig, denn ein 405 ist gesund, während ein 200 bei einem unerwarteten Verb ein Fund ist. Beliebige oder erfundene Methoden offenbaren manchmal eine noch lockerere Behandlung.

Prävention

Erzwinge die Autorisierung standardmäßig auf allen Methoden und lass nur die Verben zu, die ein Endpunkt tatsächlich braucht. Ersetze methodenspezifische Konfigurationsblöcke durch eine Deny-by-default-Richtlinie, gib 405 für nicht unterstützte Methoden zurück, deaktiviere TRACE und teste jeden beschränkten Endpunkt mit dem vollständigen Methodensatz, um zu prüfen, dass die Kontrolle nicht umgangen werden kann.