Web Security: Eine Einführung in HTTP

Ursprünglicher Autor: Alex Nadalin
  • Übersetzung
HTTP ist eine schöne Sache: ein Protokoll, das seit über 20 Jahren ohne große Änderungen existiert.

Bild

Dies ist der zweite Teil der Websicherheitsserie: Der erste Teil lautete "Funktionsweise von Browsern ".

Wie wir im vorigen Artikel gesehen haben, interagieren Browser über HTTP mit Webanwendungen. Dies ist der Hauptgrund, warum wir uns mit diesem Thema beschäftigen. Wenn Benutzer ihre Kreditkartendaten auf der Website eingeben und der Angreifer die Daten abfangen kann, bevor er auf den Server gelangt, haben wir sicherlich Probleme.

Um zu verstehen, wie HTTP funktioniert, wie wir die Kommunikation zwischen Clients und Servern schützen können und welche sicherheitsrelevanten Funktionen das Protokoll bietet, ist dies der erste Schritt zur Verbesserung unserer Sicherheit.

Bei der Diskussion über HTTP müssen wir jedoch immer zwischen Semantik und technischer Implementierung unterscheiden, da dies zwei völlig unterschiedliche Aspekte des HTTP-Betriebs sind.

Der Hauptunterschied zwischen ihnen kann durch eine sehr einfache Analogie erklärt werden: Vor 20 Jahren pflegten die Menschen ihre Angehörigen genauso wie jetzt, auch wenn sich die Art und Weise, wie sie miteinander interagieren, erheblich verändert hat. Unsere Eltern werden wahrscheinlich ihr Auto nehmen und zu ihrer Schwester gehen, um aufzuholen und Zeit mit der Familie zu verbringen.

Stattdessen senden sie heutzutage häufig Nachrichten an WhatsApp, telefonieren oder verwenden eine Gruppe bei Facebook, was zuvor unmöglich war. Dies bedeutet nicht, dass Menschen mehr oder weniger miteinander kommunizieren oder sich um sie kümmern, sondern dass sich ihre Interaktion geändert hat.

HTTP ist nicht anders: Die Semantik des Protokolls hat sich nicht wesentlich geändert, während die technische Implementierung der Interaktion zwischen Clients und Servern im Laufe der Jahre optimiert wurde. Wenn Sie sich die HTTP-Anfrage von 1996 anschauen, wird sie den im vorherigen Artikel beschriebenen sehr ähnlich sein, auch wenn diese Pakete durch das Netzwerk gehen.

Bewertung


Wie wir gesehen haben, folgt HTTP einem Anforderungs- / Antwortmodell, wenn ein an einen Server angeschlossener Client eine Anfrage sendet und der Server darauf antwortet.

Eine HTTP-Nachricht (Anfrage oder Antwort) besteht aus mehreren Teilen:

  • "Erste Zeile" (erste Zeile)
  • Header (Anforderungsheader)
  • Körper

In der Anfrage gibt die erste Zeile die vom Client verwendete Methode an, den Pfad zu der gewünschten Ressource und die Version des Protokolls, das er verwenden wird:

GET /players/lebron-james HTTP/1.1

In diesem Fall versucht der Client, die Ressource ( GET) /Players/Lebron-Jamesdurch die Protokollversion zu bekommen 1.1- nichts unverständliches.

Nach der ersten Linie ermöglicht HTTP uns Metadaten auf die Nachricht durch die Header hinzufügen, die die Form von Schlüssel-Wert nehmen, getrennt durch einen Doppelpunkt: Zum Beispiel in dieser Abfrage hinzugefügt der Client auf die Anfrage 3 Extra - Header: , und . Warten Sie ?!?!

