Web Security: Einführung in HTTP

HTTP ist eine schöne Sache: ein Protokoll, das seit mehr als 20 Jahren ohne große Änderungen existiert.



Dies ist Teil zwei der Web-Sicherheitsreihe: Teil eins war, wie Browser funktionieren .

Wie wir im vorherigen Artikel gesehen haben, interagieren Browser mit Webanwendungen über das HTTP-Protokoll. Dies ist der Hauptgrund, warum wir uns mit diesem Thema befassen. Wenn Benutzer ihre Kreditkarteninformationen auf der Website eingeben und ein Angreifer die Daten abfangen kann, bevor sie den Server erreichen, treten wahrscheinlich Probleme auf.

Der erste Schritt zur Verbesserung unserer Sicherheit besteht darin, zu verstehen, wie HTTP funktioniert, wie wir die Kommunikation zwischen Clients und Servern sichern können und welche sicherheitsrelevanten Funktionen das Protokoll bietet.

Bei der Erörterung von HTTP sollten wir jedoch immer zwischen Semantik und technischer Implementierung unterscheiden, da dies zwei völlig unterschiedliche Aspekte von HTTP sind.

Der Hauptunterschied zwischen ihnen lässt sich durch eine sehr einfache Analogie erklären: Vor 20 Jahren haben die Menschen ihre Verwandten genauso betreut wie heute, obwohl sich die Art und Weise, wie sie miteinander umgingen, erheblich verändert hat. Unsere Eltern werden wahrscheinlich ihr Auto nehmen und zu ihrer Schwester fahren, um etwas Zeit mit ihrer Familie zu verbringen.

Stattdessen senden sie heutzutage meistens Nachrichten an WhatsApp, telefonieren oder verwenden eine Gruppe auf Facebook, was bisher unmöglich war. Dies bedeutet nicht, dass Menschen mehr oder weniger kommunizieren oder sich um sie kümmern, sondern lediglich, 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 von Clients und Servern im Laufe der Jahre optimiert wurde. Wenn Sie sich die HTTP-Anforderung von 1996 ansehen, ist sie den im vorherigen Artikel beschriebenen sehr ähnlich, obwohl die Art und Weise, wie diese Pakete das Netzwerk passieren, sehr unterschiedlich ist.

Rückblick

Wie wir gesehen haben, folgt HTTP einem Anforderungs- / Antwortmodell, wenn ein mit einem Server verbundener Client eine Anforderung sendet und der Server darauf antwortet.

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

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

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

GET /players/lebron-james HTTP/1.1

In diesem Fall versucht der Client, die Ressource ( GET ) unter /Players/Lebron-James über Protokollversion 1.1 - nichts kompliziertes zu verstehen.

Nach der ersten Zeile können wir mit HTTP der Nachricht Metadaten über Header hinzufügen, die die Form eines Schlüsselwerts haben und durch einen Doppelpunkt getrennt sind:

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

In dieser Anforderung hat der Client der Anforderung beispielsweise drei zusätzliche Header hinzugefügt: Host , Accept und Coolness .

Warten Sie, Coolness ?!?!

Header sollten keine spezifischen, reservierten Namen verwenden. Es wird jedoch normalerweise empfohlen, sich auf diejenigen zu verlassen, die in der HTTP-Spezifikation standardisiert sind: Je mehr Sie von den Standards abweichen, desto weniger werden Sie von einem anderen Austauschteilnehmer verstanden.

Cache-Control ist beispielsweise ein Header, mit dem bestimmt wird, ob (und wie) eine Antwort zwischengespeichert werden kann: Die meisten Proxys und Reverse-Proxys verstehen dies, indem sie der HTTP-Spezifikation des Buchstabens folgen. Wenn Sie den Cache-Control Header in Awesome-Cache-Control umbenennen müssten, hätten die Proxys keine Ahnung, wie die Antwort zwischengespeichert werden soll, da sie nicht für die gerade erfundene Spezifikation ausgelegt sind.

Manchmal ist es jedoch sinnvoll, einen "benutzerdefinierten" Header in die Nachricht aufzunehmen, da Sie Metadaten hinzufügen können, die nicht wirklich Teil der HTTP-Spezifikation sind: Der Server kann sich dafür entscheiden, technische Informationen in seine Antwort aufzunehmen, damit der Client gleichzeitig Anforderungen ausführen und wichtige Informationen darüber erhalten kann Serverstatus, der eine Antwort zurückgibt:

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

