Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Web Development
Code

HTTP kurz: HTTP-Zustand und Sicherheit

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called HTTP Succinctly.
HTTP Succinctly: HTTP Web Architecture

German (Deutsch) translation by Jenyia (you can also view the original English article)

In diesem letzten Kapitel befassen wir uns mit den Sicherheitsaspekten von HTTP, einschließlich der Identifizierung von Benutzern, der Funktionsweise der HTTP-Authentifizierung und der Frage, warum einige Szenarien HTTPS (Secure HTTP) erfordern. Auf dem Weg dorthin werden wir auch ein wenig darüber lernen, wie man den Zustand mit HTTP verwaltet.

Das zustandslose (noch zustandsvoll) Web

HTTP ist ein zustandsloses Protokoll, dh jede Anfrage-Antwort-Transaktion ist unabhängig von einer vorherigen oder zukünftigen Transaktion. Im HTTP-Protokoll ist nichts enthalten, was erfordert, dass ein Server Informationen über eine HTTP-Anforderung speichert. Der Server muss nur eine Antwort für jede Anfrage generieren. Jede Anfrage enthält alle Informationen, die ein Server zum Erstellen der Antwort benötigt.

Die zustandslose Natur von HTTP ist einer der treibenden Faktoren für den Erfolg des Webs. Die geschichteten Dienste, die wir im vorherigen Kapitel betrachtet haben, Dienste wie Caching, werden alle ermöglicht (oder zumindest einfacher), weil jede Nachricht alle Informationen enthält, die zur Verarbeitung der Nachricht erforderlich sind. Proxyserver und Webserver können Nachrichten prüfen, transformieren und zwischenspeichern. Ohne Caching konnte das Internet nicht skaliert werden, um den Anforderungen des Internets gerecht zu werden.

Die meisten Web-Anwendungen und -Dienste, die wir auf HTTP aufbauen, sind jedoch sehr Stateful.

Eine Bankanwendung möchte, dass sich ein Benutzer anmeldet, bevor der Benutzer seine kontobezogenen Ressourcen anzeigen kann. Wenn jede zustandslose Anforderung für eine private Ressource eintrifft, möchte die Anwendung sicherstellen, dass der Benutzer bereits authentifiziert wurde. Ein anderes Beispiel ist, wenn der Benutzer ein Konto öffnen und Formulare in einem dreiseitigen Assistenten ausfüllen möchte. Die Anwendung möchte sicherstellen, dass die erste Seite des Assistenten vollständig ist, bevor der Benutzer die zweite Seite senden kann.

Glücklicherweise gibt es viele Möglichkeiten, den Zustand in einer Webanwendung zu speichern. Ein Ansatz besteht darin, den Zustand in die Ressourcen einzubetten, die an den Client übertragen werden, so dass der gesamte von der Anwendung benötigte Zustand bei der nächsten Anforderung zurückkehrt. Dieser Ansatz erfordert in der Regel einige ausgeblendete Eingabefelder und funktioniert am besten für einen kurzlebigen Status (wie der Status, der für das Durchlaufen eines dreiseitigen Assistenten erforderlich ist). Durch das Einbetten des Zustands in die Ressource bleibt der gesamte Zustand in den HTTP-Nachrichten erhalten. Das ist ein hochskalierbarer Ansatz, der jedoch die Programmierung der Anwendung erschweren kann.

Eine weitere Option ist, den Zustand auf dem Server (oder hinter dem Server) zu speichern. Diese Option ist für einen Zustand erforderlich, der lange Zeit sein muss. Nehmen wir an, der Benutzer reicht ein Formular ein, um seine E-Mail-Adresse zu ändern. Die E-Mail-Adresse muss immer mit dem Benutzer verknüpft sein, sodass die Anwendung die neue Adresse übernehmen, die Adresse validieren und die Adresse in einer Datenbank oder Datei speichern oder einen Webdienst anrufen kann, damit sich jemand um das Speichern der Adresse kümmert.

Für die serverseitige Speicherung bieten viele Webentwicklungs-Frameworks wie ASP.NET auch Zugriff auf eine "Benutzersitzung". Die Sitzung kann sich im Speicher oder in einer Datenbank befinden, aber ein Entwickler kann Informationen in der Sitzung speichern und die Informationen bei jeder nachfolgenden Anforderung abrufen. Daten, die in einer Sitzung gespeichert werden, sind für einen einzelnen Benutzer (tatsächlich für die Browsersitzung des Benutzers) bestimmt und werden nicht von mehreren Benutzern gemeinsam genutzt.

