Unsichere HTTP-Methoden zugelassen

Ein Webserver akzeptiert standardmäßig ein breiteres Angebot an HTTP-Methoden, als die dahinterliegende Anwendung nutzt. Das ist selten ein akutes Problem und häufig ein Hinweis: Der Unterschied zwischen dem, was eingestellt ist, und dem, was benötigt wird, sagt etwas darüber aus, wie sorgfältig die Umgebung eingerichtet wurde. Im Folgenden lesen Sie, welche Methoden zählen und wo sie sehr wohl zu etwas Schwerwiegenderem führen.

Welche Methoden gibt es und welche gehören abgeschaltet?

HTTP kennt eine Reihe von Methoden mit jeweils eigener Bestimmung. GET ruft ab, POST sendet, PUT und DELETE schreiben und löschen, HEAD fragt nur die Header ab, OPTIONS teilt mit, was erlaubt ist, und TRACE gibt die empfangene Anfrage zurück.

Von unsicheren HTTP-Methoden spricht man, wenn der Server Methoden akzeptiert, die die Anwendung nicht nutzt. Das ist für sich genommen keine Schwachstelle, vergrößert aber die Angriffsfläche ohne jede Gegenleistung. Jede eingeschaltete Methode ist ein Verhalten, das jemand untersuchen kann und dessen Verarbeitung irgendwo umgesetzt ist, mal durch Ihre Anwendung, mal durch den Webserver, mal durch ein Modul, von dessen Bestehen Sie nichts wussten.

Denken Sie an ein Gebäude mit Türen zu Räumen, die niemand nutzt. An sich geschieht nichts. Sie müssen sie jedoch alle verschlossen halten, und das ist eine Aufgabe, die Sie sich hätten ersparen können.

Wohin führen unsichere HTTP-Methoden?

Verwundbar:

OPTIONS / HTTP/1.1
Host: portal.example

HTTP/1.1 200 OK
Allow: GET, POST, PUT, DELETE, OPTIONS, HEAD, TRACE, PATCH

Diese Antwort gibt in einer Zeile preis, was alles offensteht. TRACE gibt die Anfrage vollständig zurück, einschließlich der Header, die zwischengeschaltete Proxys hinzugefügt haben:

TRACE / HTTP/1.1
Host: portal.example

HTTP/1.1 200 OK
Content-Type: message/http

TRACE / HTTP/1.1
Host: portal.example
X-Forwarded-For: 10.0.4.12
X-Internal-Route: cluster-b-node3
Cookie: sid=8f42c19ade7b3f5c

Die interne Netzwerkstruktur und die Routing-Header Ihrer Infrastruktur stehen nun in der Antwort. Schwerwiegender wird es, wenn PUT tatsächlich von einem Modul des Webservers umgesetzt wird statt von Ihrer Anwendung:

PUT /uploads/shell.jsp HTTP/1.1
Host: portal.example
Content-Length: 51

<% Runtime.getRuntime().exec(request.getParameter("c")); %>

Bei einem falsch konfigurierten Server mit Schreibrechten auf diesem Ordner ist das ein unmittelbarer Weg zur Codeausführung. Das ist selten, kommt aber bei älteren Installationen und bei nie geschlossenen Standardkonfigurationen vor.

Sicher:

# Nur das, was die Anwendung nutzt
location / {
    limit_except GET POST {
        deny all;
    }
    proxy_pass http://anwendung;
}

// Und in der Anwendung selbst, je Route ausdrücklich
app.route('/api/rechnungen/:id')
  .get(erfordertAnmeldung, zeigeRechnung)
  .put(erfordertAnmeldung, aendereRechnung)
  .all((req, res) => res.status(405).set('Allow', 'GET, PUT').send());

Der Webserver lässt nur durch, was nötig ist, und die Anwendung antwortet auf alles darüber hinaus mit einer 405 und einem korrekten Allow-Header. Letzteres ist zugleich sauber und aufschlussreich, ohne zu viel preiszugeben: Dort steht, was dieser Endpunkt unterstützt, nicht, was der Server im Allgemeinen beherrscht.