Bei der Verwendung von benutzerdefinierten Headern ist es immer vorzuziehen, ein Präfix mit einem Schlüssel vor sich zu setzen, damit sie nicht mit anderen Headern in Konflikt stehen, die möglicherweise in Zukunft zum Standard werden. In der Vergangenheit funktionierte dies gut, bis alle Benutzer die nicht standardmäßigen X Präfixe verwendeten, die wiederum verwendet wurden die Norm. Die Header X-Forwarded-For und X-Forwarded-Proto sind Beispiele für benutzerdefinierte Header, die von Load Balancern und Proxys häufig verwendet und verstanden werden , auch wenn sie nicht Teil des HTTP-Standards sind .

Wenn Sie Ihren eigenen benutzerdefinierten Header hinzufügen müssen, ist es normalerweise am besten, ein proprietäres Präfix wie Acme-Custom-Header oder A-Custom-Header .

Nach den Überschriften kann die Anforderung einen Text enthalten, der durch eine leere Zeile von den Überschriften getrennt ist:

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

Best Player Ever


Unsere Anfrage ist abgeschlossen: erste Zeile (Standort- und Protokollinformationen), Header und Text. Bitte beachten Sie, dass der Body vollständig optional ist und in den meisten Fällen nur verwendet wird, wenn Daten an den Server gesendet werden sollen. POST wird im obigen Beispiel die POST Methode verwendet.

Die Antwort ist nicht anders:

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 zusammen mit dem Status dieser Antwort. Das Folgende sind die Überschriften und, falls erforderlich, ein Zeilenumbruch, gefolgt vom Text.

Wie bereits erwähnt, wurde das Protokoll mehrfach überarbeitet und im Laufe der Zeit wurden neue Funktionen hinzugefügt (neue Header, Statuscodes usw.), aber die Hauptstruktur hat sich nicht wesentlich geändert (erste Zeile, Header und Text). Was sich wirklich geändert hat, ist die Art und Weise, wie Clients und Server diese Nachrichten austauschen. Schauen wir uns das genauer an.

HTTP gegen HTTPS gegen H2

Es gab 2 signifikante semantische Änderungen in HTTP / 1.0 : HTTP / 1.0 und HTTP / 1.1.

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

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

HTTPS ist eine „sichere“ HTTP- Erweiterung und umfasst die Einrichtung eines gemeinsamen geheimen Schlüssels zwischen Client und Server, um sicherzustellen, dass wir mit der richtigen Partei kommunizieren und Nachrichten verschlüsseln, die einen gemeinsamen geheimen Schlüssel austauschen (dazu später mehr). Während HTTPS darauf abzielte, die Sicherheit des HTTP-Protokolls zu verbessern, zielte H2 darauf ab, eine hohe Geschwindigkeit bereitzustellen.

H2 verwendet eher binäre als Textnachrichten, unterstützt Multiplexing, verwendet den HPACK-Algorithmus zum Komprimieren von Headern ... ... Kurz gesagt, H2 verbessert die Leistung gegenüber HTTP / 1.1.

Websitebesitzer zögerten, auf HTTPS umzusteigen, da dies zusätzliche Problemumgehungen zwischen dem Client und dem Server beinhaltete (wie bereits erwähnt, muss ein gemeinsamer geheimer Schlüssel zwischen den beiden Parteien eingerichtet werden), wodurch der Benutzer verlangsamt wurde: Mit H2, das standardmäßig verschlüsselt ist, gibt es keine Ausreden mehr da Funktionen wie Multiplexing und Server-Push es besser machen als einfaches HTTP / 1.1 .

Https

Mit HTTPS (HTTP Secure) können Clients und Server sicher über TLS (Transport Layer Security), den Nachfolger von SSL (Secure Socket Layer), kommunizieren.

Das Problem, auf das sich TLS konzentriert, ist recht einfach und lässt sich mit einer einfachen Metapher veranschaulichen: Ihr Seelenverwandter ruft Sie mitten am Tag an, wenn Sie sich in einer Besprechung befinden, und bittet Sie, ihm das Passwort Ihres Online-Banking-Kontos mitzuteilen, da dies das Banking abschließen muss Überweisung, um sicherzustellen, dass die Ausbildung Ihres Sohnes rechtzeitig bezahlt wird. Es ist sehr wichtig, dass Sie dies sofort melden, da sonst die Gefahr besteht, dass Ihr Kind am nächsten Morgen von der Schule ausgeschlossen wird.

Jetzt stehen Sie vor zwei Problemen:

• Authentifizierung, dass du wirklich mit deiner Seelenverwandten sprichst, da es jemand sein kann, der vorgibt, sie zu sein
• Verschlüsselung : Übertragen Sie Ihr Passwort, damit Ihre Kollegen es nicht verstehen und aufschreiben können

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

