HTTP bietet ein allgemeines Framework für Zugriffskontrolle 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 Clientanforderung zuchallengen, und von einem Client, um Authentifizierungsinformationen bereitzustellen.

Der Ablauf von Challenge und Response funktioniert so:

1. Der Server antwortet auf eine Clientanfrage mit einem401 (Unauthorized) Statuscode und gibt Informationen zur Autorisierung an, indem er einenWWW-Authenticate Antwortheader enthält, der mindestens eine Challenge enthält.
2. Ein Client, der sich beim Server authentifizieren möchte, kann dies tun, indem er einenAuthorization Anfrageheader mit den Anmeldedaten einfügt.
3. Normalerweise zeigt ein Client dem Benutzer eine Passwortaufforderung an und sendet dann die Anfrage mit dem richtigenAuthorization-Header.

Der allgemeine Nachrichtenfluss oben ist derselbe für die meisten (wenn nicht alle)Authentifizierungsschemata. Die tatsächlichen Informationen in den Headern und die Art und Weise, wie sie kodiert sind, ändern sich allerdings!

Proxy-Authentifizierung

Der gleiche Mechanismus von Challenge und Response kann für dieProxy-Authentifizierung verwendet werden. Da Ressourcen- und Proxy-Authentifizierung koexistieren können, wird ein anderer Satz von Headern und Statuscodes benötigt. Im Fall von Proxies ist der herausfordernde Statuscode407 (Proxy Authentication Required), derProxy-Authenticate Antwortheader enthält mindestens eine für den Proxy anwendbare Challenge, und derProxy-Authorization Anfrageheader wird verwendet, um die Anmeldedaten an den Proxyserver bereitzustellen.

Zugriff verweigert

Wenn ein (Proxy-)Serverungültige Anmeldedaten erhält, sollte er mit einem401Unauthorized oder mit einem407Proxy Authentication Required antworten, und der Benutzer kann eine neue Anfrage senden oder dasAuthorization Headerfeld ersetzen.

Wenn ein (Proxy-)Server gültige Anmeldedaten erhält, dieunzureichend sind, um auf eine bestimmte Ressource zuzugreifen, sollte der Server mit dem403Forbidden Statuscode antworten. Im Gegensatz zu401Unauthorized oder407Proxy Authentication Required ist für diesen Benutzer keine Authentifizierung möglich, und Browser werden keinen neuen Versuch vorschlagen.

In allen Fällen kann der Server es vorziehen, einen404Not Found Statuscode zurückzugeben, um die Existenz der Seite vor einem Benutzer ohne angemessene Berechtigungen oder nicht korrekt authentifiziert zu verbergen.

Authentifizierung von Cross-Origin-Bildern

Ein potenzielles Sicherheitsloch (das in Browsern inzwischen behoben wurde) war die Authentifizierung von Cross-Site-Bildern.AbFirefox 59 können Bildressourcen, die von anderen Ursprüngen als das aktuelle Dokument geladen werden, keine HTTP-Authentifizierungsdialoge mehr auslösen (Firefox bug 1423146), was verhindert, dass Benutzeranmeldedaten gestohlen werden, wenn Angreifer in der Lage wären, ein beliebiges Bild in eine Drittanbieter-Seite einzubetten.

Zeichenkodierung der HTTP-Authentifizierung

Browser verwendenutf-8 Kodierung für Benutzernamen und Passwörter.

Firefox verwendete einmalISO-8859-1, wechselte jedoch zuutf-8 für die Parität mit anderen Browsern und um potenzielle Probleme zu vermeiden, wie inFirefox bug 1419658 beschrieben.

WWW-Authenticate und Proxy-Authenticate Header

DieWWW-Authenticate undProxy-Authenticate Antwortheader definieren die Authentifizierungsmethode, die verwendet werden sollte, um Zugang zu einer Ressource zu erhalten. Sie müssen angeben, welches Authentifizierungsschema verwendet wird, damit der Client, der autorisieren möchte, weiß, wie die Anmeldedaten bereitzustellen sind.

Die Syntax für diese Header ist die folgende:

WWW-Authenticate: <type> realm=<realm>Proxy-Authenticate: <type> realm=<realm>

Hierbei ist<type> das Authentifizierungsschema ("Basic" ist das am häufigsten verwendete Schema undwird unten eingeführt). Dasrealm wird verwendet, um den geschützten Bereich zu beschreiben oder den Schutzbereich anzugeben. Dies könnte eine Nachricht wie "Zugang zur Staging-Seite" oder ähnliches sein, damit der Benutzer weiß, auf welchen Bereich er zugreifen möchte.

Authorization und Proxy-Authorization Header

