Zugangskontrolle

IT 12.6 – Webanwendungen · Einheit 11 · Café-App Schritt 11

Lernziele

Du kannst Authentifizierung und Autorisierung unterscheiden.
Du kannst den Ablauf einer Anmeldung mit Sitzung und Cookie beschreiben.
Du kannst erklären, warum Passwörter als Hash mit Salz gespeichert werden.
Du kannst Schwachstellen einer Zugangskontrolle erkennen und beurteilen.
Du kannst Maßnahmen für eine sichere Anmeldung begründen.

Rückblick

1. Mit welcher Methode sollte ein Anmeldeformular senden, und warum?

Mit POST. Das Passwort soll nicht in der Adresse, im Verlauf oder in den Protokolldateien des Servers stehen (Einheit 10).

2. Schützt POST das Passwort auf dem Weg zum Server?

Nein. Erst HTTPS verschlüsselt die Anfrage auf dem Weg (Einheit 10, Aufgabe 5).

3. Warum genügt eine Prüfung im Browser nicht?

Alles im Browser lässt sich verändern oder umgehen. Verbindlich ist nur, was der Server prüft (Einheit 6 und 9).

Der Team-Bereich

Das Café-Team möchte auf dem Tablet am Tresen die Seite team.php mit allen Bestellungen des Tages sehen: Namen, Klassen, Produkte. Außerdem soll die Leitung des Cafés die Preise ändern können, die anderen im Team aber nicht.

Im Team gibt es zwei Ideen:

Tim: „Die Adresse team.php verraten wir einfach niemandem.“
Sara: „Wir bauen eine Passwortabfrage in JavaScript ein. Nur wer das richtige Passwort eintippt, bekommt die Tabelle zu sehen.“

Überlege: Was haltet ihr von den beiden Ideen? Wie kann der Server bei jeder Anfrage wissen, ob sie von einem angemeldeten Teammitglied kommt?

Erkunden: Ein geschützter Bereich

Bevor du weiterliest: Bearbeite die Erkundungen. Die Erklärungen weiter unten helfen dir erst danach.

Erkundung 1: Anmelden und angemeldet bleiben mittel

Simulation eines Webservers für cafe.example: Alles läuft in deinem Browser, nichts wird übertragen oder gespeichert. Klicke Links an und schicke Formulare ab. Demo-Zugänge (erfunden): team / Brezel!42 und leitung / Kakao#2026.

Das hat der Browser an den Server geschickt:

Anfrage von Hand ändern und senden

So wie mit den Entwicklerwerkzeugen kann man eine Anfrage beliebig verändern. Der Server muss damit rechnen.

Was der Server bei der letzten Anfrage getan hat:

Das hat der Server zurückgeschickt (Kopfzeilen und HTML):

a) Klicke auf „Bereich für das Café-Team“. Beschreibe, was passiert. Sieh dir dazu die Reiter Antwort und Server an.

b) Melde dich als team an. Beschreibe, was der Server dabei speichert (Reiter Datenbank) und was der Browser speichert (Reiter Cookies). Vergleiche die beiden Werte.

c) Rufe danach noch einmal team.php auf. Sieh dir die Anfrage an und erkläre, woran der Server erkennt, dass du angemeldet bist.

d) Klicke auf „Preise ändern“. Melde dich dann ab und als leitung wieder an und versuche es erneut. Vergleiche die beiden Antworten (Statuscodes).

e) Vermute zuerst, was passiert, wenn du im Reiter Cookies den Wert des Cookies änderst (zum Beispiel ein Zeichen austauschst) und dann team.php neu lädst. Probiere es aus.

Tipp 1

Zu a): Achte in der Antwort auf den Statuscode und die Kopfzeile Location. Im Reiter Anfrage siehst du, dass der Browser danach von selbst eine zweite Anfrage geschickt hat.

Lösung

Erkundung 2: Ein Blick in die Konten mittel

Das hat der Browser an den Server geschickt:

Anfrage von Hand ändern und senden

So wie mit den Entwicklerwerkzeugen kann man eine Anfrage beliebig verändern. Der Server muss damit rechnen.

Was der Server bei der letzten Anfrage getan hat:

Das hat der Server zurückgeschickt (Kopfzeilen und HTML):

Passwörter im Klartext speichern (unsicher) Anmeldeversuche begrenzen (3 Fehlversuche → 30 s Sperre) team.php nur nach Anmeldung

