Sicherheit/Zugriffsschutz
Es kommt im Web immer wieder vor, dass man den Zugang zu bestimmten Inhalten einschränken und nicht für jedermann zugänglich machen möchte. Je nach Anwendungsfall ist es sogar gewünscht, dass sich ein Besucher mittels Benutzernamen und Passwort ausweisen soll, damit er oder sie bestimmte Inhalte erreichen kann. Im Folgenden sollen nun Konzepte und Funktionsweisen vorgestellt werden, wie man den Zugang zu bestimmten Inhalten technisch einschränken kann, aufsteigend in ihrer technischen Komplexität und Sicherheit.
Inhaltsverzeichnis
Geheimlinks: Security By Obscurity
Die Idee ist die, dass die Internetadresse zu gewissen Inhalten von nirgendwo her verlinkt ist und auch nicht über Suchmaschinen gefunden werden kann, also eine Art Geheimnis darstellt. Man kann die Inhalte nur erreichen, wenn man Kenntnis von der genauen Adresse (URL) hat. Der Begriff security by obscurity bedeutet übersetzt so etwas wie Sicherheit durch Verschleierung und bezeichnet ein problematisches, weil technisch letzten Endes nicht sicheres Vorgehen.
Der Zugang zur Information über einen Geheimlink muss also über alternative Wege erfolgen. Übliche Methoden sind der Versand der Adressen über Mailinglisten oder Newsletter oder aber auch über andere zugangsbeschränkte Internetseiten, die eine Anmeldung mit mindestens Passwort oder sogar Benutzernamen benötigen.
HTTP-Authentication
Das HTTP-Protokoll, mit dem sich Browser und Webserver verständigen, sieht einen Mechanismus der Authentifizierung vor, der relativ simpel verläuft. Sie ist die einfachste und für einfache Anwendungen ausreichende Methode, Web-Seiten zu schützen. Dabei wird die Webserver-Software so konfiguriert, dass sie für bestimmte Dateien beim Zugriff durch einen Client (wie z. B. einem Browser) Zugangsdaten verlangt, bestehend aus einem Benutzernamen und einem Passwort. Bei fehlenden oder unpassenden Zugangsdaten händigt sie die angeforderte Ressource nicht aus, sondern gibt stattdessen eine Fehlerseite mit einem passenden Hinweis (HTTP-Statuscode 401) zurück. Scheitert deshalb ein erster Aufruf im Browser, sieht der Anwender ein Dialogfenster für die Eingabe solcher Zugangsdaten. Dieses Dialogfenster zeigt der Browser dem Benutzer so lange immer wieder an, bis der Server einen anderen Statuscode ausliefert, entweder weil die Authentifizierung gelungen ist und die Zugangsdaten gepasst haben oder weil ein anderer Fehler aufgetreten ist (z. B. Datei wurde nicht gefunden oder das Limit an Fehlversuchen wurde erreicht).
Die Webserver-Software Apache regelt über eine Konfigurationsdatei namens .htaccess die Zugangsbeschränkung, in der die Benutzernamen und die zugehörigen Passwörter stehen. Diese kann in jedem Verzeichnis neu angelegt werden, um dort jeweils eigene Konfigurationen vorzunehmen. Andere Webserver regeln die Konfiguration zu HTTP-Authentication zum Teil etwas anders, bieten diese Möglichkeit aber prinzipiell auch an.
So einfach die Konfiguration des eingebauten Möglichkeiten des Webservers ist. so allgemein ist sie gehalten. Die Konfiguration kann nur regeln, mit welchen Zugangsdaten man welche Dateien (einzeln oder Verzeichnis-weit) abrufen kann. Allerdings kann man auch mit Server-seitigen Programmiersprachen HTTP-Authentication implementieren und so feinere Unterteilungen vornehmen, wie beispielsweise einzelne Dateien sperren oder für jeden Nutzer angepasste Inhalte bereit stellen.
Siehe auch:
Problematisch ist bei diesem, HTTP-Authentication genannten Verfahren allerdings, dass es keine standardisierte Methode zum Ausloggen gibt. Der Browser speichert die Zugangsdaten bis zum Ende der Sitzung und vergisst sie erst, wenn das Programm geschlossen wird. Mittlerweile bieten alle gängigen Browser an, die Zugangsdaten dauerhaft zu speichern, was die Problematik mit dem Ausloggen nicht gerade vereinfacht.
Passwortschutz über Cookies
Wenn eine Website mittels einer serverseitigen Programmiersprache wie zum Beispiel Perl oder PHP ausgeliefert wird, dann lässt sich mittels dieser Script-Sprache ein wesentlich leistungsfähigeres Konzept der Zugangsbeschränkung realisieren. Da HTTP ein zustandloses Protokoll ist, benötigt eine solche Vorgehensweise eine Lösung für das Problem, beim nächsten Aufruf einer Ressource den angemeldeten Benutzer als solchen wieder zu erkennen. Deswegen wird bei einer erfolgreichen Anmeldung auf dem Server eine sogenannte Session (session, engl. für Sitzung) gestartet und dem Browser des Benutzers die Session-ID entweder über ein Cookie oder einen URL-Parameter mitgeteilt. Ruft nun der Browser eine Ressource auf, „erkennt“ die Website den Benutzer anhand der mitgesendeten Session-ID und kann ihm maßgeschneiderte Inhalte, beziehungsweise nur für ihn bestimmte Inhalte anzeigen.
Eine solche Session wird entweder dadurch beendet, dass sich der Benutzer abmeldet, oder dass ein Zeitlimit abgelaufen ist, seit dem der Benutzer das letzte Mal eine Ressource angefordert hat.
Der Vorteil einer Session-basierten Zugangsbeschränkung ist der, dass sich ein Benutzer wieder abmelden kann und dass sich der Login-Vorgang besser anpassen lässt, da die Login-Website im Wesentlichen aus einem einem HTML-Formular besteht. Aufgrund dieser Vorteile ist dies das am häufigsten verwendete Login-Verfahren.
Der Nachteil dieser Art der Zugangsbeschränkung ist sicherlich der, dass die Website nun zwingend ein in einer serverseitigen Script-Sprache geschriebenes Programm ist und seine Erstellung weit über den Kontext von HTML-Dokumenten hinausgeht. Um solche Webseiten in einer Entwicklungsumgebung sinnvoll zu testen und zu erstellen, genügt es nun nicht mehr die Dateien einfach von der Festplatte im Browser aufzurufen. Man benötigt nun eine Webserver-Software mit passender Einbindung der verwendeten Script-Sprache.
Vergleich von HTTP-Authentication und Cookies
Im Forum postete Der Martin folgenden anschaulichen Vergleich der beiden Zugriffsschutz-Methoden:
Login: Der Portier stoppt dich am Eingang. "Moment, wer sind Sie denn?" Dann zeigst du deinen Ausweis vor, der Portier schaut in der Liste nach. Ist alles okay, reicht er dir eine Pappnase mit einer Nummer auf der Nasenspitze (Cookie): "Die müssen Sie tragen, dann erkennen meine Kollegen sofort, dass Sie dazugehören." Und beim nächsten Mal lassen sie dich unbehelligt rein, du hast ja die Pappnase mit der Nummer.
HTTP-AUTH: Der Portier stoppt dich am Eingang. "Moment, wer sind Sie denn?" Dann zeigst du deinen Ausweis vor, der Portier schaut in der Liste nach. Ist alles okay, lässt er dich rein. Beim nächsten Mal wäre dasselbe Spielchen erneut fällig, aber du bist ja schlau und zeigst sofort deinen Ausweis, bevor überhaupt jemand danach fragt.
Unwirksame Zugriffsschutz-Methoden
Achtung!
Folgende Methoden werden hier nur als Negativ-Beispiel aufgeführt und sollten deshalb nicht verwendet werden, da sie auf das Prinzip der oben genannten Geheimlinks aufsetzen.
„Passwortschutz“ mit JavaScript
Der zu schützenden Seite wird eine Seite mit einem Formular und Eingabemöglichkeit eines Passwortes vorgeschaltet. JavaScript überprüft die Eingabe und weist den Besucher dann entweder ab oder leitet ihn auf die geheime Seite.
Da JavaScript allerdings vollständig im Browser des Besuchers ausgeführt wird, kann der Besucher im Quelltext oder mit Werkzeugen wie dem Seiteninspektor sowohl das Passwort auslesen als auch die Funktion des Passwortschutzes ausspähen und ohne Passworteingabe auf die geheime Seite gelangen (indem er die URL aus dem Quellcode entnimmt und manuell in seinem Browser eingibt).
Auf Sessions basierender „Passwortschutz“ – falsch implementiert
Der zu schützenden Seite wird eine Seite mit einem Formular und Eingabemöglichkeit eines Passwortes vorgeschaltet. Ein Script auf dem Server überprüft die Eingabe und weist den Besucher dann entweder ab oder leitet ihn auf die geheime Seite weiter.
Dabei gibt es mehrere Möglichkeiten, durch falsche Implementierung den Passwortschutz unsicher, verwundbar gegenüber Angriffe oder sogar für den Benutzer gefährlich zu machen:
- Das Passwort ist auf dem Server unverschlüsselt gespeichert und kommt dadurch bei einem Datenleck in die Hände von Angreifern oder das Passwort wird unverschlüsselt im Klartext übertragen – da Nutzer trotz aller Warnungen die selben Passwörter auf mehreren Webangeboten verwenden, können Angreifer die erhaltene Benutzername/E-Mail-Adresse-Passwort-Kombination einfach auf mehreren Diensten ausprobieren und so auch andere Accounts kompromittieren
- Der Passwortschutz sorgt nur für eine (passwortgeschützte) Weiterleitung auf die geheime Seite, die geheime Seite kann aber, wenn man ihre URL kennt, ganz ohne Passwort aufgerufen werden
- Der Server speichert Ihren Loginstatus global statt nur in Bezug auf ihre Session – die geheime Seite kann dadurch von jedem aufgerufen werden solange Sie eingeloggt sind.
- Der Server benutzt nicht ihre Session zum Speichern ihrer Logindaten, sondern uneindeutigere Merkmale, z. B. Ihre IP oder den User Agent ihres Browser. Dadurch kann, insbesondere bei IPv4-Verbindungen, jeder, der mit Ihnen im selben lokalen Netzwerk ist, die geheime Seite öffnen.
- Da HTTP statuslos ist, kann – sofern keine Gegenmaßnahmen getroffen wurden – eine andere Seite ihre Sitzung indirekt ausnutzen, indem sie Ihren Browser dazu bringt, die Seite, auf der Sie eingeloggt sind, mit bestimmten Paramtern aufzurufen, um beispielsweise ihr Passwort zu ändern. Dies nennt man Cross-Site-Request-Forgery.
Diese Liste erhebt keinen Anspruch auf Vollständigkeit!
„Zugriffsschutz“ mit robots-Metatag
Die zu schützende Seite wird ohne Links ins Netz gestellt und den Suchmaschinen mittels meta-Element oder robots.txt empfohlen, die jeweilige Seite nicht in den Index aufzunehmen. Dieser „Zugriffsschutz“ ist mit allen Nachteilen des Konzepts Security-by-Obscurity behaftet; abgesehen davon kann man Suchmaschinen nur darum bitten, eine Seite nicht zu indizieren – eine sichere Verhinderung ist nicht möglich, da die Suchmaschinen selbst entscheiden, ob sie dieser Bitte nachkommen oder nicht. Es ist außerdem nicht ausgeschlossen, dass diese Angaben dazu führen, dass böswillige Webcrawler, die gezielt nach solchen Dateien suchen, bei denen die Indizierung unerwünscht ist, der geheimen Seite dadurch zusätzliche Aufmerksamkeit widmen.
Siehe auch
Weblinks
- Wikipedia: Cross-Site-Request-Forgery, ermöglicht das Ausnutzen einer aktiven Sitzung durch eine dritte Partei
- Wikipedia: Session Hijacking
- Wikipedia: Session Fixation