Welche Auswirkungen haben unsichere HTTP-Methoden?

Der Schweregrad ist üblicherweise niedrig, und das entspricht der Wirklichkeit: In den meisten Fällen geht es um überflüssige Funktionen ohne unmittelbaren Missbrauch. Zwei Lagen ändern das.

Die erste ist eine schreibende Methode, die tatsächlich funktioniert. Lässt sich über PUT eine Datei auf dem Server ablegen, entspricht die Auswirkung einem unbeschränkten Datei-Upload und ist damit hoch. Das erfordert eine bestimmte Kombination aus einem eingeschalteten Modul und Schreibrechten, doch diese Kombination gibt es in der Praxis.

Die zweite ist das Umgehen der Zugriffskontrolle. Sind Beschränkungen je Methode formuliert, kann eine abweichende Methode daran vorbei. Ein bekanntes Muster ist eine Verwaltungsseite, die für GET abgeschirmt ist, über HEAD oder eine unbekannte Methode jedoch von der dahinterliegenden Anwendung dennoch verarbeitet wird.

Hinzu kommt der Informationswert. Was eine OPTIONS-Antwort und ein umfangreiches Methodenangebot vor allem verraten, ist, dass die Umgebung auf Standardeinstellungen läuft. Für einen Angreifer ist das ein Hinweis darauf, dass vermutlich mehr nicht geschlossen wurde.

Wie spürt man unsichere HTTP-Methoden auf?

Ein Tester fragt mit OPTIONS ab, welche Methoden der Server zu unterstützen angibt, und prüft das anschließend in der Praxis, denn die angegebene Liste und das tatsächliche Verhalten laufen regelmäßig auseinander. Jede Methode wird gesondert ausprobiert, um zu sehen, welche eine sinnvolle Antwort liefert statt einer 405.

Bei TRACE wird geprüft, ob die Anfrage zurückgegeben wird und ob darin Header stehen, die von zwischengeschalteten Systemen hinzugefügt wurden. Bei PUT und DELETE wird behutsam geprüft, ob tatsächlich etwas geschrieben oder gelöscht wird. Ferner werden unbekannte und erfundene Methoden ausprobiert, denn manche Server reichen diese an die Anwendung weiter, ohne sie zu beschränken, eine bekannte Möglichkeit, Zugriffsregeln zu umgehen. Auch Mechanismen für Method Override über einen Header oder Parameter erhalten Aufmerksamkeit. AssistSec prüft ausdrücklich, ob eine abgeschirmte Route mit einer abweichenden Methode dennoch erreichbar ist, denn das ist das Szenario, in dem dieser Befund von der Härtung zur echten Zugriffskontrolle wechselt.

Wie verhindert man unsichere HTTP-Methoden?

• Lassen Sie auf jeder Route nur die Methoden zu, die die Anwendung wirklich nutzt.
• Schalten Sie TRACE ab; es gibt dafür keine Anwendung in der Produktion.
• Schalten Sie PUT und DELETE am Webserver ab, wenn allein Ihre Anwendung sie verarbeitet.
• Legen Sie Zugriffsregeln anhand des Erlaubten fest, nie als Liste von Ausnahmen.
• Antworten Sie auf nicht unterstützte Methoden mit 405 und einem korrekten Allow-Header für diesen Endpunkt.
• Lassen Sie OPTIONS nur die Methoden nennen, die es an diesem Endpunkt gibt.
• Schalten Sie Method Override über Header oder Parameter ab, wenn Sie es nicht benötigen.
• Prüfen Sie, ob die Beschränkungen auch hinter einem Reverse Proxy, Lastverteiler oder CDN gelten.
• Wiederholen Sie die Prüfung nach einer Servermigration, denn Standardkonfigurationen kehren dann zurück.