Um zu überprüfen, mit wem Sie sprechen, verwendet HTTPS Public Key-Zertifikate (Public Key-Zertifikate), bei denen es sich lediglich um Zertifikate handelt, die die Identität eines bestimmten Servers angeben. Wenn Sie über HTTPS eine Verbindung zu einer IP-Adresse herstellen, werden Sie vom Server hinter dieser Adresse angezeigt Mit seinem Zertifikat können Sie Ihre Identität nachweisen. Zurück zu unserer Analogie: Sie können Ihren Seelenverwandten einfach bitten, Ihre Sozialversicherungsnummer anzugeben. Sobald Sie überprüfen, ob die Nummer korrekt ist, erhalten Sie ein zusätzliches Maß an Vertrauen.

Dies hindert „Angreifer“ jedoch nicht daran, die Sozialversicherungsnummer des Opfers herauszufinden, das Smartphone Ihres Seelenverwandten 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 bitten sie, in Ihre Wohnung zu gehen und sicherzustellen, dass Ihre andere Hälfte die Sozialversicherungsnummer sagt. Dies erhöht das Vertrauen, da Sie Ihre Mutter nicht als Bedrohung betrachten und sich darauf verlassen, dass sie die Identität des Anrufers überprüft.

In Bezug auf HTTPS heißt Ihre Mutter CA, kurz für Certificate Authority: Die Aufgabe einer CA besteht darin, die Identität eines bestimmten Servers zu überprüfen und ein Zertifikat mit einer eigenen digitalen Signatur auszustellen. Dies bedeutet, dass ich beim Herstellen einer Verbindung zu einer bestimmten Domain kein vom Domaininhaber generiertes Zertifikat (das sogenannte selbstsignierte) erhalte Zertifikat ) und CA.

Die Aufgabe der Zertifizierungsstelle besteht darin, die Authentizität der Domäne zu überprüfen und das Zertifikat entsprechend auszustellen: Wenn Sie ein Zertifikat "bestellen" (normalerweise als SSL-Zertifikat bezeichnet, obwohl derzeit TLS verwendet wird - die Namen bleiben wirklich erhalten!), Kann die Zertifizierungsstelle Sie anrufen oder Bitten Sie darum, die DNS-Einstellung zu ändern, um sicherzustellen, dass Sie diese Domäne steuern. Nach Abschluss des Überprüfungsprozesses wird ein Zertifikat ausgestellt, das dann auf den Webservern installiert werden kann.

Clients, z. B. Browser, stellen dann eine Verbindung zu Ihren Servern her und erhalten dieses Zertifikat, damit sie dessen Authentizität überprüfen können: Browser haben eine Art „Beziehung“ zur Zertifizierungsstelle, in dem Sinne, dass sie die Liste der vertrauenswürdigen Domänen in der Zertifizierungsstelle verfolgen, um dies sicherzustellen Das Zertifikat ist wirklich vertrauenswürdig. Wenn das Zertifikat nicht von einer vertrauenswürdigen Stelle signiert ist, zeigt der Browser eine große Informationswarnung für Benutzer an:



Wir sind auf halbem Weg, um die Kommunikation zwischen Ihnen und Ihrer anderen Hälfte sicherzustellen: Nachdem wir die Authentifizierung (Überprüfung der Identität des Anrufers) bestanden haben, müssen wir sicherstellen, dass wir sicher kommunizieren können, ohne dass andere in den Prozess eingreifen. Wie bereits erwähnt, befinden Sie sich mitten in der Besprechung und müssen Ihr Passwort für das Online-Banking aufschreiben. 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 Ihnen beiden festlegen und Nachrichten mit diesem Schlüssel verschlüsseln: Beispielsweise können Sie die Caesar-Verschlüsselungsoption basierend auf dem Datum Ihrer Hochzeit verwenden.



Dies funktioniert gut, wenn beide Parteien Beziehungen aufgebaut haben, wie Sie und Ihr Seelenverwandter, da sie einen Schlüssel basierend auf dem gemeinsamen Gedächtnis erstellen können, von dem niemand etwas weiß. Browser und Server können jedoch nicht denselben Mechanismus verwenden, da sie sich nicht im Voraus kennen.

Stattdessen werden Variationen des Diffie-Hellman-Schlüsselaustauschprotokolls verwendet, die sicherstellen, dass Parteien ohne Vorkenntnisse einen gemeinsamen geheimen Schlüssel einrichten und niemand sonst ihn „stehlen“ kann. Dies schließt die Verwendung von Mathematik ein .



Sobald der geheime Schlüssel installiert ist, können Client und Server kommunizieren, ohne befürchten zu müssen, dass jemand seine Nachrichten abfängt. Selbst wenn Angreifer dies tun, verfügen sie nicht über einen 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 Verbindungen schützt " von Hartley Brody und " Wie funktioniert HTTPS wirklich?" Zu lesen. »Robert Heaton. Darüber hinaus enthält Nine Algorithms That Changed the Future ein erstaunliches Kapitel, in dem die Verschlüsselung mit öffentlichen Schlüsseln erläutert wird, und ich empfehle es Informatik-Enthusiasten, die an Originalalgorithmen interessiert sind, wärmstens.