a) Sieh dir im Reiter Datenbank die Tabelle der Konten an. Beschreibe, was dort statt der Passwörter gespeichert ist. Kannst du daraus das Passwort von team ablesen?

b) Setze den Haken bei „Passwörter im Klartext speichern“ und sieh dir die Tabelle noch einmal an. Erläutere, wer in diesem Fall die Passwörter lesen könnte.

c) Rufe cafe.example/bestellen.html auf und bestelle etwas. Entferne dann den Haken bei „team.php nur nach Anmeldung“ und rufe ohne Anmeldung cafe.example/team.php auf. Beurteile damit Tims Idee aus dem Einstieg.

d) Melde dich mehrmals mit einem falschen Passwort an. Setze dann den Haken bei „Anmeldeversuche begrenzen“ und versuche es dreimal. Erkläre, wozu die Sperre gut ist.

Tipp 1

Zu b): Denke an alle, die Zugriff auf die Datenbank haben könnten, nicht nur an Angreifer von außen. Und daran, dass viele Menschen dasselbe Passwort für mehrere Dienste verwenden.

Lösung

Wer bist du, und was darfst du?

Vergleicht eure Ergebnisse. Eine Zugangskontrolle beantwortet zwei verschiedene Fragen:

	Authentifizierung	Autorisierung
Frage	Wer bist du?	Was darfst du?
Beispiel im Café	Anmeldung mit Benutzername und Passwort	nur die Rolle `leitung` darf Preise ändern
Statuscode, wenn es scheitert	401 Unauthorized (nicht angemeldet)	403 Forbidden (angemeldet, aber nicht berechtigt)

Zuerst kommt immer die Authentifizierung, dann die Autorisierung. Rechte vergibt man meist über Rollen: Nicht jede Person bekommt einzeln Rechte, sondern jede Person hat eine Rolle (hier team oder leitung), und die Rolle hat Rechte.

Seine Identität kann man auf drei Arten nachweisen, mit Wissen (Passwort, PIN), Besitz (Handy, Chipkarte, Schlüssel) oder einem Merkmal der Person (Fingerabdruck, Gesicht). Aus IT 12.4 kennst du die Stufen Zutritt, Zugang und Zugriff: Die Anmeldung an einer Webanwendung ist eine Zugangskontrolle, die Prüfung der Rechte eine Zugriffskontrolle.

Sitzungen und Cookies

HTTP hat kein Gedächtnis: Jede Anfrage steht für sich. Der Server weiß bei der zweiten Anfrage nicht von selbst, dass dieselbe Person schon angemeldet ist. Die Lösung ist eine Sitzung (englisch session):

Nach der erfolgreichen Anmeldung legt der Server eine Sitzung an und merkt sich darin, wer angemeldet ist und welche Rolle die Person hat.
Die Sitzung bekommt eine lange, zufällige Sitzungsnummer. Der Server schickt sie mit Set-Cookie an den Browser.
Der Browser speichert sie als Cookie und schickt sie bei jeder weiteren Anfrage an diesen Server mit.
Jedes geschützte Skript sucht die Sitzung zur Nummer und prüft, ob und als wer jemand angemeldet ist.
Beim Abmelden löscht der Server die Sitzung. Die Nummer ist danach wertlos.

Die Sitzungsnummer funktioniert wie eine Garderobenmarke: Wer die Marke hat, bekommt die Jacke. Deshalb muss sie geheim, lang und zufällig sein, und deshalb vergibt login.php mit session_regenerate_id(true) bei jeder Anmeldung eine neue Nummer.

In der Antwort des Simulators steht zum Beispiel Set-Cookie: PHPSESSID=…; path=/; HttpOnly; SameSite=Lax. HttpOnly bedeutet: JavaScript in der Seite kann das Cookie nicht lesen. Bei HTTPS kommt Secure hinzu: Der Browser schickt das Cookie nur über verschlüsselte Verbindungen.

Passwörter speichern

Ein Server sollte Passwörter nie im Klartext speichern. Stattdessen speichert er einen Hash:

Eine Hashfunktion berechnet aus einem Text einen Wert fester Länge, den Hashwert. Derselbe Text ergibt immer denselben Hashwert. Schon eine kleine Änderung ergibt einen völlig anderen.
Aus dem Hashwert lässt sich der Text nicht zurückrechnen (Einwegfunktion).
Bei der Anmeldung berechnet der Server den Hash der Eingabe und vergleicht ihn mit dem gespeicherten. In PHP erledigen das password_hash() beim Anlegen und password_verify() beim Anmelden.