DieAuthorization undProxy-Authorization Anfrageheader enthalten die Anmeldedaten, um einen Benutzeragenten bei einem (Proxy-)Server zu authentifizieren. Hierbei wird<type> erneut benötigt, gefolgt von den Anmeldedaten, die kodiert oder verschlüsselt sein können, je nachdem, welches Authentifizierungsschema verwendet wird.

Authorization: <type> <credentials>Proxy-Authorization: <type> <credentials>

Authentifizierungsschemata

Das allgemeine HTTP-Authentifizierungsframework ist die Grundlage für eine Reihe von Authentifizierungsschemata.

Die IANA pflegt eineListe der Authentifizierungsschemata, aber es gibt andere Schemata, die von Host-Services, wie zum Beispiel Amazon AWS, angeboten werden.

Einige gängige Authentifizierungsschemata umfassen:

Basic

SieheRFC 7617, base64-kodierte Anmeldedaten. Weitere Informationen unten.

Bearer

SieheRFC 6750, Inhabertokens zum Zugriff auf OAuth 2.0-geschützte Ressourcen.

Digest

SieheRFC 7616. Firefox 93 und höher unterstützen den SHA-256-Algorithmus. Frühere Versionen unterstützen nur MD5-Hashing (nicht empfohlen).

HOBA

SieheRFC 7486, Abschnitt 3,HTTPOrigin-BoundAuthentication, digital-signaturbasiert.

Mutual

SieheRFC 8120

Negotiate /NTLM

SieheRFC4599

VAPID

SieheRFC 8292

SCRAM

SieheRFC 7804

AWS4-HMAC-SHA256

SieheAWS-Dokumentation. Dieses Schema wird zur AWS3-Serverauthentifizierung verwendet.

Die Schemata können sich in der Sicherheitsstärke und in ihrer Verfügbarkeit in Client- oder Server-Software unterscheiden.

Das "Basic"-Authentifizierungsschema bietet sehr geringe Sicherheit, wird jedoch weit unterstützt und ist einfach einzurichten. Es wird unten ausführlicher eingeführt.

Basic-Authentifizierungsschema

Das "Basic"-HTTP-Authentifizierungsschema ist definiert inRFC 7617, das Anmeldedaten als Benutzer-ID/Passwort-Paare codiert mit base64 überträgt.

Sicherheit der Basic-Authentifizierung

Da die Benutzer-ID und das Passwort im Netzwerk als Klartext übermittelt werden (sie sind base64-codiert, aber base64 ist eine reversible Codierung), ist das Basic-Authentifizierungsschema nicht sicher. HTTPS/TLS sollte mit Basic-Authentifizierung verwendet werden, um das Abfangen von Anmeldedaten zu verhindern.

Darüber hinaus sind Seiten, die HTTP Basic Auth verwenden, besonders anfällig fürCross-Site Request Forgery (CSRF)-Angriffe, da die Benutzeranmeldedaten bei allen Anfragen ungeachtet des Ursprungs gesendet werden (dies unterscheidet sich von cookie-basierten Anmeldemechanismen, da Cookies in Cross-Site-Anfragen häufig blockiert werden). Seiten sollten immer POST-Anfragen verwenden, wenn Daten geändert werden, undCSRF-Token einfügen.

Ohne diese Sicherheitsverbesserungen sollte Basic-Authentifizierung nicht verwendet werden, um sensible oder wertvolle Informationen zu schützen.

Zugriff einschränken mit Apache und Basic-Authentifizierung

Um ein Verzeichnis auf einem Apache-Server passwortzuschützen, benötigen Sie eine.htaccess und eine.htpasswd Datei.

Die.htaccess-Datei sieht typischerweise so aus:

AuthType BasicAuthName "Access to the staging site"AuthUserFile /path/to/.htpasswdRequire 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 siegehasht sind (in diesem Fall durch MD5-basiertes Hashing). Beachten Sie, dass Sie Ihre.htpasswd-Datei anders benennen können, wenn Sie möchten, aber bedenken 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/

Zugriff einschränken mit Nginx und Basic-Authentifizierung

Für Nginx müssen Sie einen Ort angeben, den Sie schützen möchten, sowie dieauth_basic-Direktive, die den Namen des passwortgeschützten Bereichs bereitstellt.Dieauth_basic_user_file-Direktive verweist dann auf eine.htpasswd-Datei, die die verschlüsselten Benutzeranmeldedaten enthält, genau wie im Apache-Beispiel oben.

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 einige Seiten die Anmeldung über eine kodierte URL, die den Benutzernamen und das Passwort enthielt, wie gezeigt:

https://username:password@www.example.com/

Diese Syntax ist in modernen Browsern nicht mehr erlaubt; der Benutzername und das Passwort werden von der Anfrage entfernt, bevor sie gesendet wird.

Siehe auch

• WWW-Authenticate
• Authorization
• Proxy-Authorization
• Proxy-Authenticate
• 401,403,407
• HTTP-Sicherheits-Leitfäden