HTTP-Authentifizierung
HTTP bietet einen allgemeinen Rahmen für Zugangskontrolle und Authentifizierung. Diese Seite ist eine Einführung in das HTTP-Framework für Authentifizierung und zeigt, wie Sie den Zugriff auf Ihren Server mithilfe des HTTP-"Basic"-Schemas einschränken können.
Das allgemeine HTTP-Authentifizierungsframework
RFC 7235 definiert das HTTP-Authentifizierungsframework, das von einem Server verwendet werden kann, um eine Challenge an eine Client-Anfrage zu senden und von einem Client, um Authentifizierungsinformationen bereitzustellen.
Der Ablauf von Challenge und Antwort funktioniert folgendermaßen:
- Der Server antwortet einem Client mit einem
401(Unauthorized) Antwortstatus und liefert Informationen, wie man mit einemWWW-AuthenticateAntwortheader, der mindestens eine Challenge enthält, autorisiert werden kann. - Ein Client, der sich beim Server authentifizieren möchte, kann dies tun, indem er einen
AuthorizationAnforderungsheader mit den Anmeldedaten einschließt. - In der Regel wird dem Benutzer eine Eingabeaufforderung für ein Passwort angezeigt, und der Client wird die Anfrage mit dem korrekten
Authorization-Header ausführen.
Der oben beschriebene allgemeine Nachrichtenfluss ist derselbe für die meisten (wenn nicht alle) Authentifizierungsschemata. Die eigentlichen Informationen in den Headers und die Art und Weise, wie sie codiert sind, ändern sich jedoch!
Warnung: Das oben im Diagramm verwendete "Basic"-Authentifizierungsschema sendet die Anmeldedaten codiert, aber nicht verschlüsselt. Dies wäre völlig unsicher, es sei denn, der Austausch erfolgt über eine sichere Verbindung (HTTPS/TLS).
Proxy-Authentifizierung
Der gleiche Mechanismus von Challenge und Antwort kann für die Proxy-Authentifizierung verwendet werden. Da sowohl Ressourcen-Authentifizierung als auch Proxy-Authentifizierung nebeneinander bestehen können, wird ein anderes Set von Headers und Status-Codes benötigt. Im Fall von Proxies ist der Herausforderungs-Statuscode 407 (Proxy Authentication Required), der Proxy-Authenticate Antwortheader enthält mindestens eine auf den Proxy anwendbare Challenge, und der Proxy-Authorization Anforderungsheader wird verwendet, um die Anmeldedaten dem Proxy-Server bereitzustellen.
Zugriff verweigert
Erhält ein (Proxy-)Server ungültige Anmeldedaten, sollte er mit einem 401 Unauthorized oder einem 407 Proxy Authentication Required antworten, und der Benutzer kann eine neue Anfrage senden oder das Authorization-Header-Feld ersetzen.
Erhält ein (Proxy-)Server gültige Anmeldedaten, die unzureichend sind, um auf eine bestimmte Ressource zuzugreifen, sollte der Server mit dem 403 Forbidden Statuscode reagieren. Im Gegensatz zu 401 Unauthorized oder 407 Proxy Authentication Required ist eine Authentifizierung für diesen Benutzer unmöglich, und Browser werden keinen neuen Versuch vorschlagen.
In allen Fällen kann der Server es vorziehen, einen 404 Not Found Statuscode zurückzugeben, um die Existenz der Seite einem Benutzer ohne ausreichende Berechtigungen oder nicht korrekt authentifiziert zu verbergen.
Authentifizierung von Cross-Origin-Bildern
Ein potenzielles Sicherheitsproblem (das inzwischen in Browsern behoben wurde) war die Authentifizierung von Cross-Site-Bildern. Ab Firefox 59 können Bildressourcen, die aus anderen Ursprüngen als dem aktuellen Dokument geladen werden, keine HTTP-Authentifizierungsdialoge mehr auslösen (Firefox-Bug 1423146), wodurch verhindert wird, dass Benutzeranmeldeinformationen gestohlen werden, wenn Angreifer in der Lage waren, ein beliebiges Bild in eine Drittanbieter-Seite einzubetten.
Zeichencodierung der HTTP-Authentifizierung
Browser verwenden utf-8-Codierung für Benutzernamen und Passwörter.
Firefox verwendete früher ISO-8859-1, wechselte jedoch zu utf-8, um mit anderen Browsern gleichzuziehen und mögliche Probleme zu vermeiden, wie in Firefox-Bug 1419658 beschrieben.
WWW-Authenticate und Proxy-Authenticate Headers
Die WWW-Authenticate und Proxy-Authenticate Antwortheaders definieren die Authentifizierungsmethode, die verwendet werden sollte, um auf eine Ressource zuzugreifen. Sie müssen angeben, welches Authentifizierungsschema verwendet wird, damit der Client, der sich autorisieren möchte, weiß, wie er die Anmeldedaten bereitstellen muss.
Die Syntax für diese Headers ist wie folgt:
WWW-Authenticate: <type> realm=<realm>
Proxy-Authenticate: <type> realm=<realm>
Hierbei ist <type> das Authentifizierungsschema ("Basic" ist das häufigste Schema und wird unten eingeführt). Der realm wird verwendet, um den geschützten Bereich zu beschreiben oder den Schutzumfang anzugeben. Dies könnte eine Nachricht wie "Zugang zur Staging-Site" oder Ähnliches sein, sodass der Benutzer weiß, zu welchem Bereich er Zugang erhalten möchte.
Authorization und Proxy-Authorization Headers
Die Authorization und Proxy-Authorization Anforderungsheaders enthalten die Anmeldedaten, um einen User Agent bei einem (Proxy-)Server zu authentifizieren. Hier wird <type> erneut benötigt, gefolgt von den Anmeldedaten, die je nach verwendetem Authentifizierungsschema codiert oder verschlüsselt sein können.
Authorization: <type> <credentials>
Proxy-Authorization: <type> <credentials>
Authentifizierungsschemata
Das allgemeine HTTP-Authentifizierungsframework bildet die Grundlage für eine Reihe von Authentifizierungsschemata.
IANA führt eine Liste von Authentifizierungsschemata, aber es gibt andere von Hostdiensten angebotene Schemata, wie z.B. Amazon AWS.
Einige häufige Authentifizierungsschemata umfassen:
- Basic
-
Siehe RFC 7617, base64-codierte Anmeldedaten. Weitere Informationen unten.
- Bearer
-
Siehe RFC 6750, Bearer-Tokens für den Zugriff auf durch OAuth 2.0 geschützte Ressourcen
- Digest
-
Siehe RFC 7616. Firefox 93 und später unterstützen den SHA-256-Algorithmus. Frühere Versionen unterstützen nur MD5-Hashing (nicht empfohlen).
- HOBA
-
Siehe RFC 7486, Abschnitt 3, HTTP Origin-Bound Authentication, signaturbasierte Authentifizierung
- Mutual
-
Siehe RFC 8120
- Negotiate / NTLM
-
Siehe RFC4599
- VAPID
-
Siehe RFC 8292
- SCRAM
-
Siehe RFC 7804
- AWS4-HMAC-SHA256
-
Siehe AWS-Dokumentation. Dieses Schema wird für die AWS3-Serverauthentifizierung verwendet.
Schemata können sich in Sicherheitsstärke und Verfügbarkeit in Client- oder Server-Software unterscheiden.
Das "Basic"-Authentifizierungsschema bietet sehr geringe Sicherheit, ist jedoch weit verbreitet und einfach einzurichten. Es wird im Folgenden ausführlicher behandelt.
Basic-Authentifizierungsschema
Das "Basic" HTTP-Authentifizierungsschema ist in RFC 7617 definiert, welches Anmeldedaten als Benutzer-ID/Passwort-Paare überträgt, die mit base64 codiert sind.
Sicherheit der Basic-Authentifizierung
Da die Benutzer-ID und das Passwort als Klartext über das Netzwerk übertragen werden (sie sind base64-codiert, aber base64 ist eine umkehrbare Codierung), ist das Basic-Authentifizierungsschema nicht sicher. HTTPS/TLS sollte mit Basic-Authentifizierung verwendet werden, um die Abfangung von Anmeldedaten zu verhindern.
Darüber hinaus sind Seiten, die HTTP Basic Auth verwenden, besonders anfällig für Cross-Site Request Forgery (CSRF)-Angriffe, da die Benutzeranmeldedaten in allen Anforderungen unabhängig vom Ursprung gesendet werden (dies unterscheidet sich von cookie-basierten Anmeldemechanismen, da Cookies in Anfragen von Drittseiten häufig blockiert werden). Seiten sollten immer POST-Anfragen verwenden, um Daten zu ändern, und CSRF-Tokens einbeziehen.
Ohne diese Sicherheitsverbesserungen sollte die Basic-Authentifizierung nicht zum Schutz sensibler oder wertvoller Informationen verwendet werden.
Zugriffseinschränkung mit Apache und Basic-Authentifizierung
Um ein Verzeichnis auf einem Apache-Server durch ein Passwort zu schützen, benötigen Sie eine .htaccess- und eine .htpasswd-Datei.
Die .htaccess-Datei sieht typischerweise so aus:
AuthType Basic
AuthName "Access to the staging site"
AuthUserFile /path/to/.htpasswd
Require valid-user
Die .htaccess-Datei verweist auf eine .htpasswd-Datei, in der jede Zeile aus einem Benutzernamen und einem durch einen Doppelpunkt (:) getrennten Passwort besteht. Sie können die tatsächlichen Passwörter nicht sehen, da sie gehasht sind (in diesem Fall wird MD5-basiertes Hashing verwendet). Beachten Sie, dass Sie Ihre .htpasswd-Datei anders benennen können, wenn Sie möchten, aber beachten Sie, dass diese Datei für niemanden zugänglich sein sollte. (Apache ist normalerweise so konfiguriert, dass der Zugriff auf .ht*-Dateien verhindert wird).
aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
Zugriffseinschränkung mit Nginx und Basic-Authentifizierung
Bei Nginx müssen Sie einen Ort angeben, den Sie schützen möchten, und die auth_basic-Anweisung, die den Namen des passwortgeschützten Bereichs angibt. Die auth_basic_user_file-Anweisung zeigt dann auf eine .htpasswd-Datei, die die verschlüsselten Benutzeranmeldedaten enthält, genau wie im vorherigen Apache-Beispiel.
location /status {
auth_basic "Access to the staging site";
auth_basic_user_file /etc/apache2/.htpasswd;
}
Zugriff mit Anmeldedaten in der URL
Historisch gesehen erlaubten es einige Seiten, sich mit einer codierten URL einzuloggen, die den Benutzernamen und das Passwort enthält, wie gezeigt:
https://username:password@www.example.com/
Diese Syntax ist in modernen Browsern nicht mehr erlaubt; der Benutzername und das Passwort werden aus der Anfrage entfernt, bevor sie gesendet wird.