Damit gleiche Passwörter nicht denselben Hash ergeben, hängt der Server vor dem Hashen ein Salz an: eine zufällige Zeichenfolge, die für jedes Konto anders ist und mit dem Hash gespeichert wird. So nützen Angreifern vorberechnete Listen mit den Hashes häufiger Passwörter nichts.

Der Simulator verwendet zur Anschauung das Verfahren SHA-256. Für Passwörter nutzt man in echten Anwendungen absichtlich langsame Verfahren wie bcrypt, das password_hash() in PHP standardmäßig verwendet. Langsam heißt hier: Ein Hash dauert einen Bruchteil einer Sekunde. Für eine Anmeldung merkt man das nicht, aber das Durchprobieren von Millionen Passwörtern wird sehr aufwendig.

Angriffe erschweren

Typische Angriffe auf eine Anmeldung und was dagegen hilft:

Angriff	Gegenmaßnahme
Passwörter durchprobieren (Brute Force)	Versuche begrenzen, Wartezeit nach Fehlversuchen
herausfinden, welche Benutzernamen es gibt	immer dieselbe Fehlermeldung „Benutzername oder Passwort falsch“
Mitlesen auf dem Weg	HTTPS
erbeutete Datenbank	nur Hashes mit Salz speichern
fremde Sitzungsnummer nutzen	lange zufällige Nummern, neue Nummer nach der Anmeldung, `HttpOnly`, `Secure`, Abmelden löscht die Sitzung
erratene oder anderswo erbeutete Passwörter	lange Passwörter, nicht mehrfach verwenden, zweiter Faktor

Bei einer Zwei-Faktor-Authentifizierung braucht man zusätzlich zum Passwort (Wissen) einen zweiten Nachweis einer anderen Art, zum Beispiel einen Code aus einer App auf dem Handy (Besitz).

Café-App: Schritt 11

Café-App, Schritt 11: Die Anmeldung für das Team mittel

Lege die Seite login.html im Design der Café-Seite an. Sie enthält ein Formular, das mit POST an login.php sendet, mit den Feldern benutzer und passwort (Typ password) und einem Knopf „Anmelden“. Denke an die label-Elemente.
Ergänze in der Fußzeile aller Seiten einen unauffälligen Link „Für das Team“ auf login.html.
Ergänze in plan.txt einen Abschnitt „Zugangskontrolle“: Welche Seiten müssen geschützt werden? Welche Rollen gibt es, und was darf jede? Was steht in der Datenbank über jedes Konto, was in der Sitzung, was im Cookie?
Das Team möchte eine weitere Seite ausverkauft.php, auf der jedes Teammitglied Produkte als ausverkauft markieren kann. Beschreibe in plan.txt, was diese Seite ganz am Anfang prüfen muss und was passiert, wenn die Prüfung scheitert. Zusatz: Schreibe die passenden PHP-Zeilen als Kommentar dazu.

Tipp 1

Zu 1: Mit autocomplete="username" und autocomplete="current-password" erkennen Passwortmanager die Felder.

Tipp 2

Zu 4: Vorbild ist der Anfang von team.php (Erkundung 1, Reiter Server). Dürfen beide Rollen auf die Seite?

Stand nach Schritt 11

Aufgaben

Aufgabe 1: Authentifizierung oder Autorisierung? leicht

Ordne jede Situation der Authentifizierung oder der Autorisierung zu. Begründe kurz.

Du entsperrst dein Handy mit dem Fingerabdruck.
Der Hausmeister darf den Serverraum betreten, Schülerinnen und Schüler nicht.
Du gibst im Schulportal Benutzername und Passwort ein.
Eine Lehrkraft darf Noten eintragen, eine Schülerin darf ihre Noten nur ansehen.
Nach dem Passwort gibst du einen sechsstelligen Code aus einer App ein.
Ein angemeldeter Schüler ruft die Adresse verwaltung.php auf und bekommt den Statuscode 403.

Lösung

Aufgabe 2: Eine Anmeldung darstellen mittel

In der Online-Ausleihe der Stadtbücherei meldet sich eine Nutzerin an und lässt sich danach die Liste ihrer ausgeliehenen Bücher anzeigen.

Stelle den Ablauf in drei Abschnitten dar: Seite aufrufen, Anmeldedaten absenden, eigene Ausleihen anzeigen. Gib jeweils an, was der Client (Browser) und was der Server tut. Gehe dabei auch auf Sitzung und Cookie ein.

Tipp 1