Sitzungsspeicher hat ein einfaches Programmiermodell und ist nur für kurzlebige Zustände geeignet, da der Server schließlich davon ausgehen muss, dass der Benutzer die Site verlassen hat oder den Browser geschlossen hat und der Server die Sitzung verwerfen wird. Sitzungsspeicher kann, wenn er im Arbeitsspeicher gespeichert wird, die Skalierbarkeit beeinträchtigen, da nachfolgende Anforderungen an denselben Server gesendet werden müssen, auf dem sich die Sitzungsdaten befinden. Einige Load Balancer unterstützen dieses Szenario, indem sie "sticky sessions" implementieren.

Sie fragen sich vielleicht, wie ein Server einen Benutzer verfolgen kann, um den Sitzungsstatus zu implementieren. Wenn zwei Anfragen bei einem Server eintreffen, wie weiß der Server, ob es sich um zwei Anfragen desselben Benutzers handelt oder ob zwei verschiedene Benutzer jeweils eine einzige Anfrage stellen?

In den frühen Tagen des Webs hat die Server-Software möglicherweise unterschiedliche Benutzer, indem sie sich die IP-Adresse einer Anforderungsnachricht angesehen hat. Heutzutage jedoch leben viele Benutzer hinter Geräten, die die Netzwerkadressübersetzung verwenden. Aus diesem und anderen Gründen können mehrere Benutzer effektiv dieselbe IP-Adresse verwenden. Eine IP-Adresse ist keine zuverlässige Technik zur Unterscheidung von Benutzern.

Glücklicherweise gibt es zuverlässigere Techniken.


Identifizierung und Cookies