Https überall

Sie entscheiden immer noch, 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 Browsing-Funktionen bereitzustellen.

Unter dem Motto " HTTPS überall " lehnten Browser unverschlüsselte Verbindungen ab. Google war der erste Browser-Anbieter, der Webentwicklern eine Frist setzte, indem er bekannt gab, dass ab Chrome 68 (Juli 2018) HTTP-Websites als "unsicher" gekennzeichnet werden. ::



Noch beunruhigender für Websites, die HTTPS nicht nutzen, ist die Tatsache, dass das Etikett „Unsicher“ rot wird, sobald ein Benutzer etwas auf einer Webseite eingibt. Dieser Schritt sollte Benutzer dazu anregen, vor dem Datenaustausch zweimal nachzudenken. mit Websites, die HTTPS nicht unterstützen.



Vergleichen Sie dies mit dem Aussehen einer HTTPS-Site mit einem gültigen Zertifikat:



Theoretisch sollte eine Website nicht sicher sein, aber in der Praxis schreckt sie Benutzer ab - und das zu Recht. In den Tagen, in denen H2 keine Realität war, wäre es sinnvoll, sich an unverschlüsselten, einfachen HTTP-Verkehr zu halten. Dafür gibt es derzeit praktisch keinen Grund. Schließen Sie sich der HTTPS Everywhere-Bewegung an und machen Sie das Internet zu einem sichereren Ort zum Surfen .

GET vs POST

Wie wir bereits gesehen haben, beginnt eine HTTP-Anfrage mit einer Art „erster Zeile“:

Zunächst teilt der Client dem Server mit, welche Methoden er zum Ausführen der Anforderung verwendet: Zu den grundlegenden HTTP-Methoden gehören GET, POST, PUT DELETE, Die Liste kann jedoch mit weniger gebräuchlichen (aber immer noch standardmäßigen) Methoden wie TRACE, OPTIONS oder TRACE, OPTIONS werden HEAD

Theoretisch ist keine Methode sicherer als andere; in der Praxis ist nicht alles so einfach.

GET-Anforderungen enthalten normalerweise keinen Textkörper, daher sind Parameter in der URL enthalten (z. B. www.example.com/articles?article_id=1 ), während POST-Anforderungen normalerweise zum Senden ("Veröffentlichen") von Daten verwendet werden, die im Textkörper enthalten sind. Ein weiterer Unterschied sind die Nebenwirkungen dieser Methoden: GET ist eine idempotente Methode. Dies bedeutet, dass Sie den Status des Webservers nicht ändern, unabhängig davon, wie viele Anforderungen Sie senden. Stattdessen ist POST nicht idempotent: Für jede von Ihnen gesendete Anfrage können Sie den Status des Servers ändern (denken Sie beispielsweise an eine neue Zahlung - jetzt verstehen Sie wahrscheinlich, warum Websites Sie auffordern, die Seite beim Abschluss 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 können, protokollieren Webserver den Anforderungspfad: 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 in Klartext, den wir komplett vermeiden müssen. Stellen Sie sich vor, ein Angreifer könnte Zugriff auf eine Ihrer alten Protokolldateien erhalten , die Kreditkarteninformationen, Zugriffstoken für Ihre privaten Dienste usw. enthalten. Dies ist eine völlige Katastrophe.

Webserver protokollieren keine HTTP-Header und -Körper, da die gespeicherten Daten zu umfangreich sind. Daher ist das Senden von Informationen über den Anfragetext und nicht über die URL im Allgemeinen sicherer. Daraus können wir schließen, dass POST (und ähnliche nicht idempotente Methoden) sicherer als GET , auch wenn es mehr davon abhängt, 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 Hauptteil der GET Anfrage aufnehmen würden, hätten Sie nicht mehr Probleme als die Verwendung von POST , selbst wenn ein solcher Ansatz als ungewöhnlich angesehen würde.

Wir glauben an HTTP-Header

In diesem Artikel haben wir uns mit HTTP, seiner Entwicklung und der Kombination von Authentifizierung und Verschlüsselung durch die sichere Erweiterung befasst, damit Clients und Server über einen sicheren Kanal kommunizieren können. Dies ist nicht alles, was HTTP in Bezug auf Sicherheit zu bieten hat.

---

Die Übersetzung wurde von EDISON Software , einem professionellen Sicherheitsunternehmen , unterstützt und entwickelt auch elektronische medizinische Verifizierungssysteme .