Erkundung 1 zeigt den Ablauf im Café. Übertrage ihn: Welche Anfrage schickt der Browser, was prüft und speichert der Server, was schickt er zurück?

Lösung (Beispiel)

Aufgabe 3: Wie speichert der Sportverein die Passwörter? mittel

Drei Sportvereine haben Webseiten mit Mitgliederbereich. Sie speichern die Passwörter so:

Verein A: im Klartext
Verein B: verschlüsselt mit einem Schlüssel, der ebenfalls auf dem Server liegt
Verein C: als Hash mit Salz (password_hash)

a) Bei allen drei Vereinen haben Angreifer die Datenbank kopiert. Beurteile für jeden Verein, was die Angreifer mit den Daten anfangen können.

b) Bei Verein A und B bekommt man unter „Passwort vergessen“ sein altes Passwort per E-Mail zugeschickt. Bei Verein C nur einen Link, mit dem man ein neues Passwort festlegt. Erkläre, warum Verein C das alte Passwort gar nicht schicken könnte.

Tipp 1

Zu a): Was ist der Unterschied zwischen Verschlüsseln und Hashen? Wer den Schlüssel hat, kann … Und wo liegt der Schlüssel bei Verein B?

Lösung

Aufgabe 4: Code lesen – Schwachstellen finden schwer

Für die Webseite der Schülerzeitung hat jemand eine Anmeldung programmiert. Die Passwörter stehen in der Datenbank im Feld passwort.

login.php:

<?php
$name  = $_POST['benutzer'] ?? '';
$pw    = $_POST['passwort'] ?? '';
$konto = findeBenutzer($name);

if ($konto === null) {
  echo '<p>Diesen Benutzer gibt es nicht.</p>';
  exit;
}
if ($pw !== $konto['passwort']) {
  echo '<p>Das Passwort ist falsch.</p>';
  exit;
}
setcookie('benutzer', $konto['name']);
setcookie('rolle', $konto['rolle']);
header('Location: redaktion.php');
?>

redaktion.php beginnt so:

<?php
if (($_COOKIE['rolle'] ?? '') !== 'redaktion') {
  http_response_code(403);
  echo '<p>Keine Berechtigung.</p>';
  exit;
}
?>

a) Beschreibe, wie die Anmeldung abläuft, wenn Benutzername und Passwort richtig sind.

b) Ermittle mindestens vier Schwachstellen. Erläutere jeweils, wie man sie ausnutzen könnte.

c) Beschreibe für jede Schwachstelle aus b), wie man sie beseitigt.

d) Zusatz: Entwickle eine verbesserte Fassung beider Anfänge in PHP.

Tipp 1

Zu b): Wer bestimmt, was in einem Cookie steht? Denke an den Reiter Cookies im Simulator: Dort konntest du Werte ändern.

Tipp 2

Zu b): Gehe die Tabelle im Abschnitt „Angriffe erschweren“ Zeile für Zeile durch.

Lösung

Aufgabe 5: Saras Passwortabfrage schwer

Sara aus dem Einstieg hat ihre Idee umgesetzt. In team.html steht:

<h1>Bestellungen heute</h1>
<table id="bestellungen" hidden>
  <tr><td>B001</td><td>Lisa Weber</td><td>11FO</td><td>1 × Kakao</td></tr>
  <tr><td>B002</td><td>Jonas Kaya</td><td>12FO</td><td>2 × Brezel</td></tr>
</table>
<script>
  const eingabe = prompt('Passwort für den Team-Bereich:');
  if (eingabe === 'Kakao2026') {
    document.getElementById('bestellungen').hidden = false;
  } else {
    alert('Falsches Passwort');
  }
</script>

Nimm Stellung zu Saras Lösung. Nenne mindestens zwei Wege, wie jemand ohne Passwort an die Daten kommt, und beschreibe, wie es richtig gemacht wird.

Tipp 1

Was bekommt der Browser alles vom Server, bevor das Skript überhaupt läuft? Was zeigt „Seitenquelltext anzeigen“?

Lösung (Beispiel)

Zusatzaufgabe: Zwei Faktoren schwer Zusatz

a) Erläutere, warum eine Zwei-Faktor-Authentifizierung auch dann schützt, wenn das Passwort bekannt geworden ist.

b) Ein Dienst fragt nach dem Passwort und danach nach der Antwort auf die Sicherheitsfrage „Wie hieß dein erstes Haustier?“. Beurteile, ob das eine Zwei-Faktor-Authentifizierung ist.

