PHP-Session-Login – Ein IT-Projekt mit KI

Warum überhaupt?

Klassisches HTTP Basic Auth ist der einfachste Schutz für eine private Webseite – funktioniert aber in manchen Browser-/Proxy-Konstellationen schlicht nicht: der Anmelde-Dialog kommt nie hoch, der Besucher sieht nur eine leere Seite oder eine generische Fehlermeldung. Genau das war bei Voggenreiter mit dem ursprünglichen Apache-Basic-Auth-Setup auf intern, hinter Login passiert.

Die Antwort: ein eigener Auth-Layer in PHP. Statt sich auf den Browser- Dialog zu verlassen, liefert die Seite eine ganz normale HTML-Login- Karte aus – das funktioniert immer, egal welcher Browser oder welcher Proxy dazwischen sitzt. Gleichzeitig bleibt der Aufwand klein: eine einzelne PHP-Datei, keine Datenbank, keine externen Dienste.

So läuft eine Anfrage

Jede ausgelieferte Seite endet auf .php und beginnt mit einer einzigen Zeile: require_once $_SERVER['DOCUMENT_ROOT'] . '/der Zugangsschutz über PHP-Sitzungen';. Diese Datei prüft das Session-Flag $_SESSION['authed'].

Ist es gesetzt, kehrt sie still zurück und die Seite rendert normal. Ist es nicht gesetzt, antwortet sie selbst mit HTTP 401 und einer eingebetteten Login-Karte. Wer Benutzername und Passwort einträgt, schickt einen POST an dieselbe URL: der Zugangsschutz über PHP-Sitzungen prüft den Hash mit password_verify, regeneriert die Session-ID, setzt das Auth-Flag und macht einen 302-Redirect auf die ursprünglich angefragte Seite. Ab dann liefert der Browser den Cookie KIR_SESSION bei jedem Request mit – 30 Tage lang.

Was den Layer hart macht

bcrypt statt MD5/APR1: moderne Hashes mit Cost 12, kein selbstgebautes Passwort-Vergleichen
Session-Regeneration nach Login: session_regenerate_id(true) verhindert Session-Fixation
Cookie-Härtung: Secure (nur HTTPS), HttpOnly (kein JS-Zugriff), SameSite=Lax (kein CSRF aus Fremdseiten)
Brute-Force-Bremse: 500 ms usleep bei falschem Passwort macht systematisches Durchprobieren spürbar teurer
Source bleibt verborgen: der Zugangsschutz über PHP-Sitzungen liegt zwar im Web-Root, wird aber von Apache als PHP geparst – der Klartext-Hash wird nie ausgeliefert
Sichere Defaults für Security-Header: HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy und Permissions-Policy werden direkt in der Zugangsschutz über PHP-Sitzungen per header() gesetzt – als defensive Doppelung gedacht, tatsächlich die einzige Ebene, weil die Server-Konfiguration auf dieser NAS nie ausgewertet wurde. Der Nebeneffekt: Was nicht durch PHP läuft, trägt die Kopfzeilen auch nicht

Bewusste Trennung von der Plattform

Wer sich auf der Webseite anmeldet, ist kein Nutzer des darunter liegenden Systems (auf der NAS: kein DSM-User, kein SFTP-Konto, kein SMB-Zugriff). Die Hash-Liste in der Zugangsschutz über PHP-Sitzungen ist eine völlig eigene Welt. Selbst wenn das Web-Passwort kompromittiert würde, käme jemand maximal an die ohnehin private Webseite – nicht an Dateien, nicht an die DSM-Oberfläche, nicht an andere Dienste am gleichen Rechner.

Skalierungs-Pfad

Der Aufbau ist absichtlich klein gehalten: eine Datei, eine Liste. Für ein bis fünf Nutzer ist das ideal – kein Overhead, kein Server, keine Datenbank. Wenn mehr Nutzer dazukommen, lässt sich die User-Liste in eine SQLite-Datei auslagern oder gegen einen externen OIDC-Provider tauschen. Die eigentliche Auth-Mechanik (Cookie, Session-Handling, in-page-Form, Security-Header) bleibt dabei identisch.

Wofür sich PHP-Session-Login NICHT lohnt

Öffentliche Webseiten mit Self-Service-Registrierung – da fehlen Mail-Bestätigung, Passwort-Reset, Account-Sperre als eigenständige Subsysteme
Mehrstufige Rollen-/Rechtekonzepte – der Layer kennt nur eingeloggt oder nicht, kein RBAC
Hosts, die kein PHP ausliefern können (rein statische Hoster wie GitHub Pages) – dort hilft nur ein vorgeschalteter Reverse-Proxy mit eigener Auth

Eingesetzt in

← zurück zur Baustein-Übersicht