Wenn wir eine fremde Laravel-Anwendung prüfen, ähneln sich die Befunde erstaunlich. Das liegt nicht daran, dass alle denselben Fehler machen. Es liegt daran, dass unter Zeitdruck immer dieselben Stellen als Erstes liegen bleiben.
1. Berechtigungen werden in der Oberfläche geprüft, nicht im Zugriff
Der Knopf zum Löschen wird für Benutzer ohne Recht ausgeblendet, die Route dahinter prüft aber nichts. Wer die Adresse kennt, löscht trotzdem. Mit Abstand der häufigste Befund, und gleichzeitig der folgenschwerste.
Die Prüfung gehört an den Zugriff selbst, in Laravel also in eine Policy oder ein Gate, und sie muss auch dann greifen, wenn der Aufruf nicht aus der eigenen Oberfläche kommt.
2. Massenzuweisung ohne Begrenzung
Ein Formular schickt Felder, das Model übernimmt sie. Bequem, bis jemand ein Feld mitsendet,
das im Formular gar nicht vorkommt, etwa eine Rollenkennung. Wer Eingaben ungefiltert an
create oder update weiterreicht, öffnet genau diese Tür.
Die Absicherung ist unspektakulär: explizit festlegen, welche Felder zuweisbar sind, und im Request nur das validieren und weitergeben, was auch hingehört.
3. Datei-Uploads ohne echte Prüfung
Häufig wird die Dateiendung geprüft, manchmal der vom Browser gemeldete Typ. Beides kommt vom Client und beweist deshalb gar nichts. Dazu landen die hochgeladenen Dateien oft in einem Verzeichnis, das der Webserver direkt ausliefert.
Nötig ist eine serverseitige Typprüfung, ein neu vergebener Dateiname und eine Ablage, aus der nicht direkt ausgeliefert wird. Der Abruf läuft dann über eine Route, die vorher die Berechtigung prüft.
4. Konfiguration aus der Entwicklung im Betrieb
Die Fehleranzeige ist eingeschaltet, und die nächste Ausnahme zeigt Datenbankzugänge und Dateipfade. Oder die Zwischenspeicher für Konfiguration und Routen fehlen, was neben der Geschwindigkeit vor allem eines heißt: Den Betriebsmodus hat nie jemand geprüft.
Behoben ist so etwas in einer Stunde. Im Bericht steht es trotzdem regelmäßig.
5. Protokolle, die zu viel wissen
Beim Suchen eines Fehlers werden Anfragedaten protokolliert, und die Zeile bleibt danach drin. Ab da stehen Passwörter, Tokens oder personenbezogene Daten in einer Datei, die viele Leute lesen dürfen und die selten jemand aufräumt. Ein Sicherheitsthema, und gleichzeitig eines für den Datenschutz.
6. Abhängigkeiten aus einer anderen Zeit
Die Anwendung läuft, also fasst sie niemand an. Nach drei Jahren sind Dutzende Pakete veraltet, einige mit bekannten Schwachstellen, und keines lässt sich mehr einzeln aktualisieren, weil alle voneinander abhängen.
Ein Sicherheitsfehler im engeren Sinn ist das nicht. Es ist ein Wartungsversäumnis mit Sicherheitsfolgen, und der Grund, warum regelmäßige Pflege billiger kommt als gelegentliche Rettungsaktionen.
Was daraus folgt
Spezialwissen verlangt keiner dieser Punkte. Sie verlangen, dass jemand hinsieht, bevor es einen Anlass dazu gibt. Wie wir dabei vorgehen und was Sie am Ende in der Hand halten, steht unter Beratung und Code-Audit.