GET /players/lebron-james HTTP/1.1
Host: nba.com
Accept: */*
Coolness: 9000


HostAcceptCoolness

Coolness

Header sollten keine bestimmten, reservierten Namen verwenden, aber es wird normalerweise empfohlen, sich auf die in der HTTP-Spezifikation standardisierten Namen zu verlassen: Je mehr Sie von den Standards abweichen, desto weniger verstehen Sie den anderen Börsenteilnehmer.

Cache-Control- Dies ist beispielsweise der Header, mit dem bestimmt wird, ob (und wie) die Antwort zwischengespeichert werden kann: Die meisten Proxys und Reverse-Proxys verstehen es, indem sie der HTTP-Spezifikation vor dem Buchstaben folgen. Wenn Sie einen Titel umbenannt haben Cache-Controlim Awesome-Cache-ControlProxy würde keine Ahnung hat , wie die Antwort cachen, da sie nicht die Spezifikationen erfüllen sollen, die Sie gerade erfunden.

Es ist jedoch manchmal sinnvoll, einen "benutzerdefinierten" Header in die Nachricht aufzunehmen, da Sie Metadaten hinzufügen können, die eigentlich nicht Teil der HTTP-Spezifikation sind: Der Server kann technische Informationen in seine Antwort aufnehmen, sodass der Client gleichzeitig Anforderungen abrufen und wichtige Informationen darüber erhalten kann Status des Servers, der die Antwort zurückgibt: Wenn Sie benutzerdefinierte Header verwenden, ist es vorzuziehen, ihnen einen Schlüssel voranzustellen, damit sie nicht mit anderen Headern kollidieren Standard in der Zukunft: In der Vergangenheit hat es gut funktioniert, bis alle "Nicht-Standard" -Präfixe verwendet haben, die wiederum zur Norm wurden. Header und sind Beispiele für benutzerdefinierte Header

...
X-Cpu-Usage: 40%
X-Memory-Available: 1%
...


XX-Forwarded-ForX-Forwarded-Protoweit verbreitet und von Load Balancer und Proxies verstanden , auch wenn sie nicht Teil des HTTP-Standards sind .

Wenn Sie einen eigenen benutzerdefinierten Header hinzufügen müssen, ist es in der Regel besser, ein Firmenpräfix wie Acme-Custom-Headeroder zu verwenden A-Custom-Header.

Nach den Headern kann die Anfrage einen Body enthalten, der durch eine leere Zeile von den Headern getrennt ist: Unsere Anfrage ist abgeschlossen: die erste Zeile (Standort- und Protokollinformationen), Header und Body. Beachten Sie, dass der Rumpf vollständig optional ist und in den meisten Fällen nur dann verwendet wird, wenn wir Daten an den Server senden möchten, also die im obigen Beispiel verwendete Methode . Die Antwort macht keinen großen Unterschied:

POST /players/lebron-james/comments HTTP/1.1
Host: nba.com
Accept: */*
Coolness: 9000

Best Player Ever


POST



HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: private, max-age=3600

{"name": "Lebron James", "birthplace": "Akron, Ohio", ...}


Die erste Information, die in der Antwort gesendet wird, ist die Version des verwendeten Protokolls sowie der Status dieser Antwort. Folgen Sie dann den Kopfzeilen und ggf. dem Zeilenumbruch gefolgt vom Körper.

Wie bereits erwähnt, hat das Protokoll zahlreiche Revisionen durchlaufen und im Laufe der Zeit wurden neue Funktionen hinzugefügt (neue Header, Statuscodes usw.), aber die grundlegende Struktur hat sich nicht wesentlich geändert (erste Zeile, Header und Hauptteil). Was sich wirklich geändert hat, ist, wie Clients und Server diese Nachrichten austauschen - lassen Sie uns dies genauer betrachten.

HTTP vs. HTTPS vs. H2


Es gibt zwei bedeutende semantische Änderungen in HTTP: HTTP / 1.0und HTTP / 1.1.

"Wo ist HTTPS und HTTP2 ?", Fragen Sie.

HTTPS und HTTP2 (abgekürzt H2) sind eher technische Änderungen, da sie neue Möglichkeiten der Übermittlung von Nachrichten über das Internet eingeführt haben, ohne die Semantik des Protokolls wesentlich zu beeinträchtigen.

HTTPS ist eine "sichere" HTTP- Erweiterung und beinhaltet die Einrichtung eines gemeinsamen geheimen Schlüssels zwischen Client und Server. Dadurch wird sichergestellt, dass wir mit der richtigen Partei kommunizieren und Nachrichten verschlüsseln, die den gemeinsamen geheimen Schlüssel austauschen (mehr dazu später). Während HTTPS darauf abzielte, die Sicherheit des HTTP-Protokolls zu verbessern, zielte H2 mit hoher Geschwindigkeit ab.

H2 verwendet Binär- und keine Textnachrichten, unterstützt Multiplexing und verwendet den HPACK-Algorithmus für die Header-Komprimierung…. Kurz gesagt, H2 verbessert die HTTP / 1.1-Leistung.

Die Besitzer der Website wechselten widerstrebend zu HTTPS, da dies zusätzliche Problemumgehungen zwischen Client und Server beinhaltete (wie bereits erwähnt, müssen Sie einen gemeinsamen geheimen Schlüssel zwischen den beiden Parteien festlegen), was die Arbeit des Benutzers verlangsamt: Mit H2, das standardmäßig verschlüsselt ist, gibt es keine Entschuldigungen mehr , da Funktionen wie Multiplexing und Server-Push besser als einfaches HTTP / 1.1 sind .

