### Experimente mit Cross-site request forgery

Hier finden Sie eine Sammlung von Seiten, die alle in der ein oder anderen Form Cross-site request forgery mit dem Login-Server auf `http://localhost:4013` machen wollen. Stellen Sie sicher, dass diese Seite hier von einem anderen Host kommt (starten Sie beispielsweise `http-server .` in diesem Verzeichnis) und laden die Seite über http://127.0.0.1:8080/csrf-possibilities.html.

- read-message-by-link.html enthält einen Link, über den Sie zu `localhost:4013/main` gelangen. Wenn Sie auf `localhost:4013` bereits eingeloggt sind: landen Sie direkt im Nachrichten-Versende-Fenster oder schickt Sie der Server zum Login-Bildschirm?
- logout-with-link-1.html ist bereits etwas boshafter. Wenn Sie auf den Link darin klicken, werden Sie ausgeloggt. Oder?
- logout-with-link-1.html ist bereits etwas boshafter. Wenn Sie auf den Link darin klicken, werden Sie ausgeloggt. Oder?
- logout-with-link-2-image.html ist hinterhältiger. Es versucht, die Login-Seite automatisch ohne Ihr Zutun zu laden. Scheitert aber. Warum?
- logout-with-link-2-image-https.html versucht das gleiche, kommuniziert aber über Https. Wenn `https://localhost:4013` läuft und `same-site-policy=None` gesetzt ist, dann: Ja! Diese Seite loggt Sie ohne Ihr Zutun aus, indem sie ein "Bild" lädt.
- Hier kommen Sie direkt zu http://localhost:4013/redirect.html, wo Sie direkt weitergeleitet werden zu `http://localhost:4013/main`. Da die weiterleitende Seite ja bereits auf `localhost:4013` liegt, zählt das jetzt also Cross-Site-Request oder Same-Site-Request? In anderen Worten: wenn `server.js` die Cookies auf `SameSite=Strict` gesetzt hat, schickt die Weiterleitung dann die Cookies mit?
- Hier können Sie über ein `form`-Element einen `POST`-Request erzeugen: post-by-form.html
- Das gleiche mit Https: post-by-form-https.html

Und zum Schluss: gehen Sie per Klick auf gmail.com und schauen, ob Sie gleich "reinkommen" oder zum Login-Bildschirm geführt werden.