c) Vergleiche einen Code aus einer Authentifizierungs-App auf dem Handy mit einem Code per SMS. Ermittle dazu Informationen bei einer seriösen Quelle (zum Beispiel beim Bundesamt für Sicherheit in der Informationstechnik, BSI) und gib die Quelle an.

Lösung (Beispiel)

Zusammenfassung

Authentifizierung: Wer bist du? (Anmeldung, scheitert mit 401 bzw. Weiterleitung zur Anmeldung). Autorisierung: Was darfst du? (Rechte über Rollen, scheitert mit 403).
HTTP hat kein Gedächtnis. Nach der Anmeldung führt der Server eine Sitzung. Der Browser bekommt nur die zufällige Sitzungsnummer als Cookie und schickt sie bei jeder Anfrage mit.
Jede geschützte Seite prüft selbst und bei jeder Anfrage, ob eine gültige Sitzung besteht und ob die Rolle passt.
Passwörter werden als Hash mit Salz gespeichert (password_hash, password_verify), nie im Klartext. Ein Hash lässt sich nicht zurückrechnen.
Angriffe erschweren: Versuche begrenzen, einheitliche Fehlermeldung, HTTPS, neue Sitzungsnummer nach der Anmeldung, zweiter Faktor.
Geheime Adressen und Passwortabfragen nur in JavaScript sind kein Schutz.

Selbstcheck

Geh die Fragen ehrlich durch. Wenn du bei einer unsicher bist, lies den verlinkten Abschnitt noch einmal oder bearbeite die passende Aufgabe.

Kannst du Authentifizierung und Autorisierung unterscheiden? → Erkundung 1, Wer bist du, und was darfst du?, Aufgabe 1
Kannst du den Ablauf einer Anmeldung mit Sitzung und Cookie beschreiben? → Sitzungen und Cookies, Aufgabe 2
Kannst du erklären, warum Passwörter als Hash mit Salz gespeichert werden? → Erkundung 2, Passwörter speichern, Aufgabe 3
Kannst du Schwachstellen erkennen und beurteilen? → Angriffe erschweren, Aufgabe 4, Aufgabe 5
Kannst du Maßnahmen für eine sichere Anmeldung begründen? → Café-App, Aufgabe 4

Wortspeicher

Begriff	Bedeutung in einfachen Worten
Zugangskontrolle	sicherstellen, dass nur Berechtigte einen Bereich nutzen
Authentifizierung	nachweisen, wer man ist
Autorisierung	prüfen, was eine Person darf
Rolle	Gruppe mit festgelegten Rechten, z. B. `team` oder `leitung`
Sitzung (Session)	Speicher auf dem Server, der sich merkt, wer angemeldet ist
Sitzungsnummer	lange zufällige Nummer, mit der der Server die Sitzung wiederfindet
Cookie	kleiner Wert, den der Browser für eine Seite speichert und bei jeder Anfrage mitschickt
Weiterleitung (302)	Antwort „Frag bitte diese andere Adresse ab“
401 / 403	nicht angemeldet / angemeldet, aber nicht berechtigt
Hash	Wert, der aus einem Text berechnet wird und sich nicht zurückrechnen lässt
Salz	zufällige Zeichenfolge, die vor dem Hashen an das Passwort gehängt wird
Brute-Force-Angriff	Passwörter durch massenhaftes Ausprobieren erraten
Zwei-Faktor-Authentifizierung	Anmeldung mit zwei Nachweisen verschiedener Art, z. B. Passwort und Handy

Quellen

Hessisches Kultusministerium: Kerncurriculum Fachoberschule, Fachrichtung Technik, Schwerpunkt Informationstechnik, Themenfeld 12.6 Webanwendungen, „Zugangskontrolle“, „Konzepte serverseitiger Skriptsprachen“ (Stand November 2022).
PHP-Dokumentation (php.net): password_hash, Sitzungen (Du verlässt jetzt Maternet).
Bundesamt für Sicherheit in der Informationstechnik: Hinweise zu sicheren Passwörtern und zur Zwei-Faktor-Authentisierung, bsi.bund.de (Du verlässt jetzt Maternet).
HTTP-Statuscodes nach RFC 9110, Cookies nach RFC 6265.
Texte, Beispiele, Aufgaben und der Server-Simulator sind selbst erstellt. Die Demo-Zugänge im Simulator sind erfunden. Namen in den Beispielen sind erfunden. cafe.example ist eine Beispieladresse nach RFC 2606.