Https


HTTPS (HTTP Secure) ermöglicht Clients und Servern die sichere Kommunikation über TLS (Transport Layer Security), dem Nachfolger von SSL (Secure Socket Layer).

Das Problem, auf das TLS fokussiert ist, ist ziemlich einfach und kann mit einer einfachen Metapher veranschaulicht werden: Die andere Hälfte ruft Sie mitten in dem Tag an, wenn Sie sich in einer Besprechung befinden, und fordert Sie auf, ihnen das Kennwort Ihres Online-Bankkontos mitzuteilen, da das Bankgeschäft ausgeführt werden muss Übersetzung, um pünktliche Bezahlung für die Ausbildung Ihres Sohnes zu gewährleisten. Es ist sehr wichtig, dass Sie dies jetzt melden, ansonsten besteht die Möglichkeit, dass Ihr Kind am nächsten Morgen aus der Schule entlassen wird.

Jetzt haben Sie zwei Probleme:

  • Authentifizierung dessen, was Sie wirklich mit Ihrem Seelenverwandten sprechen, weil es jemand sein könnte, der vorgibt, es zu sein
  • Verschlüsselung : Übertragen Sie ein Passwort, damit Ihre Kollegen es nicht verstehen und schreiben können

Was werden sie machen? Dies ist genau das Problem, das HTTPS zu lösen versucht.

Um zu überprüfen, mit wem Sie sich unterhalten, verwendet HTTPS Public-Key-Zertifikate. Hierbei handelt es sich lediglich um Zertifikate, die die Identität eines bestimmten Servers angeben: Wenn Sie sich über HTTPS mit einer IP-Adresse verbinden, wird der Server hinter dieser Adresse Sie repräsentieren Dieses Zertifikat dient dazu, Ihre Identität zu überprüfen. Um zu unserer Analogie zurückzukehren, können Sie einfach Ihren Seelenverwandten bitten, Ihre Sozialversicherungsnummer zu sagen. Sobald Sie sicherstellen, dass die Anzahl korrekt ist, erhalten Sie eine zusätzliche Vertrauensstufe.

Dies hindert "Eindringlinge" jedoch nicht daran, die Sozialversicherungsnummer des Opfers herauszufinden, das Smartphone der anderen Hälfte zu stehlen und Sie anzurufen. Wie überprüfen wir die Identität des Anrufers?

Anstatt Ihren Seelenverwandten direkt zu bitten, Ihre Sozialversicherungsnummer zu schreiben, rufen Sie stattdessen Ihre Mutter (die nebenan wohnt) an und bittet sie, in Ihre Wohnung zu gehen und sicherzustellen, dass Ihre andere Hälfte die Sozialversicherungsnummer sagt. Dies fügt eine zusätzliche Vertrauensstufe hinzu, da Sie Ihre Mutter nicht als Bedrohung betrachten und sich darauf verlassen, um die Identität des Anrufers zu überprüfen.

In Bezug auf HTTPS heißt Ihre Mutter "CA", kurz "Certificate Authority": Die Aufgabe von CA besteht darin, die Identität eines bestimmten Servers zu überprüfen und ein Zertifikat mit seiner eigenen digitalen Signatur auszustellen. Dies bedeutet, dass ich beim Herstellen einer Verbindung zu einer bestimmten Domäne kein vom Domäneninhaber generiertes Zertifikat (das so genannte selbstsignierte Zertifikat) bekomme Zertifikat ) und CA.

Die Aufgabe der Zertifizierungsstelle besteht darin, dass sie die Domäne authentifizieren und dementsprechend ein Zertifikat ausstellen: Wenn Sie ein Zertifikat "bestellen" (normalerweise als SSL-Zertifikat bezeichnet, obwohl TLS stattdessen verwendet wird - die Namen haften wirklich!), Kann die Zertifizierungsstelle Sie oder anrufen bitten Sie, die DNS-Einstellung zu ändern, um sicherzustellen, dass Sie die Kontrolle über diese Domäne haben. Nach Abschluss des Überprüfungsprozesses wird ein Zertifikat ausgestellt, das auf Webservern installiert werden kann.

