Sicherheit/Zugriffsschutz

Aus SELFHTML-Wiki
Wechseln zu: Navigation, Suche

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

[Bearbeiten] 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.

Beachten Sie: Das Konzept hinter Geheimlinks ist in keiner Weise sicher. Sobald eine Adresse irgendwo im Netz öffentlich sichtbar wird, ist das Geheimnis kein Geheimnis mehr. Außerdem kann prinzipiell jeder die Inhalte erreichen, da es keine technische Vorkehrung gibt, die den Zugang einschränken könnte, weshalb sie vielleicht doch irgendwann von Suchmaschinen gelistet werden.

[Bearbeiten] 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.

Siehe auch:

Problematisch ist bei dem 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 vereinfacht.

Ein weiteres mögliches Problem ist, dass die Zugriffsregelung sehr allgemein gehalten ist. Die Konfiguration kann nur regeln, mit welchen Zugangsdaten man welche Dateien (einzeln oder verzeichnisweit) abrufen kann. Auf den Benutzer maßgeschneiderte Inhalte zusammen zu stellen, wie etwa in einem Forum oder web-basierten E-Mail-Programm, ist damit nicht möglich.

[Bearbeiten] Passwortschutz mit serverseitiger Programmiersprache

Wenn eine Website mittels einer serverseitigen Script-Sprache (ist im Prinzip eine Programmiersprache) wie z.B. Perl, PHP oder andere 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, beim nächsten Aufruf einer Ressource den angemeldeten Benutzer als solchen wieder zu erkennen. Deswegen wird bei einer erfolgreichen Anmeldung mit der serverseitigen Script-Sprache 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 unter Verwendung dieser Session-ID auf, "erkennt" die Website den Benutzer und kann ihm maßgeschneiderte 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 durch die Verwendung der serverseitigen Script-Sprache maßgeschneiderte Inhalte für diesen Benutzer zusammenstellen lassen. So ist es z.B. möglich komplexe Webanwendungen zu realisieren.

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.

[Bearbeiten] 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.

[Bearbeiten] „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).

Beachten Sie: Jeder auf JavaScript basierte Zugriffsschutz kann mit einfachsten Mitteln umgangen werden.

[Bearbeiten] „Passwortschutz“ mit serverseitiger Programmiersprache – 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
  • Das Passwort wird über eine unverschlüsselte Verbindung übertragen und kommt dadurch in die Hände eines Lauschers
  • Das Passwort wird im Klartext übertragen und Ihr E-Mail-Konto, welches zufällig das gleiche Passwort eingestellt hat, kann von einem Lauscher gekapert werden
  • 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. Dadurch kann, insbesondere bei IPv4-Verbindungen, jeder, der mit Ihnen im selben lokalen Netzwerk ist, die geheime Seite öffnen.

Diese Liste erhebt keinen Anspruch auf Vollständigkeit!

Beachten Sie: Versuchen Sie auf keinen Fall auf eigene Faust einen eigenen serverseitigen Zugriffsschutz zu implementieren, wenn Sie nicht ganz genau wissen, was Sie tun, und was Sie dabei beachten müssen. Seien Sie sich darüber im Klaren, dass ein Zugriffsschutz, der heute als sicher gilt, schon morgen aufgrund der technischen Entwicklung unsicher sein kann und steter Pflege bedarf.
Empfehlung: Verwenden Sie stattdessen einen Zugriffsschutz, der beispielsweise in einem vertrauenswürdigen Framework verfügbar ist, bei dem Sie vom Spezialwissen und den Sicherheitsupdates eines Experten profitieren können.

[Bearbeiten] „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.

Meine Werkzeuge
Namensräume

Varianten
Aktionen
Übersicht
Index
Mitmachen
Werkzeuge
Spenden
SELFHTML