Im Jahr 2019 wurde im CDN-Netzwerk die Sicherheitsanfälligkeit CPDoS Cache Poisoned Denial of Service entdeckt , die es ermöglicht, den HTTP-Cache des CDN-Anbieters zu vergiften und einen Denial-of-Service zu verursachen. Die Sicherheitsanfälligkeit hat noch nicht viel Hype ausgelöst, da sie bei echten Angriffen nicht beobachtet wurde. Aber ich möchte separat über eine der Cache-Vergiftungsmethoden sprechen. Überschreiben der HTTP-Methode.Wenn andere Varianten der Ausnutzung der Sicherheitsanfälligkeit auf die eine oder andere Weise auf Fehlern oder Merkmalen der Anforderungsänderung durch einen Vermittler beruhen, basiert die Methode Override-Variante auf der gleichnamigen Taktik, die nicht Teil des HTTP-Standards ist, zusätzliche Probleme mit sich bringt und die aufgrund von Unachtsamkeit entstanden und verbreitet wurden Beziehung zur Sicherheit. Hier werden wir es betrachten.Kurz über CPDoS, wenn Sie es verpasst haben, URI method .
, , , , - . — - - -, , - , . , .
, . , ,
-. - , , .
Begrenzen Sie den Client, weniger kann - weniger wird brechen
Die Notwendigkeit, die Methode in der Anforderung zu überschreiben, ergab sich aus der Tatsache, dass einige Webanwendungsfirewalls und HTTP-Client-Implementierungen sehr begrenzt waren und die Ausführung anderer Methoden als GET und POST nicht zuließen. Das Problem ist nicht, dass es sich um eine Implementierungsbeschränkung handelte, sondern dass es sich um eine absichtliche Einschränkung von HTTP-Clients durch eine Sicherheitsrichtlinie handelte.Es ist klar, dass alles gut gemeint ausgeführt wurde, um den beengten Datenverkehr zu unterbinden, der für normale HTTP-Clients nicht dem Standard entspricht. Aus Sicherheitsgründen wurden jedoch alle Methoden außer GET und POST abgeschnitten. Möglicherweise, weil dies die einzigen Methoden sind, die nicht optional sind und für Allzweckserver erforderlich sind .Warum eine derart strenge Beschränkung eingeführt werden musste, ist nicht klar. Ja, Angriffe mit der Einführung verschiedener Zeichen, um den Parser zu verwirren, sind nur das Hobby von Textprotokollen. Sie könnten jedoch etwas mehr Methoden zulassen, z. B. mindestens diejenigen, die im Standard selbst beschrieben oder bei IANA registriert sind . Es hat sich nicht gelohnt, die Methodenprüfung vollständig zu entfernen, aber Sie können eine Reihe der beliebtesten Methoden wählen und diejenigen ausschließen, die das Interaktionsprotokoll ändern und die Arbeit mit Verbindungen auf dem Proxyserver (CONNECT) unterbrechen. Aber nein, es stellte sich heraus, dass eine Sicherheitsrichtlinie unnötige Einschränkungen und Verbote für Kunden einführte .Und die Kunden waren auf die falschen beschränkt. Sie wollten die Variabilität von Nachrichten von HTTP-Clients begrenzen und die von diesen WAFs geschützten Clients, die Endanwendungsserver und ihre Entwickler einschränken. Jetzt hatten die Entwickler nur noch zwei Methoden, die nicht immer ausreichten, um die Logik des HTTP-Clients zu beschreiben.Einschränkungen werden erstellt, um sie zu überwinden.
Es war zu erwarten, dass diese übermäßige Einschränkung früher oder später die Webentwickler stören würde. Die Ironie ist, dass es so einfach ist, solche WAFs nicht loszuwerden. Besonders wenn sie mit Kunden oder Anbietern zusammen sind. Die Sicherheitsrichtlinien anderer Menschen in Frage zu stellen, ist eine katastrophale Angelegenheit.Aufgrund der Flexibilität von HTTP ist es nicht schwierig, diese Einschränkung zu umgehen. Fügen Sie der Anforderung einfach etwas hinzu, bei dem Sie die Methode überschreiben können. Strict WAF überprüft nur die Methode in der Anforderungszeile (der ersten Zeile der Anfrage) und freut sich, dort ein genehmigtes GET oder POST zu sehen. Das Backend kann das hinzugefügte Element analysieren und die reale Methode daraus extrahieren.Sie können eine Reihe von Artikeln googeln , wirklich eine Reihedarüber, wie fehlerhafte Proxys REST-Anwendungen beschädigt haben und wie die Autoren die reale Methode in einem separaten Header übergeben mussten. In allen Fällen wird vorgeschlagen, dass Sie ungefähr denselben Header eingeben (X-HTTP-Methode, X-HTTP-Methodenüberschreibung oder X-Methodenüberschreibung - die Schreibweise variiert etwas), um eine überschriebene Methode anzugeben. Sehr, sehr selten kann man Referenzen finden, die für den gleichen Zweck der Abfragekomponenten-URI verwendet werden können.Was in diesen Artikeln fehlt, ist der Abschnitt Sicherheitsüberlegungen. Und sie sind es einfach.Ist das Überschreiben von Methoden sicher?
Manchmal vergessen Entwickler von Webanwendungen, dass sich zwischen dem Client und dem Server möglicherweise Zwischen-Teilnehmer befinden, die über das HTTP-Protokoll interagieren: Proxys, Web-Caches von Anbietern, CDN und WAF. Die Verbreitung von TLS verringert die Wahrscheinlichkeit eines zwischengeschalteten Teilnehmers zwischen Client und Server erheblich. Höchstwahrscheinlich ist der einzige Proxy zwischen dem Client und dem Backend ein eigener Server mit Nginx. Eine solche Konfiguration ist einfach genug, um sie vor der Veröffentlichung in typischen Szenarien zu testen.Aber wir bewegen uns in das Zeitalter von CDN und immer mehr Anwendungen werden sich hinter CDNs verstecken, die den Benutzerverkehr lesen und manipulieren. Backends direkt bedienen Benutzer fast nie und verstecken sich hinter Reverse-Proxys, um die Reaktionsfähigkeit und Leistung zu erhöhen. Daher müssen Sie sich daran erinnern, wie sich das Überschreiben einer Methode auf die Verarbeitung einer Anforderung auf einem Vermittlungsserver auswirken kann.Die Angriffe, über die ich sprechen möchte, gelten hauptsächlich für HTTP / 1.1. HTTP / 2 erbt in gewisser Weise das Verhalten des alten Standards, in gewisser Weise geht es seinen eigenen Weg, sodass die Anwendbarkeit jedes Angriffs auf den neuen Standard separat betrachtet wird.Cache-Angriffe
In den meisten Fällen berücksichtigen Zwischenserver keine Methodenüberschreibungen, überprüfen nicht die Header der X-HTTP-Methodenüberschreibungsfamilie und arbeiten mit der Anforderung mithilfe ihrer Hauptmethode aus der Anforderungszeile. Und da die überschriebene Methode nicht im Schlüssel zur Suche nach einer Anforderung im Cache enthalten ist (Methode + URI), können solche Server POST nicht von POST + X-HTTP-Methodenüberschreibung: LÖSCHEN unterscheiden. Dies bedeutet, dass Sie das Zwischenspeichern von Anforderungen an einen bestimmten URI nicht zulassen können, wenn das Backend überschriebene Methoden überwachen und ausführen kann.Das CPDoS-Dokument enthält ein gutes Beispiel dafür, was passiert, wenn Sie eine solche Anforderung zwischenspeichern. Wenn ein Angreifer eine POST-Anforderung als GET-Anforderung tarnt, erkennt der Proxy die Ersetzungen nicht und behandelt die Anforderung als legitime GET-Anforderung. Das Backend erkennt jedoch die überschriebene Methode und führt das im Header X-HTTP-Method-Override - POST beschriebene Verb aus. Da die POST-Methode für den Ziel-URI nicht definiert ist, generiert der Server einen Fehler. Ferner wird die Backend-Antwort als Antwort auf die ursprüngliche Methode - GET - im Cache gespeichert. Jetzt gibt jede nächste GET-Anforderung für denselben URI einen zwischengespeicherten Fehler zurück.
POST /some-uri HTTP/1.1
X-HTTP-Method-Override: DELETE
↓ ↓ ↓
POST /some-uri?method=DELETE HTTP/1.1
Jetzt sehen Anforderungen mit unterschiedlichen Methoden für den Cache unterschiedlich aus, da sie unterschiedliche Schlüssel erhalten. Einige Proxys ziehen es vor, Antworten auf Anforderungen, die die Abfragekomponente im URI enthalten, nicht zwischenzuspeichern. Dies wirkt sich jedoch nur auf die Caching-Effizienz aus. Diese Methode löst immer Probleme mit falschem Caching.Eine andere Möglichkeit besteht darin, die Methodenüberschreibung in einem separaten Header zu belassen, aber einen Sekundärschlüssel einzugeben, um die Antwort im Cache zu finden. Dies ist mit dem Vary-Header möglich. Bei der Bearbeitung der Anforderung wiederholt der Server den Header mit der Methodenüberschreibung und gibt den Namen dieses Headers im Vary-Header wieder. Bei den folgenden Anforderungen verwendet der Cache-Server dann den Wert der überschriebenen Methode als Sekundärschlüssel, wenn nach einer Anforderung im Cache gesucht wird.Diese Methode funktioniert, wenn der Zwischenserver mit Sekundärschlüsseln arbeiten kann. Dies ist normalerweise der Fall, aber die Proxy-Vertrauensstufe, die alle Methoden außer GET und POST schneidet, ist normalerweise niedriger und es ist besser, dies zu überprüfen.Das Überschreiben einer Methode durch eine Entität innerhalb des Anforderungshauptteils hat genau die gleichen Nachteile wie das Überschreiben eines zusätzlichen Headers - es ist außerhalb der Sichtbarkeit des Caches.Nachrichtenwarteschlangenangriffe
Selbst wenn Cache-Angriffe geschlossen sind, ist das noch nicht alles. Ein Angreifer kann durch Überschreiben einer Methode versuchen, den Rahmen der Antwort zu ändern und dadurch die Entsprechung der Anforderungs-Antwort-Paare für andere Clients zu verletzen. Oder zwingen Sie die Serverseite der Anwendung, dieselbe Anforderung mehrmals zu verarbeiten.Das Wichtigste, was dafür erforderlich ist, ist ein Zwischenserver, der im Reverse-Proxy-Modus arbeitet. Das heißt, jeder Caching- oder CDN-Server. Ein solcher Proxy unterstützt eine relativ kleine Anzahl von Verbindungen zum Backend und multipliziert Anforderungen von vielen Clients in jedem von ihnen. Dies ist sowohl erforderlich, um die Unterstützung einer großen Anzahl von Clientverbindungen von den Backends zum Proxyserver zu übernehmen, als auch um die Last zwischen den Backends auszugleichen. Die Beendigung von TLS-Verbindungen erfolgt auch auf dem Proxy. Client-Verbindungen werden niemals direkt mit dem Backend verbunden.Da sich jetzt Anforderungen von verschiedenen Clients in derselben Verbindung zwischen dem Backend und dem Proxy befinden, ist es erforderlich, eine eindeutige Entsprechung zwischen den Anforderungs-Antwort-Paaren aufrechtzuerhalten. Die meisten Proxys leiten keine Pipeline(Pipelines) Anfragen an das Backend und arbeitet damit im Request-Response-Modus. Der Request-Response-Modus ist einfacher und unterliegt praktisch einer Bedrohung - dem Blockieren von Verbindungen. Wenn Sie die Verbindung an einem einzelnen Anforderungs-Antwort-Paar hängen lassen, können Sie eine Verzögerung oder sogar eine Verweigerung der Verarbeitung der folgenden Anforderungen verursachen (z. B. wenn es Ihnen gelingt, die Warteschlangen von Proxy-Anforderungen zu überlaufen).Produktivere Proxy-Pipeline-Anforderungen an das Backend - Auf diese Weise können Sie sofort ein Paket von Anforderungen an den Server senden und auf deren Ausführung warten. Die Leistung ist höher, aber es gibt mehr Bedrohungen. Erstens verschwindet das Problem der Head-of-Line-Blockierung nirgendwo - selbst wenn das Backend die Abfrage-Pipeline harken und parallel ausführen kann, können sie nicht gesendet werden, wenn die erste hängt. Zweitens, wenn Sie den Antwortrahmen unterbrechen, können Sie den Proxy verwirren und die Korrespondenz der Anforderungs-Antwort-Paare unterbrechen, dann können einige Clients die Antworten anderer Personen erhalten oder zumindest einen sofortigen Verbindungsabschluss mit dem Backend erreichen.
Automatische Spam-Wiedergabe
Ich habe oben gesagt, dass Anfragen der Form GET + X-HTTP-Method-Override: PATCH von seriösen Clients schlecht sind. Und das ist schlecht, weil Methoden zwei Eigenschaften haben: Sicherheit und Idempotenz . Sicherheit bedeutet, dass die Methode den Status des Servers nicht ändert (schreibgeschützt) und uns im Kontext dieses Artikels nicht interessiert. Die Idempotenz der Methode stellt sicher, dass wiederholte Anforderungen den gleichen Effekt haben wie eine einzelne Anforderung. Sie können eine Analogie ziehen: (a = 5)- idempotente Anfrage und (a += 2) - nicht idempotente.Diese Eigenschaft interessiert uns. Wenn die Verbindung zwischen Client und Server plötzlich unterbrochen wird, kann der Client die Anforderung automatisch erneut senden, da er weiß, dass die Methode idempotent ist. Proxies verhalten sich genauso. Nicht idempotente Anforderungen werden nicht automatisch wiederholt, da nicht bekannt ist, wie sie sich auf den Server auswirken und was der Client am Ende erhält. Ich denke, jeder kennt die Popups im Browser: "Sind Sie sicher, dass Sie die Anfrage wiederholen möchten?"Wenn Sie eine nicht idempotente Methode als idempotent maskieren, wird sie im Fehlerfall nicht verworfen, sondern erneut zum Server umgeleitet. Selbst wenn der Client die tatsächliche Anforderungsmethode berücksichtigt, bevor er die Anforderung erneut sendet, hilft dies nicht viel, da der Proxyserver die Methodenüberschreibung nicht kennt und solche Anforderungen wiederholt.Wenn ein Angreifer in der Lage ist, die Trennung zwischen dem Backend und den Clients zu erzwingen, kann er den Server veranlassen, nicht idempotente Anforderungen mehrmals auszuführen und die Zuverlässigkeit und Vorhersagbarkeit der Anwendung zu verringern. Im vorherigen Abschnitt haben wir gerade einen Weg gefunden, wie Sie mit derselben Methodenüberschreibung Verbindungsunterbrechungen verursachen können. Obwohl zu beachten ist, dass das Internet per Definition ein unzuverlässiges Netzwerk ist und die Anwendung selbst in Gefahr ist.Zum Schutz vor diesem Angriff sollten Sie nur Methoden verwenden, die der Anforderung keine neuen Eigenschaften als Transport hinzufügen. POST ist ein guter Kandidat, da es standardmäßig weder sicher noch idempotent ist.Das alte HTTP / 1.1, wie bei HTTP / 2?
HTTP / 2 hat die Art und Weise geändert, wie Anforderungen zwischen Knoten transportiert werden, hat jedoch ihre lexikalische Bedeutung nicht geändert. Daher verhält sich HTTP / 2 bei Angriffen, die sich auf den Anforderungswert beziehen, gleich. Transportangriffe werden jedoch nicht reproduziert, da sie bereits im Standard berücksichtigt sind.Angriffe auf den Cache werden auf ähnliche Weise wie HTTP / 1 reproduziert, und der Schutz ist ähnlich.Message Queuing-Angriffe gelten nicht für HTTP / 2. Die darin enthaltenen HTTP-Nachrichten sind in separate Frames mit separaten Frame-Headern unterteilt, die die Länge und das Ende der Nachricht explizit bestimmen. Als ob der Angreifer die Methode nicht ändern und die HTTP-Header ändern würde, hat dies keine Auswirkungen auf den Nachrichtenrahmen. Das Stehlen der Antwort wird fehlschlagen.Angriffe auf die Wiederholung nicht idempotenter Nachrichten sind auch unter Berücksichtigung der Tatsache anwendbar, dass es in HTTP / 2 solche gibtBenachrichtigungsmechanismus der zuletzt verarbeiteten Anfrage . In HTTP / 2 werden mehrere Anforderungen in demselben TCP multipliziert und erzeugen so Flows . Jeder Thread hat eine eigene Nummer. Wenn der HTTP / 2-Server die Verbindung trennt, kann er die Nummer der zuletzt verarbeiteten Anforderung in GOAWAY angeben. Anfragen mit einer höheren Nummer können immer sicher umgeleitet werden, Anfragen mit einer niedrigeren Nummer werden nur umgeleitet, wenn sie idempotent sind. Wenn eine Anforderung mit einer überschriebenen Methode für einen Proxyserver idempotent aussieht, leitet der Proxy sie an den Server weiter.So überschreiben Sie eine Methode sicher
Die kurze Antwort ist auf keinen Fall. Es ist besser, überhaupt keine Methodenüberschreibungen zu verwenden. Deaktivieren Sie gegebenenfalls die Unterstützung im Backend vollständig. Blockieren Sie überschreibende Methoden für HTTP-Clients. Verweigern Sie Proxy / WAF, wodurch die "zusätzlichen" Methoden abgeschnitten werden.Wenn Sie irgendwie mit der Neudefinition der Methode leben müssen, dann verhindern Sie genügend Änderungen am Backend. Zunächst ist es ratsam, die Methode nur über die Abfragekomponente des URI zu überschreiben.Zweitens sollte es eine weiße Liste der Transformation von Methoden geben: welche als "Transport" akzeptabel sind und welche die resultierenden sind. Es sollte keine verallgemeinerten Transformationsfunktionen geben, wenn eine Methode von einer überschrieben werden kann. Die "Transport" -Methode sollte nicht die Eigenschaften von Sicherheit und Idempotenz haben, wenn die resultierende dies nicht tut. Gefährliche Transformationen sollten verboten werden, der gleiche Ersatz GET -> HEAD.Muss ich einen Problem-Proxy / WAF patchen?
Wenn der Proxy nur die Methoden GET und POST implementiert und die anderen aus dem einen oder anderen Grund blockiert, auf jeden Fall ja. Sie können es hauptsächlich für GET und POST optimieren, aber das Blockieren anderer Methoden ist eine schlechte Idee. Was immer noch zu Misstrauen gegenüber dem Produkt führt: Wenn grundlegende Dinge blockiert sind, was kann man von der Umsetzung komplexerer Probleme erwarten?Wenn Sie sich Sorgen über die Sicherheit geschützter Webanwendungen machen, kann es sinnvoll sein, Anwendungen vor Richtlinien zum Überschreiben unsicherer Methoden zu schützen. Im allgemeinen Fall ist es natürlich unmöglich, die Anwendung vollständig vor falschen Überschreibungen zu schützen, ohne die Details der Implementierung der Webanwendung zu kennen, aber Sie können teilweise Benutzer abdecken, die das Problem einfach nicht kennen. Es ist nicht nur erforderlich, den eigenen Cache vor einer Vergiftung zu schützen, sondern auch das Aktivieren oder Deaktivieren des Überschreibens für jede geschützte Anwendung zu ermöglichen. Um dies zu tun, den Überblick über häufig verwendete Header.X-HTTP-Methode, X-HTTP-Methodenüberschreibung und X-Methodenüberschreibung. Das Verfolgen der Neudefinition in der Abfragekomponente des URI ist wenig sinnvoll: Der Cache vergiftet eine solche Anforderung nicht, und die Abfrage kann sehr lang sein und ein völlig beliebiges Format haben.?
Sicherheitsentwickler beschränken Anwendungsentwickler nicht auf Sicherheitsrichtlinien. Sie werden immer noch herausfinden, wie sie um sie herumkommen können. Je flexibler das Protokoll ist, desto einfacher ist es, dies zu tun. Es ist sehr wahrscheinlich, dass sie Sie nicht treten und warten, bis Sie die Einschränkungen vernünftiger machen, sondern sie einfach umgehen.Wenn Sie herausgefunden haben, wie etwas in das Protokoll implementiert werden soll, es jedoch eines der Schlüsselkonzepte des Standards überschreibt oder diesem zuwiderläuft, treten mit Sicherheit Kompatibilitäts- und Sicherheitsprobleme auf. Und sie müssen gleichzeitig mit der Entscheidung abgedeckt werden. Jedes Mal. Wenn Sie diesen Rat befolgt haben und keine Sicherheitswarnungen gesehen haben, duplizieren Sie den Rat nicht im gesamten Internet. Seien Sie immer kritisch gegenüber der Entscheidung und finden Sie heraus, was schief gehen könnte .Anstelle eines Nachwortes
Auf welche Proxy-Server-Probleme sind Sie gestoßen? Was musste umgangen werden und wie?