Clients, wie z. B. Browser, stellen dann eine Verbindung zu Ihren Servern her und erhalten dieses Zertifikat, um ihre Authentizität zu überprüfen: Browser haben eine Art "Beziehung" zu CA, in dem Sinne, dass sie die Liste vertrauenswürdiger Domänen in CA nachverfolgen, um dies sicherzustellen Das Zertifikat ist wirklich vertrauenswürdig. Wenn das Zertifikat nicht von einer vertrauenswürdigen Stelle signiert ist, zeigt der Browser eine umfangreiche Informationswarnung für Benutzer an:

Bild

Wir sind zur Hälfte mit der Verbindung zwischen Ihnen und Ihrer anderen Hälfte verbunden: Nachdem wir uns authentifiziert haben (Anrufer-ID), müssen wir sicherstellen, dass wir sicher kommunizieren können, ohne dass andere in den Prozess eingreifen. Wie gesagt, Sie befinden sich mitten in der Besprechung und müssen Ihr Kennwort für das Online-Banking aufzeichnen. Sie müssen einen Weg finden, Ihre Kommunikation zu verschlüsseln, damit nur Sie und Ihr Seelenverwandter Ihre Konversation verstehen können.

Sie können dies tun, indem Sie einen gemeinsamen geheimen Schlüssel zwischen den beiden festlegen und Nachrichten mit diesem Schlüssel verschlüsseln. Beispielsweise können Sie die Caesar-Verschlüsselungsoption basierend auf Ihrem Hochzeitsdatum verwenden.

Bild

Dies funktioniert gut, wenn beide Parteien Beziehungen aufgebaut haben, wie Sie und Ihre andere Hälfte, da sie einen Schlüssel erstellen können, der auf Shared Memory basiert, über das niemand Bescheid weiß. Browser und Server können jedoch nicht denselben Mechanismus verwenden, da sie sich vorher nicht kennen.

Stattdessen werden Variationen des Diffie-Hellman-Schlüsselaustauschprotokolls verwendet , die sicherstellen, dass die Parteien ohne Vorkenntnisse einen gemeinsamen geheimen Schlüssel festlegen und niemand sonst diesen "stehlen" kann. Dies beinhaltet den Einsatz von Mathematik .

Bild

Sobald der geheime Schlüssel festgelegt ist, können Client und Server miteinander kommunizieren, ohne befürchten zu müssen, dass jemand ihre Nachrichten abfangen kann. Selbst wenn Angreifer dies tun, verfügen sie nicht über den gemeinsamen geheimen Schlüssel, der zum Entschlüsseln von Nachrichten erforderlich ist.

Für weitere Informationen zu HTTPS und Diffie-Hellman würde ich empfehlen, " Wie HTTPS schützt Verbindungen " von Hartley Brodie und " Wie funktioniert HTTPS tatsächlich?" Robert Heaton. Darüber hinaus enthält die neun Algorithmen, die die Zukunft verändert haben, ein erstaunliches Kapitel, in dem die Verschlüsselung mit öffentlichen Schlüsseln erläutert wird. Ich empfehle es wärmstens Informatikfans, die an Originalalgorithmen interessiert sind.

Https überall


Sie müssen noch entscheiden, ob Sie HTTPS auf Ihrer Website unterstützen sollen? Ich habe schlechte Nachrichten für Sie: Browser haben begonnen, Benutzer vor Websites zu schützen, die HTTPS nicht unterstützen, um Webentwickler zu zwingen, vollständig verschlüsselte Browserfunktionen bereitzustellen.

Hinter dem Motto „ HTTPS across “ widersetzten sich Browser unverschlüsselten Verbindungen. Google war der erste Browser-Anbieter, der Webentwicklern einen Abgabetermin gab. Er gab bekannt, dass er seit Chrome 68 (Juli 2018) HTTP-Websites als „unsicher“ kennzeichnen werde. :

Bild


Umso beunruhigender für Nicht-HTTPS-Websites ist die Tatsache, dass, sobald ein Benutzer etwas auf einer Webseite eingibt, das Etikett "Unsicher" rot angezeigt wird. In diesem Schritt sollten Benutzer vor dem Datenaustausch zwei Überlegungen anstellen mit Websites, die HTTPS nicht unterstützen.

Bild


Vergleichen Sie dies mit dem Aussehen der HTTPS-Website und einem gültigen Zertifikat:

Bild


Theoretisch sollte eine Website nicht sicher sein, aber in der Praxis werden Nutzer davon abgehalten - und das zu Recht. Damals, als H2 noch keine Realität war, wäre es sinnvoll, sich an unverschlüsseltem, einfachen HTTP-Verkehr zu halten. Derzeit gibt es wenig Grund dafür. Schließen Sie sich der Bewegung „HTTPS across“ an und helfen Sie, das Internet zu einem sichereren Ort zum Surfen zu machen .

