Bundesamt für Sicherheit in der Informationstechnik

M 5.160 Authentisierung gegenüber Webservern

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator

Um die Identität von Benutzern feststellen und ihnen entsprechende Rechte zuteilen zu können, gibt es unterschiedliche Mechanismen, die in den folgenden Abschnitten vorgestellt werden. Hat sich ein Benutzer erfolgreich authentisiert (beispielsweise durch Angabe von Benutzername und Passwort), so wird ihm eine sogenannte Session zugewiesen. Bei einer Session handelt es sich um eine Sitzung, die einem Benutzer zugeordnet ist und die eine zum Server hergestellte aktive Verbindung bezeichnet. Sessions sind notwendig, da das bei Web-Anwendungen verwendete Protokoll ( HTTP ) zustandslos ist. Jede Anfrage an einen Webserver wird unabhängig von allen anderen zuvor eingetroffenen Anfragen bearbeitet. Um bei Web-Angeboten dennoch von Benutzern abhängige Zustände abbilden zu können ( z. B. den Anmeldestatus eines Benutzers oder den Inhalt eines Warenkorbs), werden Sessions verwendet.

Eine Session wird durch eine eindeutige Session- ID identifiziert. Diese wird nach einer erfolgreichen Anmeldung zum Client übertragen und bei jeder weiteren Anfrage an den Server wieder mitgesandt. Dadurch erkennt der Webserver, dass die Anfrage in einem bestimmten Kontext steht und kann sie einem Benutzer zuordnen.

Formular-basierte Authentisierung

Die Formular-basierte Authentisierung ist eine weit verbreitete Authentisierungsmethode und wird bei den meisten Web-Anwendungen eingesetzt. Dabei werden die Anmeldedaten über ein Formular an die Web-Anwendung übergeben. Die Authentisierung des Benutzers erfolgt dann durch die Web-Anwendung, welche überprüft, ob die übergebenen Anmeldedaten für den angegebenen Benutzer korrekt sind. Der Vorteil dieser Art der Authentisierung ist die nahtlose Einbindung der Anmelde-Funktion in eine Web-Anwendung, da die Angabe der Anmeldedaten einfach über Eingabefelder in der Web-Anwendung erfolgt. Da die Authentisierung durch die Web-Anwendung vorgenommen wird, ist zudem eine sehr flexible Handhabung von Anmeldeversuchen (z. B. Handhabung von fehlgeschlagenen Anmeldeversuchen, Fehlermeldungen) möglich. Eine erhöhte Flexibilität birgt allerdings auch das Problem von Schwächen in der Implementierung mit sich. So muss beispielsweise darauf geachtet werden, dass die Anmeldedaten über eine gesicherte Verbindung übertragen werden.

Basic Access Authentication

HTTP Basic Access Authentication wurde im Rahmen von HTTP/1.0 in RFC 1945 spezifiziert und stellt einen einfachen Authentisierungsmechanismus zur Verfügung. Der Anmeldevorgang wird dabei jedoch nicht über die Web-Anwendung, sondern durch den Webserver selbst durchgeführt. Die Anmeldedaten werden dabei nur Base64-codiert und nicht verschlüsselt versendet, weshalb diese Art der Authentisierung nur über eine gesicherte Kommunikation benutzt werden darf. Ist der Angreifer in der Lage, die Kommunikation abzuhören, so kann dieser die Kodierung umkehren und Benutzername und Passwort im Klartext auslesen. Basic Access Authentication bietet einen Schutz auf Verzeichnis-Ebene, da definiert werden kann, welcher Benutzer welche Zugriffsfunktionen auf welche Verzeichnisse anwenden darf. Diese Art der Authentisierung wird von allen gängigen Webservern und Browsern unterstützt, gilt jedoch als veraltet und wird kaum noch verwendet.

Digest Access Authentication

Digest Access Authentication basiert auf der Basic Access Authentication, wurde jedoch um Sicherheitsfunktionen erweitert. So werden beispielsweise anstatt der Anmeldedaten nur noch eine entsprechende MD5 -Prüfsumme übertragen. MD5 kann zwar nicht mehr für alle Anwendungsgebiete als sicher angesehen werden. Die Möglichkeit zum Auffinden von Kollisionen, die bei MD5 besteht, hat jedoch auf die Authentisierung keine Auswirkung, da hier Zufallszahlen verwendet werden. In die MD5-Prüfsumme fließt die bei jedem Authentisierungsversuch neu vom Server bestimmte Zufallszahl ein. Auf diese Weise kann eine sichere Authentisierung auch über ungesicherte Kanäle erfolgen. Spezifiziert ist die Digest Access Authentication in RFC 2617.

Host-basierte Authentisierung

Bei der Host-basierten Authentisierung werden die Zugriffsrechte auf Basis der IP-Adresse bestimmt. Diese Art der Authentisierung ist jedoch anfällig für IP-Spoofing. Dabei fälscht ein Angreifer die IP -Adresse der von ihm gesandten Netzpakete, wodurch die darin enthaltenen Anfragen unter anderen Zugriffsrechten ausgeführt werden.

Zertifikate

Zertifikat-basierte Authentisierung basiert auf einer Public-Key-Infrastruktur. Der Nachweis der Identität erfolgt dabei über ein Zertifikat, welches den öffentlichen Schlüssel einer Entität (z. B. Benutzer) beinhaltet und von einer Zertifizierungsstelle signiert sein muss. Die Zertifizierungsstelle ist somit auch für die Verifizierung der Identität vor Signieren des Zertifikats verantwortlich. In der Regel wird dies von einer eigenen Registrierungsstelle erledigt.

Meist kommt bei der Zertifikat-basierter Authentisierung ein sogenanntes Zwei-Faktor-Verfahren zum Einsatz. Dies bedeutet, dass zum Nachweis der Identität nicht nur der Besitz des Zertifikats, sondern auch ein weiterer Faktor, typischerweise ein Passwort, erforderlich ist. Je nach Anwendungsgebiet kann die Speicherung des Zertifikats auf unterschiedlichen Medien erfolgen. Beispiele hierfür sind Token, Chipkarten oder Software-Zertifikatsspeicher.

Cookies

Cookies sind in der Regel kleine Text-Dateien, die Informationen über HTTP-Sitzungen lokal auf Client-Seite speichern. Diese werden bei erneuten Anfragen an einen Webserver in der HTTP-Kopfzeile mitgesendet und erlauben somit dem Server ein Wiedererkennen des Clients. Der Server kann mit Hilfe des Cookies beispielsweise erkennen, welcher Benutzer eine Anfrage sendet.

Im Cookie können außer einer eindeutigen ID noch andere Informationen gespeichert werden. Ein Beispiel hierfür ist die Angabe, für welche Domain und welchen Pfad ein Cookie gültig ist. Da das Mitsenden von Cookies vom Browser geregelt wird, ist dieser auch dafür verantwortlich, dass sie nur von der zugehörigen Domain, wie vom Server definiert, ausgelesen werden können. Cookies können zusätzlich Flags enthalten. Wird das httponly-Flag gesetzt, so kann das Cookie von JavaScript nicht mehr gelesen oder verändert werden.

Mit Hilfe von Cross-Site Scripting ist es möglich, Cookies von anfälligen Domains zu stehlen und sich damit beispielsweise gegenüber einem Webserver als ein anderer Benutzer auszugeben. Ein Angreifer schleust dabei Code in die Web-Anwendung ein, welcher auf dem Client des Benutzers ausgeführt wird und dem Angreifer das gewünschte Cookie im Hintergrund übermittelt.

Stand: 12. EL Stand 2011