HTTP Verb Tampering

Was ist HTTP Verb Tampering?

HTTP Verb Tampering (auch HTTP Method Tampering genannt) ist eine Angriffstechnik, bei der ein Angreifer die HTTP-Methode einer Request manipuliert, um Authentifizierungs- und Autorisierungsmechanismen zu umgehen.

Das HTTP-Protokoll kennt verschiedene Methoden (Verbs), mit denen Clients mit Servern kommunizieren:

• GET: Ressourcen abrufen
• POST: Daten an den Server senden (z. B. Formulare)
• PUT: Ressourcen aktualisieren oder erstellen
• DELETE: Ressourcen löschen
• HEAD: Wie GET, aber nur Header ohne Body
• OPTIONS: Zeigt unterstützte Methoden für eine Ressource
• TRACE: Echo-Request für Debugging (oft deaktiviert)
• PATCH: Teilweise Aktualisierung einer Ressource

Während die meisten Webanwendungen nur GET und POST aktiv nutzen, akzeptieren viele Server auch andere Methoden – oft ohne dass dies explizit intendiert oder abgesichert ist.

Das Problem: Viele Zugriffskontrollmechanismen schützen nur die gebräuchlichsten Methoden. Ein simples Beispiel aus einer Java-EE-Konfiguration:

<security-constraint>
  <web-resource-collection>
    <url-pattern>/admin/*</url-pattern>
    <http-method>GET</http-method>
    <http-method>POST</http-method>
  </web-resource-collection>
  <auth-constraint>
    <role-name>admin</role-name>
  </auth-constraint>
</security-constraint>

Diese Konfiguration schützt /admin/* nur für GET und POST. Eine HEAD-Anfrage? Läuft durch. Eine PUT-Anfrage? Ebenfalls unkontrolliert. Der Angreifer hat freie Bahn.

Wie funktioniert der Angriff?

Der Ablauf ist denkbar simpel:

1. Reconnaissance: Der Angreifer identifiziert einen geschützten Endpunkt (z. B. /admin/users)
2. Testing: Er probiert verschiedene HTTP-Methoden aus – HEAD, OPTIONS, PUT, DELETE, oder sogar erfundene Methoden wie MPRV
3. Exploitation: Findet er eine Methode, die nicht blockiert wird, kann er die Zugriffskontrolle umgehen

Das Manipulieren der HTTP-Methode ist trivial. Mit einem Proxy-Tool wie Burp Suite oder OWASP ZAP kann jeder Request abgefangen und geändert werden:

Original Request:
POST /admin/delete-user HTTP/1.1
Host: vulnerable-app.com
Cookie: session=xyz123

Manipulierter Request:
HEAD /admin/delete-user HTTP/1.1
Host: vulnerable-app.com
Cookie: session=xyz123

Wenn der Server HEAD-Requests nicht explizit blockiert, könnte diese Anfrage durchgehen – selbst wenn die Authentifizierung für POST fehlschlägt.

Reale Angriffsszenarien

Szenario 1: Admin-Panel-Zugriff

Eine Webanwendung schützt das Admin-Panel unter /admin/. Der Schutz ist so konfiguriert:

• GET /admin/ → Authentifizierung erforderlich ✅
• POST /admin/ → Authentifizierung erforderlich ✅
• HEAD /admin/ → Kein Schutz definiert ❌

Ein Angreifer sendet eine HEAD-Anfrage und erhält Zugriff. Da HEAD technisch identisch zu GET funktioniert (nur ohne Response Body), kann er Informationen extrahieren oder sogar Aktionen auslösen, wenn der Server Side Effects bei HEAD nicht verhindert.

Szenario 2: Daten-Manipulation via PUT

Eine Blog-Applikation erlaubt Nutzern, ihre eigenen Beiträge zu bearbeiten:

• POST /blog/create → Neuen Artikel anlegen
• PUT /blog/edit/123 → Artikel 123 bearbeiten (nur eigener Artikel)
• DELETE /blog/delete/123 → Artikel 123 löschen

Die Zugangskontrolle prüft bei POST und PUT korrekt, ob der Nutzer Eigentümer des Artikels ist. Doch bei DELETE fehlt diese Prüfung – vermutlich, weil der Entwickler annahm, dass DELETE ohnehin über ein Formular mit POST ausgelöst wird.

Ein Angreifer sendet direkt eine DELETE /blog/delete/456-Anfrage und löscht fremde Artikel. Verb Tampering kombiniert mit Missing Function Level Access Control – eine verhängnisvolle Mischung.

Szenario 3: Apache/PHP-Default-Handling

Manche Server behandeln unbekannte HTTP-Methoden wie Standard-Methoden. Ein Angreifer sendet:

FOOBAR /admin/config HTTP/1.1
Host: vulnerable-app.com

Wenn der Apache-Server so konfiguriert ist, dass er unbekannte Methoden akzeptiert, könnte er diese wie GET behandeln. Die Zugriffskontrolle prüft nur explizit definierte Methoden – FOOBAR ist nicht dabei. Bingo: Zugriff ohne Authentifizierung.

Besonders gefährliche HTTP-Methoden

HEAD – Der unterschätzte Zwilling von GET

HEAD ist funktional identisch mit GET, gibt aber nur die HTTP-Header zurück, keinen Body. Das macht ihn beliebt für Verfügbarkeitsprüfungen.

Problem: Viele Entwickler vergessen, dass HEAD dieselben serverseitigen Prozesse auslöst wie GET. Wenn die Access Control nur GET schützt, ist HEAD ein Bypass.

OPTIONS – Informationsleck

OPTIONS zeigt, welche HTTP-Methoden für eine Ressource verfügbar sind. Das ist eigentlich harmlos – kann aber Angreifern wertvolle Hinweise geben:

OPTIONS /admin/users HTTP/1.1
Host: vulnerable-app.com

Response:
Allow: GET, POST, PUT, DELETE, HEAD, OPTIONS

Jetzt weiß der Angreifer, dass PUT und DELETE existieren – und kann gezielt testen, ob sie geschützt sind.

TRACE – Cross-Site Tracing (XST)

TRACE wurde ursprünglich für Debugging entwickelt. Der Server echoed einfach die gesamte Anfrage zurück. Das klingt harmlos, ist es aber nicht:

• Angreifer können TRACE nutzen, um HttpOnly-Cookies auszulesen (Cross-Site Tracing)
• Kombiniert mit XSS wird TRACE zur Cookie-Stealing-Waffe

Best Practice: TRACE sollte immer deaktiviert sein.

PUT und DELETE – Datenmanipulation

Diese Methoden sind mächtig – und genau deshalb gefährlich, wenn sie unkontrolliert zugänglich sind. PUT kann Dateien hochladen, DELETE Ressourcen entfernen. Ohne strikte Authentifizierung ein Sicherheitsdesaster.

Warum ist HTTP Verb Tampering so verbreitet?

Die Schwachstelle ist bekannt, OWASP listet sie seit Jahren. Warum tritt sie dennoch regelmäßig auf?

1. Fehlende Awareness

Viele Entwickler denken in GET und POST. Dass es neun standardisierte HTTP-Methoden gibt (plus beliebige Custom-Methoden), ist vielen nicht bewusst.

2. Framework-Defaults sind unsicher

Viele Frameworks erlauben standardmäßig alle HTTP-Methoden, sofern nicht explizit eingeschränkt. "Secure by Default" sieht anders aus.

3. Unvollständige Konfigurationen

Entwickler definieren Access Control Rules für GET und POST – und übersehen, dass die Regel damit nur für diese Methoden gilt. Was nicht explizit geschützt ist, ist offen.

4. Testing-Lücken

Standard-Security-Tests prüfen meist nur die Standard-Methoden. HTTP Verb Tampering erfordert explizites Fuzzing mit verschiedenen Verbs – das machen nur wenige.

Schutzmaßnahmen: Wie verhindert man HTTP Verb Tampering?

1. Explizit erlaubte Methoden definieren (Whitelist-Ansatz)

Statt zu versuchen, alle gefährlichen Methoden zu blockieren (Blacklist), definieren Sie explizit, welche Methoden pro Endpunkt erlaubt sind.

Beispiel für Apache:

<Location /admin>
  <LimitExcept GET POST>
    Require all denied
  </LimitExcept>
</Location>

Das bedeutet: Nur GET und POST sind erlaubt. Alle anderen Methoden (HEAD, PUT, DELETE, etc.) werden blockiert.

2. Nicht benötigte Methoden global deaktivieren

Wenn Ihre Anwendung ausschließlich GET und POST nutzt, blockieren Sie alles andere auf Server-Ebene.

Beispiel für Nginx:

if ($request_method !~ ^(GET|POST)$ ) {
  return 405;
}

Beispiel für Apache (global):

<Directory /var/www>
  <LimitExcept GET POST>
    Require all denied
  </LimitExcept>
</Directory>

3. Framework-spezifische Access Control nutzen

Moderne Web-Frameworks bieten oft eingebaute Mechanismen, die automatisch alle HTTP-Methoden abdecken.

Beispiel für Spring Security (Java):

@Override
protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
        .antMatchers("/admin/**").hasRole("ADMIN")
        .anyRequest().authenticated();
}

Diese Regel gilt für alle HTTP-Methoden – kein Verb Tampering möglich.

4. TRACE-Methode deaktivieren

TRACE wird fast nie legitim genutzt und birgt Sicherheitsrisiken. Deaktivieren Sie sie:

Apache:

TraceEnable off

Nginx:

if ($request_method = TRACE) {
  return 405;
}

5. Web Application Firewall (WAF) einsetzen

Eine WAF kann verdächtige HTTP-Methoden automatisch blockieren. Moderne WAFs lernen, welche Methoden Ihre Anwendung tatsächlich nutzt, und sperren alles andere.

6. Regelmäßiges Penetration Testing

Automatisierte Vulnerability Scanner übersehen HTTP Verb Tampering oft. Manuelle Pentests mit gezieltem Method-Fuzzing decken solche Lücken auf.

Checkliste: Ist Ihre Anwendung verwundbar?

Testen Sie selbst, ob HTTP Verb Tampering ein Risiko darstellt:

• ❓ Sind Zugriffskontrollregeln nur für GET und POST definiert?
• ❓ Akzeptiert Ihr Server HEAD-Requests auf geschützte Ressourcen?
• ❓ Können Sie via OPTIONS sehen, welche Methoden verfügbar sind?
• ❓ Ist TRACE aktiviert?
• ❓ Akzeptiert der Server beliebige Custom-Methoden (z. B. FOOBAR)?
• ❓ Unterscheidet Ihre Anwendung zwischen unterschiedlichen HTTP-Methoden bei derselben URL?
• ❓ Gibt es REST-APIs, die PUT/DELETE nutzen, aber keine explizite Authentifizierung dafür haben?

Wenn Sie auch nur eine Frage mit "Ja" beantworten, sollten Sie genauer hinschauen.

HTTP Verb Tampering im Kontext moderner Architekturen

REST-APIs und Microservices

RESTful APIs nutzen HTTP-Methoden semantisch:

• GET /users → Liste abrufen
• POST /users → Neuen User anlegen
• PUT /users/123 → User 123 aktualisieren
• DELETE /users/123 → User 123 löschen

Das ist elegant – aber nur sicher, wenn jede Methode einzeln autorisiert wird. Ein häufiger Fehler: GET ist offen (lesend), POST/PUT/DELETE erfordern Admin-Rechte – doch die Prüfung greift nur bei POST, nicht bei PUT/DELETE.

Single Page Applications (SPAs)

SPAs kommunizieren oft ausschließlich via AJAX mit REST-Backends. Entwickler gehen davon aus, dass der JavaScript-Code nur definierte Methoden nutzt. Doch ein Angreifer umgeht die SPA und sendet Requests direkt – mit beliebigen Methoden.

Fazit: Frontend-Controls schützen nicht. Backend-Validierung ist Pflicht.

Fazit: Unterschätzt, aber gefährlich

HTTP Verb Tampering ist keine spektakuläre Zero-Day-Schwachstelle. Es ist eine Konfigurationslücke, die aus fehlender Awareness und unvollständigen Security-Controls resultiert. Doch die Auswirkungen können gravierend sein:

• Unbefugter Zugriff auf Admin-Funktionen
• Datenmanipulation oder -löschung
• Umgehung von Authentifizierung und Autorisierung

Die gute Nachricht: Schutz ist einfach. Ein Whitelist-Ansatz, explizite Method-Controls und regelmäßiges Testing genügen meist, um die Schwachstelle zu eliminieren.

Die schlechte Nachricht: Solange Entwickler in "GET und POST" denken und vergessen, dass HTTP neun Standardmethoden kennt (plus beliebige Custom-Methoden), wird HTTP Verb Tampering weiterhin in freier Wildbahn anzutreffen sein.

Zeit, das zu ändern. Prüfen Sie Ihre Anwendungen. Sichern Sie Ihre Endpoints. Und denken Sie daran: Was nicht explizit geschützt ist, ist offen.