GET vs POST


Wie wir bereits gesehen haben, beginnt die HTTP-Anfrage mit einer Art "erster Zeile":

Zuerst teilt der Client dem Server mit, welche Methoden er zur Ausführung der Anfrage verwendet: Die grundlegenden HTTP-Methoden enthalten GET, POST, PUT и DELETE,, die Liste kann jedoch mit weniger verbreiteten (aber immer noch standardmäßigen) Methoden fortgesetzt werden wie TRACE, OPTIONS, oder HEAD.

Theoretisch ist keine Methode sicherer als andere; In der Praxis sind die Dinge nicht so einfach.

GET-Anforderungen enthalten normalerweise keinen Nachrichtentext. Daher werden Parameter in URLs (beispielsweise www.example.com/articles?article_id=1) enthalten. POST-Anforderungen werden normalerweise zum Senden ("Veröffentlichen") von Daten verwendet, die im Textkörper enthalten sind. Ein weiterer Unterschied sind die Nebenwirkungen, die diese Methoden mit sich bringen:GET- idempotente Methode. Das bedeutet, dass unabhängig von der Anzahl der von Ihnen gesendeten Anforderungen der Status des Webservers nicht geändert wird. Stattdessen ist POSTes nicht idempotent: Für jede Anfrage, die Sie senden, können Sie den Status des Servers ändern (denken Sie zum Beispiel an, eine neue Zahlung zu tätigen. Jetzt verstehen Sie wahrscheinlich, warum Websites Sie bitten, die Seite bei der Ausführung einer Transaktion nicht zu aktualisieren).

Um den wichtigen Unterschied zwischen diesen Methoden zu veranschaulichen, müssen wir uns die Webserver-Protokolle ansehen, mit denen Sie möglicherweise bereits vertraut sind:

192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:39:47 +0000] "GET /?token=1234 HTTP/1.1" 200 525 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" 404 0.002 [example-local] 172.17.0.8:9090 525 0.002 200
192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:40:47 +0000] "GET / HTTP/1.1" 200 525 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" 393 0.004 [example-local] 172.17.0.8:9090 525 0.004 200
192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:41:34 +0000] "PUT /users HTTP/1.1" 201 23 "http://example.local/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36" 4878 0.016 [example-local] 172.17.0.8:9090 23 0.016 201


Wie Sie sehen, registrieren Webserver den Anforderungspfad. Dies bedeutet, wenn Sie vertrauliche Daten in Ihre URL aufnehmen, werden diese vom Webserver übersprungen und irgendwo in Ihren Protokollen gespeichert - Ihre vertraulichen Daten befinden sich irgendwo darin Klartext, den wir vollständig vermeiden müssen. Stellen Sie sich vor, ein Angreifer könnte Zugriff auf eine Ihrer alten Protokolldateien erhalten , die Kreditkartendaten, Zugriffstoken für Ihre privaten Dienste usw. enthalten können. Dies ist eine vollständige Katastrophe.

Webserver protokollieren keine HTTP-Header und -Körper, da die gespeicherten Daten zu umfangreich sein werden. Aus diesem Grund ist das Senden von Informationen durch den Hauptteil der Anforderung und nicht über die URL in der Regel sicherer. Von hier können wir das ableitenPOST(und ähnliche nicht idempotente Methoden) ist sicherer als GETselbst wenn es mehr darauf ankommt, wie die Daten mit einer bestimmten Methode gesendet werden, und nicht davon, dass eine bestimmte Methode wesentlich sicherer ist als andere: wenn Sie vertrauliche Informationen in den Körper einbeziehen Bitte GEThaben Sie nicht mehr Probleme als bei der Verwendung POST, selbst wenn ein solcher Ansatz als ungewöhnlich betrachtet würde.

Wir glauben an HTTP-Header


In diesem Artikel haben wir uns mit HTTP und dessen Entwicklung befasst und wie seine sichere Erweiterung Authentifizierung und Verschlüsselung kombiniert, um es Clients und Servern zu ermöglichen, Daten über einen sicheren Kanal auszutauschen. Dies ist nicht alles, was HTTP aus Sicherheitsgründen bieten kann.



Die Übersetzung wurde mit Unterstützung der Firma EDISON Software erstellt , die sich professionell mit Sicherheit befasst und elektronische Verifikationssysteme für die Medizin entwickelt .

Jetzt auch beliebt: