HTTP-Methoden-Prüfer

Testet, welche HTTP-Methoden auf einer URL aktiviert sind (GET, HEAD, POST, PUT, DELETE, PATCH, TRACE). Kennzeichnet gefährliche Methoden wie TRACE (XST) und unnötige PUT/DELETE. Bewertung A–F.

So verwenden Sie HTTP-Methoden-Prüfer

  1. 1Geben Sie die URL ein, um zulässige HTTP-Methoden zu testen.
  2. 2Das Tool sendet eine OPTIONS-Anfrage und testet wichtige HTTP-Verben.
  3. 3Ergebnisse zeigen für jede Methode den zulässig/abgelehnt-Status mit Risikoebenen.
  4. 4Überprüfen Sie gefährliche Methoden (TRACE, PUT, DELETE) und Empfehlungen.
ZenovayAnalytics

Analytics ganz ohne Cookie-Banner.

  • Besucher-Tracking in Echtzeit
  • Datenschutz zuerst, kein Cookie-Banner
  • In zwei Minuten eingerichtet
Zenovay entdecken

Häufig gestellte Fragen

Welche HTTP-Methoden sind Sicherheitsrisiken?
TRACE ist am gefaehrlichsten - es ermöglicht Cross-Site-Tracing (XST)-Angriffe, die Cookies stehlen können, selbst wenn HttpOnly gesetzt ist, indem die TRACE-Spiegelung mit einer manipulierten XSS-Nutzlast ausgenutzt wird. PUT und DELETE sind gefaehrlich, wenn sie unrestriktiert sind, da sie Angreifern erlauben könnten, Dateien hochzuladen oder zu löschen. CONNECT kann verwendet werden, um Proxy-Tunnel zu erstellen, die Firewalls umgehen. Diese Methoden sollten explizit deaktiviert werden, wenn Ihre Anwendung sie nicht benötigt.
Warum antwortet mein Server auf PUT/DELETE, ist aber eigentlich nicht ausnutzbar?
Eine 200/204-Antwort auf PUT oder DELETE bedeutet nicht unbedingt, dass ein Angreifer Dateien überschreiben kann - Authentifizierung, Autorisierungs-Middleware und Anwendungs-Routing können unautorisierten Aktionen blockieren. Die Exposition dieser Methoden zeigt jedoch, dass Ihr Server sie nicht auf HTTP-Ebene einschränkt. Best Practice ist, sie auf Web-Server/Load-Balancer-Ebene zu deaktivieren. Der Checker markiert sie als zu untersuchende Risiken, nicht als bestaetigt ausnutzbare Schwachstellen.
Was ist Cross-Site-Tracing (XST) und warum ist TRACE gefaehrlich?
XST ist ein Angriff, bei dem TRACE alles zurückspiegelt, einschliesslich des Authorization-Headers und der Cookies. In Kombination mit einer XSS-Schwachstelle kann ein Angreifer JavaScript verwenden, um eine TRACE-Anfrage zu senden und die gespiegelten Cookies zu lesen - dabei wird das HttpOnly-Flag umgangen. OWASP empfiehlt, TRACE auf allen Produktionsservern zu deaktivieren. In Apache: TraceEnable Off hinzufügen. In Nginx: if ($request_method = TRACE) { return 405; } verwenden.
Was ist der Allow-Header und wie haengt er mit diesem Test zusammen?
Der Allow-Header in einer HTTP-Antwort (typischerweise aus einer OPTIONS-Anfrage) listet die HTTP-Methoden auf, die der Server für eine Ressource unterstützt. Wenn ein Allow-Header zurückgegeben wird, verwendet dieses Tool ihn als Leitfaden, sendet aber dennoch Sondierungsanfragen, um das tatsächliche Verhalten zu verifizieren. Wenn kein Allow-Header zurückgegeben wird, werden alle Methoden direkt sondiert.
Wie deaktiviere ich TRACE in gängigen Webservern?
Apache: TraceEnable off in httpd.conf oder .htaccess hinzufügen. Nginx: if ($request_method = TRACE) { return 405; } im server block hinzufügen. IIS: Request-Filtering-Modul verwenden, um das TRACE-Verb zu blockieren. Node.js/Express: Middleware hinzufügen, um TRACE-Anfragen abzulehnen. Load Balancer (Cloudflare, AWS ALB): benutzerdefinierte WAF-Regeln konfigurieren, um TRACE zu blockieren. Die meisten modernen CDNs blockieren TRACE automatisch.