Websites, die Benutzer verfolgen möchten, wenden sich häufig Cookies zu. Cookies sind in RFC6265 (http://tools.ietf.org/html/rfc6265) definiert, und dieser RFC trägt den treffenden Titel "HTTP State Management Mechanism". Wenn ein Benutzer zum ersten Mal eine Website besucht, kann die Site dem Browser des Benutzers einen Cookie mit einem HTTP-Header geben. Der Browser weiß dann, dass er den Cookie in den Kopfzeilen jeder weiteren Anfrage senden muss, die er an die Site sendet. Unter der Annahme, dass die Website eine eindeutige Kennung in den Cookie eingefügt hat, kann die Site nun einen Benutzer nachverfolgen, wenn er Anforderungen stellt, und einen Benutzer von einem anderen unterscheiden.

Bevor wir näher darauf eingehen, wie Cookies aussehen und wie sie sich verhalten, sollten Sie einige Einschränkungen beachten. Erstens können Cookies Benutzer in dem Sinne identifizieren, dass sich Ihr Cookie von meinem Cookie unterscheidet, aber Cookies authentifizieren Benutzer nicht. Ein authentifizierter Benutzer hat seine Identität normalerweise durch die Angabe von Zugangsdaten wie Benutzername und Passwort nachgewiesen. Die Cookies, über die wir bisher gesprochen haben, geben uns nur eine eindeutige Kennung, um einen Benutzer von einer anderen zu unterscheiden, und verfolgen einen Benutzer, wenn Anfragen an die Site gestellt werden.

Zweitens, da Cookies verfolgen können, was ein Benutzer tut, werfen sie in einigen Kreisen Bedenken bezüglich des Datenschutzes auf. Einige Benutzer deaktivieren Cookies in ihren Browsern, was bedeutet, dass der Browser alle Cookies zurückweist, die ein Server in einer Antwort sendet. Deaktivierte Cookies stellen natürlich ein Problem für Websites dar, die Benutzer verfolgen müssen, und die Alternativen sind unordentlich. Zum Beispiel besteht ein Ansatz bei "Sitzungen ohne Cookies" darin, die Benutzerkennung in die URL zu setzen. Bei Sitzungen ohne Cookies ist es erforderlich, dass jede URL, die eine Site einem Benutzer gibt, den richtigen Bezeichner enthält, und die URLs werden viel größer (weshalb diese Technik oft als "fette URL" -Technik bezeichnet wird).


Einstellungvon Cookies

Wenn eine Website einem Benutzer einen Cookie geben möchte, verwendet sie einen Set-Cookie-Header in einer HTTP-Antwort.

Es gibt drei Informationsbereiche in dem Cookie, der in diesem Beispiel gezeigt wird. Die drei Bereiche sind durch Semikolons (;) voneinander getrennt. Erstens gibt es ein oder mehrere Name-Wert-Paare. Diese Name/Wert-Paare werden durch ein Dollarzeichen ($) begrenzt und ähneln sehr stark der Formatierung von Abfrageparametern in eine URL. Im Beispiel-Cookie wollte der Server den Vornamen und den Nachnamen des Benutzers im Cookie speichern. Der zweite und dritte Bereich sind die Domäne bzw. der Pfad. Wir werden später zurückkommen, um über Domain und Pfad zu sprechen.

Eine Website kann beliebige Informationen in einen Cookie einfügen, obwohl eine Größenbeschränkung von 4 KB besteht. Viele Websites geben jedoch nur einen eindeutigen Bezeichner für einen Benutzer an, möglicherweise eine GUID. Ein Server kann niemals einem auf dem Client gespeicherten Objekt vertrauen, sofern es nicht kryptographisch gesichert ist. Ja, es ist möglich, verschlüsselte Daten in einem Cookie zu speichern, aber es ist normalerweise einfacher, eine ID zu speichern.

Angenommen, der Browser ist so konfiguriert, dass er Cookies akzeptiert, sendet der Browser das Cookie bei jeder weiteren HTTP-Anfrage an den Server.

Wenn die ID eintrifft, kann die Server-Software schnell alle zugehörigen Benutzerdaten aus einer speicherinternen Datenstruktur, Datenbank oder einem verteilten Cache nachschlagen. Sie können die meisten Webanwendungs-Frameworks so konfigurieren, dass sie Cookies bearbeiten und den Sitzungsstatus automatisch nachschlagen. In ASP.NET stellt das Session-Objekt beispielsweise eine einfache API zum Lesen und Schreiben des Sitzungsstatus eines Benutzers bereit. Als Entwickler müssen wir uns nie darum sorgen, einen Set-Cookie-Header zu senden oder eingehende Cookies zu lesen, um den zugehörigen Sitzungsstatus zu finden. Hinter den Kulissen verwaltet ASP.NET den Session-Cookie.

Es lohnt sich, darauf hinzuweisen, dass die Daten firstName und lastName, die im Sitzungsobjekt gespeichert sind, nicht in den Cookie gelangen. Der Cookie enthält nur eine Sitzungskennung. Die der Sitzungskennung zugeordneten Werte sind auf dem Server sicher. Standardmäßig werden die Sitzungsdaten in eine speicherinterne Datenstruktur übertragen und bleiben für 20 Minuten am Leben. Wenn ein Sitzungscookie in einer Anfrage eingeht, ordnet ASP.NET dem Session objekt die richtigen Sitzungsdaten zu, nachdem die Benutzerdaten mit der im Cookie gespeicherten ID gefunden wurden. Wenn kein eingehendes Cookie mit einer Sitzungs-ID vorhanden ist, erstellt ASP.NET eins mit einem Set-Cookie-Header.

Ein Sicherheitsrisiko bei Sitzungskennungen besteht darin, wie sie die Möglichkeit eröffnen können, dass jemand die Sitzung eines anderen Benutzers entführt. Wenn ich zum Beispiel ein Tool wie Fiddler verwende, um den HTTP-Verkehr zu verfolgen, sehe ich möglicherweise einen Set-Cookie-Header von einem Server mit SessionID=12 innerhalb. Ich könnte vermuten, dass ein anderer Benutzer bereits eine SessionID von 11 hat, und eine HTTP-Anfrage mit dieser ID erstellen, nur um zu sehen, ob ich den HTML-Code für einen anderen Benutzer stehlen oder ansehen kann. Um dieses Problem zu bekämpfen, verwenden die meisten Webanwendungen große Zufallszahlen als Bezeichner (ASP.NET verwendet 120 Bit der Zufälligkeit). Eine ASP.NET-Sitzungs-ID sieht folgendermaßen aus: Es ist schwieriger zu erraten, wie die Sitzungs-ID einer anderen Person aussehen würde.


HttpOnly Cookies

Ein weiteres Sicherheitsrisiko bei Cookies besteht darin, wie anfällig sie für einen Cross-Site-Scripting-Angriff (XSS) sind. Bei einem XSS-Angriff injiziert ein böswilliger Benutzer bösartigen JavaScript-Code in die Website einer anderen Person. Wenn die andere Website das schädliche Skript an die Benutzer sendet, kann das bösartige Skript Cookie-Informationen ändern, prüfen und stehlen (was zu einem Session-Hijacking oder schlimmeren führen kann).

Um diese Sicherheitsanfälligkeit zu bekämpfen, führte Microsoft das HttpOnly-Flag ein (das im letzten Set-Cookie-Beispiel zu sehen ist). Das HttpOnly-Flag weist den Benutzeragenten an, den Skriptcode nicht auf den Cookie zugreifen zu lassen. Der Cookie existiert nur für "HTTP" -i.e. im Header jeder HTTP-Anforderungsnachricht zu reisen. Browser, die HttpOnly implementieren, erlauben JavaScript nicht, den Cookie auf dem Client zu lesen oder zu schreiben.


Arten von Cookies

Die Cookies, die wir bisher gesehen haben, sind Session-Cookies. Sitzungscookies existieren für eine einzelne Benutzersitzung und werden zerstört, wenn der Benutzer den Browser schließt. Persistente Cookies können eine einzelne Browsersitzung überleben und ein Benutzeragent speichert die Cookies auf der Festplatte. Sie können einen Computer herunterfahren und eine Woche später zurückkommen, auf Ihre Lieblingswebsite gehen, und ein persistenter Cookie wird immer noch für die erste Anfrage da sein.

Der einzige Unterschied zwischen den beiden besteht darin, dass ein persistenter Cookie einen Expires-Wert benötigt.

Ein Sitzungscookie kann einem Cookie explizit ein Discard-Attribut hinzufügen, aber ohne einen Expires-Wert sollte der Benutzeragent den Cookie in jedem Fall verwerfen.


Cookie-Pfade und Domänen

Bisher haben wir gesagt, dass sobald ein Cookie von einer Website gesetzt wurde, der Cookie mit jeder weiteren Anfrage zur Webseite weitergeleitet wird (vorausgesetzt, der Cookie ist nicht abgelaufen). Es werden jedoch nicht alle Cookies auf jede Website übertragen. Die einzigen Cookies, die ein User-Agent an eine Site senden soll, sind die Cookies, die der User-Agent von derselben Site erhält. Für Cookies von amazon.com wäre es nicht sinnvoll, eine HTTP-Anfrage an google.com zu stellen. Diese Art von Verhalten könnte nur zusätzliche Sicherheits- und Datenschutzprobleme auslösen. Wenn Sie in einer Antwort auf eine Anfrage an www.server.com einen Cookie setzen, wird der resultierende Cookie nur die Anfragen an www.server.com weiterleiten.

Eine Webanwendung kann auch den Umfang eines Cookies ändern, um den Cookie auf einen bestimmten Host oder eine Domäne und sogar auf einen bestimmten Ressourcenpfad zu beschränken. Die Webanwendung steuert den Bereich mithilfe der domain- und path attribute.

Das Domain-Attribut ermöglicht es einem Cookie, Sub-Domains zu überspannen. Mit anderen Worten, wenn Sie einen Cookie von www.server.com setzen, wird der Benutzeragent den Cookie nur an www.server.com übermitteln. Die Domäne im vorherigen Beispiel ermöglicht auch, dass das Cookie an eine beliebige URL in der Domäne "server.com" weitergeleitet wird, einschließlich "images.server.com", "help.server.com" und "einfach nur server.com". Sie können das Domänenattribut nicht für Domänenbereiche verwenden. Daher ist das Festlegen der Domäne auf .microsoft.com in einer Antwort auf .server.com nicht zulässig, und der Benutzeragent sollte das Cookie zurückweisen.

Das path attribut kann einen Cookie auf einen bestimmten Ressourcenpfad beschränken. Im vorherigen Beispiel wird der Cookie nur zu einer server.com-Site weitergeleitet, wenn die Anfrage-URL auf /stuff verweist, oder auf einen Ort unter /stuff wie /stuf/images. Pfadeinstellungen können dazu beitragen, Cookies zu organisieren, wenn mehrere Teams Webanwendungen auf unterschiedlichen Pfaden erstellen.


Cookie-Nachteile

Cookies ermöglichen es Websites, Informationen im Client zu speichern, und die Informationen werden bei nachfolgenden Anfragen an die Websites weitergeleitet. Die Vorteile der Web-Entwicklung sind enorm, denn Cookies ermöglichen es uns, zu verfolgen, welche Anfrage zu welchem Benutzer gehört. Aber Cookies haben einige Probleme, die wir bereits angesprochen haben.

Cookies sind, wie bereits erwähnt, anfällig für XSS-Angriffe und erhalten auch schlechte Werbung, wenn Websites (insbesondere Werbeseiten) Cookies von Drittanbietern verwenden, um Nutzer im Internet zu verfolgen. Cookies von Drittanbietern sind Cookies, die von einer anderen Domain als der Domain in der Adressleiste des Browsers gesetzt werden. Cookies von Drittanbietern bieten diese Möglichkeit, da viele Websites beim Senden einer Seitenressource an den Client Links zu Skripts oder Bildern anderer URLs enthalten. Durch die Anfragen, die an die anderen URLs gesendet werden, können die anderen Websites Cookies setzen.

Beispielsweise kann die Homepage von server.com ein <script>-Tag mit einer auf bigadvertising.com eingestellten Quelle enthalten. Dadurch kann bigadvertising.com einen Cookie liefern, während der Benutzer Inhalte von server.com anzeigt. Der Cookie kann nur auf bigadvertising.com zurückgehen, aber wenn genügend Websites bigadvertising.com verwenden, kann Big Advertising damit beginnen, einzelne Nutzer und die von ihnen besuchten Websites zu profilieren. In den meisten Webbrowsern können Sie Cookies von Drittanbietern deaktivieren (sie sind jedoch standardmäßig aktiviert).

Zwei der größten Nachteile von Cookies sind jedoch, wie sie Caching stören und wie sie Daten bei jeder Anfrage übertragen. Jede Antwort mit einem Set-Cookie-Header sollte nicht zwischengespeichert werden, zumindest nicht die Header, da dies die Benutzeridentifikation beeinträchtigen und Sicherheitsprobleme verursachen kann. Denken Sie auch daran, dass alles, was in einem Cookie gespeichert ist, sichtbar ist, wenn es über das Netzwerk läuft (und im Falle eines dauerhaften Cookies, wie es auf dem Dateisystem sitzt). Da wir wissen, dass es viele Geräte gibt, die HTTP-Verkehr hören und interpretieren können, sollte ein Cookie niemals vertrauliche Informationen speichern. Selbst Sitzungsbezeichner sind riskant, denn wenn jemand die ID eines anderen Benutzers abfangen kann, kann er die Sitzungsdaten vom Server stehlen.

Trotz all dieser Nachteile gehen Cookies nicht weg. Manchmal brauchen wir den Status, um über HTTP zu reisen, und Cookies bieten diese Möglichkeit auf einfache, meist transparente Weise. Eine andere Fähigkeit, die wir manchmal brauchen, ist die Fähigkeit, den Benutzer zu authentifizieren. Als nächstes werden wir die Authentifizierungsfunktionen besprechen.


Authentifizierung

Der Prozess der Authentifizierung zwingt einen Benutzer, seine Identität zu beweisen, indem er einen Benutzernamen und ein Passwort, eine E-Mail und eine PIN oder eine andere Art von Anmeldeinformationen eingibt.

Auf Netzwerkebene folgt die Authentifizierung typischerweise einem Abfrage- / Antwortformat. Der Client fordert eine sichere Ressource an und der Server fordert den Client zur Authentifizierung auf. Der Client muss dann eine weitere Anfrage senden und Authentifizierungsdaten für den zu überprüfenden Server angeben. Wenn die Anmeldeinformationen gut sind, wird die Anforderung erfolgreich ausgeführt.

Die Erweiterbarkeit von HTTP ermöglicht es HTTP, verschiedene Authentifizierungsprotokolle zu unterstützen. In diesem Abschnitt werden wir uns kurz die Top 5 ansehen: Basic, Digest, Windows, Forms und OpenID. Von diesen fünf sind nur zwei in der HTTP-Spezifikation "offiziell" - die Basic- und Digest-Authentifizierungsprotokolle. Wir werden uns diese beiden zuerst ansehen.


Standardauthentifizierung

Bei der Standardauthentifizierung fordert der Client zunächst eine Ressource mit einer normalen HTTP-Nachricht an.

Webserver können Sie den Zugriff auf bestimmte Dateien und Verzeichnisse konfigurieren. Sie können den Zugriff auf alle anonymen Benutzer zulassen oder den Zugriff beschränken, sodass nur bestimmte Benutzer oder Gruppen auf eine Datei oder ein Verzeichnis zugreifen können. Stellen wir uns für die vorherige Anfrage vor, dass der Server so konfiguriert ist, dass nur bestimmte Benutzer die Ressource /html5/ anzeigen können. In diesem Fall wird der Server eine Authentifizierungsanfrage stellen.

Der 401-Statuscode teilt dem Client mit, dass die Anfrage nicht autorisiert ist. Der WWW-Authenticate-Header weist den Client an, die Benutzeranmeldeinformationen zu sammeln und es erneut zu versuchen. Das Realm-Attribut gibt dem Benutzeragenten eine Zeichenfolge, die er als Beschreibung für den geschützten Bereich verwenden kann. Was als nächstes passiert, hängt vom Benutzeragenten ab, aber die meisten Browser können eine Benutzeroberfläche anzeigen, auf der der Benutzer Anmeldeinformationen eingeben kann.

Figure 8: Authentication dialog
Authentifizierungsdialog

Mit den Zugangsdaten kann der Browser eine weitere Anfrage an den Server senden. Diese Anfrage enthält einen Authorization header.

Der Wert des Autorisierungsheaders ist der Benutzername und das Kennwort des Clients in einer Basis-64-Codierung. Die Standardauthentifizierung ist standardmäßig unsicher, da jeder Benutzer mit einem Basis-64-Decoder, der die Nachricht anzeigen kann, das Kennwort eines Benutzers stehlen kann. Aus diesem Grund wird die Standardauthentifizierung selten ohne die Verwendung von sicherem HTTP verwendet, auf das wir später eingehen werden.

Es liegt an dem Server, den Berechtigungsheader zu dekodieren und den Benutzernamen und das Kennwort mit dem Betriebssystem oder dem Anmeldeinformationsverwaltungssystem auf dem Server zu überprüfen. Wenn die Anmeldeinformationen übereinstimmen, kann der Server eine normale Antwort geben. Wenn die Anmeldeinformationen nicht übereinstimmen, sollte der Server erneut mit einem 401-Status antworten.


Digestauthentifizierung

Die Digestauthentifizierung ist eine Verbesserung gegenüber der Standardauthentifizierung, da sie keine Benutzerkennwörter mit der Basis-64-Codierung (die im Wesentlichen das Kennwort im Klartext überträgt) überträgt. Stattdessen muss der Client einen Auszug des Kennworts senden. Der Client berechnet den Digest mithilfe des MD5-Hashalgorithmus mit einer Nonce, die der Server während der Authentifizierungsanforderung bereitstellt (eine Nonce ist eine kryptografische Nummer, die zur Verhinderung von Replay-Angriffen verwendet wird).

Die Digest-Challenge-Antwort ähnelt der einfachen Authentifizierungs-Challenge-Antwort, jedoch mit zusätzlichen Werten, die vom Server im WWW-Authenticate-Header zur Verwendung in den kryptografischen Funktionen kommen.

Die Digestauthentifizierung ist besser als die Standardauthentifizierung, wenn sicheres HTTP nicht verfügbar ist, aber es ist noch lange nicht perfekt. Die Digestauthentifizierung ist immer noch anfällig für man-in-the-middle-Angriffe, bei denen jemand den Netzwerkverkehr überwacht.


Windows-Authentifizierung

Windows Integrated Authentication ist kein Standardauthentifizierungsprotokoll, aber es ist beliebt unter Microsoft-Produkten und Servern. Obwohl Windows-Authentifizierung von vielen modernen Browsern (nicht nur Internet Explorer) unterstützt wird, funktioniert es nicht gut über das Internet oder wo sich Proxy-Server befinden. Sie finden es häufig auf internen und Intranet-Websites, auf denen ein Microsoft Active Directory-Server vorhanden ist.

Die Windows-Authentifizierung hängt von den zugrunde liegenden Authentifizierungsprotokollen ab, die von Windows unterstützt werden, einschließlich NTLM und Kerberos. Die Windows-Authentifizierungs-Challenge/Response-Schritte ähneln denen, die wir bereits gesehen haben, aber der Server wird NTLM oder Negotiate im WWW-Authenticate-Header angeben (Negotiate ist ein Protokoll, mit dem der Client Kerberos oder HTML auswählen kann).

Die Windows-Authentifizierung hat den Vorteil, dass sie auch ohne die Verwendung von sicherem HTTP sicher ist und dass sie für Benutzer von Internet Explorer unauffällig ist. Der IE authentifiziert einen Benutzer automatisch, wenn er von einem Server dazu aufgefordert wird, und verwendet dabei die Anmeldeinformationen des Benutzers, mit denen er sich beim Windows-Betriebssystem angemeldet hat.


Formularbasierte Authentifizierung

Die Formularauthentifizierung ist der beliebteste Ansatz für die Benutzerauthentifizierung über das Internet. Die formularbasierte Authentifizierung ist kein Standardauthentifizierungsprotokoll und verwendet keine WWW-Authenticate- oder Authorization header. Viele Webanwendungs-Frameworks bieten jedoch einige vorkonfigurierte Unterstützung für die formularbasierte Authentifizierung.

Bei der formularbasierten Authentifizierung reagiert eine Anwendung auf eine Anfrage nach einer sicheren Ressource durch einen anonymen Benutzer, indem sie den Benutzer auf eine Anmeldeseite umleitet. Die Weiterleitung ist eine temporäre HTTP 302-Weiterleitung. Im Allgemeinen kann die URL, die der Benutzer anfordert, in der Abfragezeichenfolge des Umleitungsorts enthalten sein, so dass die Anwendung den Benutzer, nachdem der Benutzer die Anmeldung abgeschlossen hat, zu der sicheren Ressource umleiten kann, die er erreichen wollte.

Die Anmeldeseite für die formularbasierte Authentifizierung ist ein HTML-Formular mit Eingaben für die Eingabe von Anmeldeinformationen durch den Benutzer. Wenn der Benutzer auf "Senden" klickt, werden die Formularwerte an ein POST gesendet, an dem die Anwendung die Anmeldeinformationen übernehmen und sie anhand eines Datenbankeintrags oder Betriebssystems überprüfen muss.

Beachten Sie, dass die formularbasierte Authentifizierung die Anmeldeinformationen eines Benutzers im Nur-Text-Format überträgt. Wie bei der Standardauthentifizierung ist die formularbasierte Authentifizierung nicht sicher, es sei denn, Sie verwenden sicheres HTTP. Als Reaktion auf die POST-Nachricht mit Anmeldeinformationen (vorausgesetzt, die Anmeldeinformationen sind gut), leitet die Anwendung den Benutzer typischerweise zurück an die sichere Ressource und setzt auch ein Cookie, das angibt, dass der Benutzer jetzt authentifiziert ist.

Für ASP.NET wird das Authentifizierungsticket (der Cookie-Wert .ASPXAUTH) verschlüsselt und gehackt, um Manipulationen zu verhindern. Ohne sicheres HTTP ist das Cookie jedoch anfällig für Abfangen, so dass das Session-Hijacking immer noch ein potentielles Problem darstellt. Dennoch bleibt die Formularauthentifizierung beliebt, da sie den Anwendungen vollständige Kontrolle über die Anmeldeerfahrung und die Validierung von Anmeldeinformationen ermöglicht.


OpenID

Während die formularbasierte Authentifizierung der Anwendung eine vollständige Kontrolle über die Benutzerauthentifizierung gibt, möchten viele Anwendungen diese Kontrollebene nicht. Insbesondere möchten Anwendungen Benutzernamen und Kennwörter nicht verwalten und überprüfen (und Benutzer möchten nicht für jede Website einen anderen Benutzernamen und ein anderes Kennwort haben). OpenID ist ein offener Standard für die dezentrale Authentifizierung. Mit OpenID registriert sich ein Benutzer bei einem OpenID-Identitätsprovider, und der Identitätsanbieter ist der einzige Standort, der Benutzeranmeldeinformationen speichern und überprüfen muss. Es gibt viele OpenID-Anbieter, darunter Google, Yahoo und Verisign.

Wenn eine Anwendung einen Benutzer authentifizieren muss, arbeitet sie mit dem Benutzer und dem Identitätsanbieter des Benutzers zusammen. Der Benutzer muss seinen Benutzernamen und sein Passwort beim Identitätsanbieter überprüfen, aber die Anwendung weiß dank der Anwesenheit kryptografischer Token und Geheimnisse, ob die Authentifizierung erfolgreich ist. Google hat einen Überblick über den Prozess auf der Webseite "Verbundanmeldung für Google-Kontobenutzer" (https://developers.google.com/accounts/docs/OpenID).

Obwohl OpenID im Vergleich zur Formularauthentifizierung viele potenzielle Vorteile bietet, hat es aufgrund der Komplexität bei der Implementierung, dem Debugging und der Pflege des OpenID-Login-Tanzes zu wenig Akzeptanz gefunden. Wir müssen hoffen, dass sich die Toolkits und Frameworks weiter entwickeln, um den OpenID-Ansatz für die Authentifizierung zu vereinfachen.


Sicheres HTTP

Zuvor haben wir erwähnt, dass die selbstbeschreibenden textlichen HTTP-Nachrichten eine der Stärken des Webs sind. Jeder kann eine Nachricht lesen und verstehen, was drin ist. Aber es gibt viele Nachrichten, die wir über das Internet senden, von denen wir nicht wollen, dass sie jemand anderes sieht. Wir haben einige dieser Szenarien in diesem Buch besprochen. Wir möchten nicht, dass jemand anderes im Netzwerk unsere Passwörter sieht, aber wir möchten auch nicht, dass sie unsere Kreditkartennummern oder Bankkontonummern sehen. Secure HTTP löst dieses Problem, indem Nachrichten verschlüsselt werden, bevor die Nachrichten über das Netzwerk übertragen werden.

Sicheres HTTP wird auch als HTTPS bezeichnet (weil es anstelle eines regulären HTTP-Schemas ein HTTPS-Schema in der URL verwendet). Der Standardport für HTTP ist Port 80 und der Standardport für HTTPS ist Port 443. Je nach Schema wird der Browser mit dem richtigen Port verbunden (es sei denn, er muss einen expliziten Port verwenden, der in der URL vorhanden ist). HTTPS arbeitet mit einer zusätzlichen Sicherheitsebene im Netzwerkprotokollstapel. Die Sicherheitsschicht befindet sich zwischen den HTTP- und TCP-Schichten und bietet die Verwendung des Transport Layer Security-Protokolls (TLS) oder des TLS-Vorgängers, der als Secure Sockets Layer (SSL) bekannt ist.

Figure 9: Secure HTTP protocol layers
Sichere HTTP-Protokollschichten

HTTPS erfordert, dass ein Server über ein kryptografisches Zertifikat verfügt. Das Zertifikat wird während der Einrichtung der HTTPS-Kommunikation an den Client gesendet. Das Zertifikat enthält den Hostnamen des Servers, und ein Benutzeragent kann das Zertifikat verwenden, um zu bestätigen, dass es wirklich mit dem Server kommuniziert, von dem es denkt, dass es mit ihm spricht. Die Validierung wird durch die Kryptografie mit öffentlichen Schlüsseln und die Existenz von Zertifizierungsstellen wie Verisign ermöglicht, die die Integrität eines Zertifikats signieren und verbürgen. Administratoren müssen Zertifikate von den Zertifizierungsstellen erwerben und installieren.

Es gibt viele kryptografische Details, die wir abdecken könnten, aber aus der Perspektive eines Entwicklers sind die wichtigsten Dinge, die Sie über HTTPS wissen sollten:

  • Der gesamte Datenverkehr über HTTPS wird in der Anforderung und in der Antwort verschlüsselt, einschließlich der HTTP-Header und des Nachrichtentexts sowie nach dem Hostnamen in der URL. Das bedeutet, dass die Pfad- und Abfragezeichenfolgedaten sowie alle Cookies verschlüsselt sind. HTTPS verhindert Session-Hijacking, da keine Lauscher eine Nachricht prüfen und einen Cookie stehlen können.
  • Der Server wird durch das Serverzertifikat für den Client authentifiziert.  Wenn Sie mit mybigbank.com über HTTPS sprechen, können Sie sicher sein, dass Ihre Nachrichten tatsächlich an mybigbank.com gesendet werden und nicht an jemanden, der einen Proxy-Server im Netzwerk festhielt, um Anfragen abzufangen und Antwortdaten von mybigbank.com zu spoofieren.
  • HTTPS authentifiziert den Client nicht. Anwendungen müssen noch die Formularauthentifizierung oder eines der anderen zuvor erwähnten Authentifizierungsprotokolle implementieren, wenn sie die Identität des Benutzers kennen müssen. HTTPS macht die formularbasierte Authentifizierung und die grundlegende Authentifizierung sicherer, da alle Daten verschlüsselt sind. Es besteht die Möglichkeit, clientseitige Zertifikate mit HTTPS zu verwenden, und clientseitige Zertifikate würden den Client auf die sicherste Weise authentifizieren. Clientseitige Zertifikate werden jedoch im offenen Internet normalerweise nicht verwendet, da nicht viele Benutzer ein persönliches Zertifikat kaufen und installieren. Unternehmen benötigen möglicherweise Clientzertifikate, damit Mitarbeiter auf Unternehmensserver zugreifen können. In diesem Fall kann das Unternehmen jedoch als Zertifizierungsstelle fungieren und von ihnen erstellte und verwaltete Mitarbeiterzertifikate ausstellen.

HTTPS hat einige Nachteile und die meisten hängen mit der Leistung zusammen. HTTPS ist rechenintensiv, und große Sites verwenden häufig spezialisierte Hardware (SSL-Beschleuniger), um die Belastung durch die kryptographische Berechnung von den Webservern zu nehmen. HTTPS-Datenverkehr kann auch nicht in einem öffentlichen Cache zwischengespeichert werden, aber Benutzeragenten können HTTPS-Antworten in ihrem privaten Cache behalten. Schließlich sind HTTPS-Verbindungen teuer in der Einrichtung und erfordern einen zusätzlichen Handshake zwischen dem Client und dem Server, um kryptografische Schlüssel auszutauschen und sicherzustellen, dass alle mit dem richtigen sicheren Protokoll kommunizieren. Persistente Verbindungen können dazu beitragen, diese Kosten zu amortisieren.

Am Ende, wenn Sie sichere Kommunikation benötigen, zahlen Sie gerne die Leistungsstrafen.


Wo sind wir?

In diesem Artikel haben wir uns Cookies, Authentifizierung und sicheres HTTP angeschaut. Wenn Sie die gesamte Sitzung abgeschlossen haben, hoffe ich, dass Sie einige nützliche Informationen gefunden haben, die Ihnen beim Schreiben, Warten und Debuggen von Webanwendungen helfen.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.