Zum Hauptinhalt springen

6. Sicherheitsüberlegungen (Security Considerations)

Dieser Abschnitt soll Entwickler, Informationsanbieter und Benutzer über bekannte Sicherheitsbedenken informieren, die für die HTTP-Authentifizierung spezifisch sind. Allgemeinere Sicherheitsüberlegungen werden in der HTTP-Nachrichtenübermittlung [RFC7230] und der HTTP-Semantik [RFC7231] behandelt.

Alles zum Thema HTTP-Authentifizierung ist eine Sicherheitsüberlegung, daher ist die folgende Liste von Überlegungen nicht erschöpfend. Darüber hinaus ist sie auf Sicherheitsüberlegungen zum Authentifizierungsrahmenwerk im Allgemeinen beschränkt, statt alle potenziellen Überlegungen für bestimmte Authentifizierungsschemata zu erörtern (die in den Spezifikationen dokumentiert werden sollten, die diese Schemata definieren). Verschiedene Organisationen pflegen themenbezogene Informationen und Links zur aktuellen Forschung über Websicherheit (z. B. [OWASP]), einschließlich häufiger Fallstricke bei der Implementierung und Verwendung der in der Praxis anzutreffenden Authentifizierungsschemata.

6.1 Vertraulichkeit von Anmeldedaten (Confidentiality of Credentials)​

Das HTTP-Authentifizierungsrahmenwerk definiert keinen einzelnen Mechanismus zur Wahrung der Vertraulichkeit von Anmeldedaten; stattdessen definiert jedes Authentifizierungsschema, wie die Anmeldedaten vor der Übertragung kodiert werden. Das bietet zwar Flexibilität für die Entwicklung künftiger Authentifizierungsschemata, ist aber unzureichend für den Schutz bestehender Schemata, die von sich aus keine Vertraulichkeit bieten oder nicht ausreichend gegen Replay-Angriffe schützen. Wenn der Server außerdem Anmeldedaten erwartet, die für jeden einzelnen Benutzer spezifisch sind, hat der Austausch dieser Anmeldedaten die Wirkung, diesen Benutzer zu identifizieren, selbst wenn der Inhalt der Anmeldedaten vertraulich bleibt.

HTTP hängt von den Sicherheitseigenschaften der zugrunde liegenden Verbindung auf Transport- oder Sitzungsebene ab, um eine vertrauliche Übertragung von Header-Feldern bereitzustellen. Mit anderen Worten: Wenn ein Server den Zugang zu authentifizierten Benutzern unter Verwendung dieses Rahmenwerks beschränkt, muss der Server sicherstellen, dass die Verbindung entsprechend der Art des verwendeten Authentifizierungsschemas ordnungsgemäß abgesichert ist. Beispielsweise verlangen Dienste, die auf individueller Benutzerauthentifizierung beruhen, häufig, dass eine Verbindung mit TLS ("Transport Layer Security", [RFC5246]) abgesichert wird, bevor Anmeldedaten ausgetauscht werden.

6.2 Authentifizierungs-Anmeldedaten und inaktive Clients (Authentication Credentials and Idle Clients)​

Bestehende HTTP-Clients und Benutzeragenten behalten Authentifizierungsinformationen üblicherweise unbegrenzt. HTTP bietet keinen Mechanismus, mit dem der Ursprungsserver Clients anweisen kann, diese zwischengespeicherten Anmeldedaten zu verwerfen, da das Protokoll keine Kenntnis davon hat, wie Anmeldedaten vom Benutzeragenten erlangt oder verwaltet werden. Die Mechanismen zum Ablaufenlassen oder Widerrufen von Anmeldedaten können als Teil einer Definition eines Authentifizierungsschemas festgelegt werden.

Umstände, unter denen das Zwischenspeichern von Anmeldedaten das Sicherheitsmodell der Anwendung beeinträchtigen kann, umfassen unter anderem:

  • Clients, die über einen längeren Zeitraum inaktiv waren, wonach der Server den Client möglicherweise veranlassen möchte, den Benutzer erneut zur Eingabe von Anmeldedaten aufzufordern.

  • Anwendungen, die einen Hinweis auf die Beendigung einer Sitzung enthalten (etwa eine Schaltfläche "logout" oder "commit" auf einer Seite), wonach die Serverseite der Anwendung „weiß", dass es keinen weiteren Grund für den Client gibt, die Anmeldedaten zu behalten.

Benutzeragenten, die Anmeldedaten zwischenspeichern, werden ermutigt, einen leicht zugänglichen Mechanismus zum Verwerfen zwischengespeicherter Anmeldedaten unter Benutzerkontrolle bereitzustellen.

6.3 Schutzbereiche (Protection Spaces)​

Authentifizierungsschemata, die sich zur Etablierung eines Schutzbereichs allein auf den Mechanismus "realm" verlassen, setzen Anmeldedaten allen Ressourcen auf einem Ursprungsserver aus. Clients, die erfolgreich authentifizierte Anfragen bei einer Ressource durchgeführt haben, können dieselben Authentifizierungs-Anmeldedaten für andere Ressourcen auf demselben Ursprungsserver verwenden. Dadurch ist es einer anderen Ressource möglich, Authentifizierungs-Anmeldedaten für andere Ressourcen zu sammeln.

Dies ist besonders bedenklich, wenn ein Ursprungsserver Ressourcen für mehrere Parteien unter derselben kanonischen Wurzel-URI hostet (Abschnitt 2.2). Mögliche Gegenmaßnahmen umfassen die Beschränkung des direkten Zugriffs auf Authentifizierungs-Anmeldedaten (d. h. den Inhalt des Authorization-Anfrage-Header-Felds nicht verfügbar zu machen) und die Trennung von Schutzbereichen durch Verwendung eines anderen Hostnamens (oder Portnummer) für jede Partei.