Sicherheit/Zugriffsschutz

10min

mittel

• Die sichere Passwort-Wahl

Nicht jede Webseite soll für alle zugänglich sein. Manchmal dürfen bestimmte Inhalte nur für angemeldete Benutzerinnen und Benutzer erreichbar sein – etwa persönliche Daten, interne Dokumente oder geschützte Bereiche einer Webseite.

In diesem Artikel geht es darum, wie man Zugriffe auf Webinhalte tatsächlich beschränkt. Dabei schauen wir uns einfache, aber unsichere Methoden genauso an wie echte Authentifizierung und zeigen auch, warum manche vermeintlichen Schutzmaßnahmen überhaupt keinen Schutz bieten.

Geheimlinks: Security By Obscurity

Die Idee: Bestimmte Inhalte sind über keine normale Webseite verlinkt und sollen auch nicht von Suchmaschinen gefunden werden. Zugriff hat nur, wer die genaue URL kennt. Dieses Prinzip nennt man Security by Obscurity – Sicherheit durch Verschleierung.

Das ist jedoch kein echter Zugriffsschutz. Wer die URL kennt, kann die Inhalte aufrufen. Wird sie beispielsweise weitergegeben oder veröffentlicht, ist das Geheimnis dahin.

Beachte: Ein Geheimlink schützt keine Inhalte. Er verhindert höchstens, dass sie leicht gefunden werden.

robots.txt

Auch eine robots.txt oder ein robots-Meta-Tag sind kein Zugriffsschutz. Damit kann man Suchmaschinen bitten, bestimmte Seiten nicht zu erfassen. Ein Browser kann die URL trotzdem direkt aufrufen – und ein böswilliger Crawler muss sich an diese Regeln ohnehin nicht halten.

Ein Geheimlink ist deshalb höchstens schwer zu finden, aber nicht geschützt.

Beachte: Eine Datei robots.txt kann eine vermeintlich geheime URL für Angreifer sogar noch interessanter machen, da sie öffentlich Pfade auflistet, die der Websitebetreiber lieber nicht von Crawlern durchsucht haben möchte. Daher sollte sie niemals für vertrauliche URLs verwendet werden.

Passwortabfragen

Am üblichsten ist eine Passwortabfrage auf der Webseite, um geschützte Inhalte freizuschalten.

Dabei ist eine Abfrage mit JavaScript für ein echtes Zugangsschutzsystem allerdings ungeeignet: Der Browser erhält den gesamten Code und damit auch das darin enthaltene Passwort. Wer die Seite mit den Entwickler-Tools untersucht, kann den „Schutz“ daher einfach umgehen.

Ein echter Zugriffsschutz muss auf dem Server stattfinden.

HTTP-Authentifizierung

Das HTTP-Protokoll, über das Browser und Webserver miteinander kommunizieren, enthält einen einfachen Mechanismus zur Authentifizierung: HTTP Basic Authentication.

Der Webserver kann bestimmte Dateien oder Verzeichnisse schützen. Ruft der Browser eine solche Ressource auf, antwortet der Server zunächst mit dem HTTP-Statuscode 401 (Unauthorized) und fordert Zugangsdaten an. Der Browser zeigt daraufhin ein Eingabefenster für Benutzername und Passwort. Stimmen die Daten, liefert der Server die angeforderte Ressource aus.

Bei Apache wird HTTP Basic Authentication beispielsweise über die Serverkonfiguration eingerichtet. Häufig kommen dabei eine .htaccess-Datei und eine separate Datei mit den Zugangsdaten zum Einsatz. Andere Webserver verwenden andere Konfigurationsdateien, bieten die Authentifizierung aber ebenfalls an.

HTTP Basic Authentication ist einfach einzurichten, bietet aber nur begrenzte Möglichkeiten. Die Webserver-Konfiguration kann beispielsweise festlegen, welche Benutzer auf bestimmte Dateien oder Verzeichnisse zugreifen dürfen. Für Anwendungen mit individuellen Benutzerkonten, Rollen oder personalisierten Inhalten sind Sessions meist flexibler.

Wichtig ist außerdem: HTTP Basic Authentication sollte immer über HTTPS verwendet werden. Bei Basic Authentication werden Benutzername und Passwort für jede Anfrage erneut übertragen – lediglich codiert, nicht verschlüsselt. HTTPS schützt diese Daten auf dem Transportweg.

Ein weiterer Nachteil ist das Ausloggen: HTTP Basic Authentication besitzt keinen standardisierten Logout-Mechanismus. Der Browser verwaltet die Zugangsdaten selbst; eine Webseite kann den Benutzer daher nicht einfach per „Logout“-Knopf abmelden.

• 

  Zugriffskontrolle mit .htaccess
  • Verzeichnisse und Dateien mit Passwort schützen‎
  • IP-Adressen oder IP-Bereiche zulassen /ausschließen
   

Sessions und Cookies

Bei einem Login mit einer serverseitigen Programmiersprache wie PHP kann die Webseite den angemeldeten Benutzer über eine Session wiedererkennen. Dazu erzeugt der Server nach erfolgreicher Anmeldung eine zufällige Session-ID, die der Browser bei weiteren Anfragen mitsendet – normalerweise in einem Cookie.

So kann der Server erkennen, welcher Benutzer angemeldet ist, und beispielsweise persönliche oder nur für diesen Benutzer freigegebene Inhalte ausliefern. Die Session endet normalerweise beim Abmelden oder nach einer gewissen Zeit ohne Aktivität.

Sessions sind flexibler als HTTP Basic Authentication: Eine Webseite kann eigene Login- und Logout-Seiten anbieten und unterschiedliche Benutzer und Zugriffsrechte verwalten. Dafür braucht sie allerdings eine serverseitige Anwendung – mit reinem HTML und JavaScript lässt sich ein solcher Zugriffsschutz nicht zuverlässig umsetzen.

Beachte: Die Session-ID sollte nicht als URL-Parameter übergeben werden. Eine solche URL kann beispielsweise in der Browser-Chronik, in Server-Logs oder beim Weitergeben eines Links sichtbar werden. Ein geschütztes Cookie ist dafür besser geeignet.

• Loginsystem in PHP
  • Sessions und Cookies
  • Password API und Hashes

  Warum wir eben kein fertiges Script mehr anbieten!

   

Vergleich von HTTP-Authentifizierung und Sessions

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 prüft ihn. 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.

Bei Sessions meldest du dich einmal an und erhältst eine Session-ID, die der Browser anschließend mit jeder Anfrage mitsendet. Bei HTTP Basic Authentication werden die Zugangsdaten dagegen bei den Anfragen erneut übertragen.

Für einfache, statische Bereiche kann HTTP-Authentifizierung ausreichen. Sessions sind flexibler und deshalb die übliche Grundlage für Benutzerkonten, individuelle Zugriffsrechte und Login- und Logout-Funktionen.

Siehe auch

• 

  Zugriffskontrolle mit .htaccess
  • Verzeichnisse und Dateien mit Passwort schützen‎
  • IP-Adressen oder IP-Bereiche zulassen /ausschließen
   
• Loginsystem in PHP
  • Sessions und Cookies
  • Password API und Hashes

  Warum wir eben kein fertiges Script mehr anbieten!

   
• Zwei-Faktor-Authentifizierung