Scanner für gefährliche HTTP-Methoden

Wie diese Prüfung funktioniert

Scanaris schickt eine OPTIONS-Anfrage an die gescannte URL, ohne Weiterleitungen zu folgen, und liest zwei Antwort-Header: Allow, mit dem ein Server angibt, welche Methoden er auf dieser Route akzeptiert, und Access-Control-Allow-Methods, den von CORS. Listet einer von beiden TRACE, TRACK, PUT, DELETE oder CONNECT, öffnet er einen Befund mit niedrigem Schweregrad und der Liste. Es ist eine vorsichtige Prüfung: Sie meldet nur, was der Server ausdrücklich ankündigt. Sie sendet nie ein Test-PUT oder -DELETE, und wenn der Server auf OPTIONS nicht antwortet oder diese Header nicht zurückgibt, gibt es keinen Befund.

Warum das wichtig ist

Eine normale Website braucht GET, HEAD, POST und, für CORS, OPTIONS. Der Rest sind Methoden mit Geschichte. TRACE gibt die Anfrage genau so zurück, wie sie ankam, Header eingeschlossen; kombiniert mit einem anderen Fehler erlaubt das, als HttpOnly markierte Cookies zu lesen (der Angriff heißt Cross-Site Tracing). PUT und DELETE legen Ressourcen an, ersetzen oder löschen sie: Auf einem falsch konfigurierten Dateiserver lädt ein PUT eine Datei ins öffentliche Verzeichnis. CONNECT macht den Server zum Proxy. Dass sie aktiv sind, heißt nicht, dass sie ohne Authentifizierung funktionieren, daher der niedrige Schweregrad; aber sie anzukündigen, ohne sie zu nutzen, ist Angriffsfläche umsonst.

So behebst du es

• Apache: TraceEnable Off in der Hauptkonfiguration (TRACE ist in älteren Versionen standardmäßig an). Für den Rest, im Directory oder Location deiner Seite: <LimitExcept GET POST HEAD OPTIONS> Require all denied </LimitExcept>.
• nginx: implementiert TRACE nicht. Um den Rest in einem location-Block zu begrenzen: limit_except GET POST HEAD OPTIONS { deny all; }. Wenn du if ($request_method !~ ^(GET|HEAD|POST|OPTIONS)$) { return 405; } nutzt, setz es auf server-Ebene.
• IIS: Das WebDAV-Modul ist der übliche Grund für angekündigte PUT und DELETE. Deinstalliere es, wenn du es nicht brauchst, und begrenze in web.config die Verben über requestFiltering/verbs.
• Express und APIs: Nutzt deine API PUT oder DELETE mit Authentifizierung, darf Access-Control-Allow-Methods sie legitim auflisten; was sie nicht tun sollte, ist, sie für die ganze Seite zu listen oder * zu nutzen. Setz im CORS-Middleware methods: ['GET', 'POST'] für öffentliche Routen und erweitere nur dort, wo es nötig ist.
• Vercel, Netlify, Cloudflare Pages: kündigen diese Methoden standardmäßig nicht an. Taucht der Befund auf, stammt er meist von einem CORS-Header, den du selbst mit der vollständigen Liste konfiguriert hast.

Prüf, ob es behoben ist

curl -si -X OPTIONS https://deinedomain.de | grep -iE "^(HTTP|allow|access-control-allow-methods):"
curl -si -X TRACE https://deinedomain.de | head -1

Im ersten sollten weder Allow noch Access-Control-Allow-Methods auf öffentlichen Routen TRACE, TRACK, PUT, DELETE oder CONNECT enthalten. Der zweite muss 405 oder 403 zurückgeben, niemals 200 mit deiner Anfrage im Body gespiegelt.

Häufige Fragen

Meine REST-API nutzt PUT und DELETE. Muss ich sie entfernen?

Nein. Wichtig ist, dass diese Routen Authentifizierung verlangen und dass der CORS-Header sie nicht für die ganze Domain oder jede Herkunft ankündigt. Zielt der Scan auf das Root deiner API, kannst du den Befund mit niedrigem Schweregrad als akzeptiert markieren, sobald du das geprüft hast. Die Konfiguration der Origins prüft permissives CORS.

Access-Control-Allow-Methods listet Methoden, aber es gibt kein Allow. Ist das dasselbe?

Nicht ganz. Allow beschreibt, was der Server akzeptiert; der CORS-Header beschreibt, was er Seiten anderer Herkunft erlaubt. Beide werden gelesen, weil beide Information sind, die du preisgibst. Was jeder Teil einer CORS-Antwort bedeutet, erklärt falsch konfiguriertes CORS.

Warum gilt OPTIONS nicht als gefährlich?

Weil es die Methode ist, mit der der Browser vor bestimmten Anfragen nach CORS fragt. Sie zu sperren bricht domainübergreifende Aufrufe. Sie ist harmlos und notwendig.