Wie mir Claude bei meinem Link Tool geholfen hat
Mein Problem
Ich hatte ein PHP Tool gebaut, mit dem man Links passwortgeschützt sammeln kann. Lief technisch, aber ich kam nicht mehr weiter und wusste nicht, wo die Schwachstellen liegen.
(Demo) Passwort: 1401Wer Interesse an diesem Werkzeug hat, möge sich bitte über das Kontaktformular melden. Ich werde die Dateien dann umgehend zusenden.
Geschützte Link‑Sammlung
Geschützte Link Sammlung
Was ich gemacht habe
- Alle Dateien (admin.php, config.php, links.html, links.txt, save.php) hochgeladen und um Review gebeten.
- Claude hat vier konkrete Probleme gefunden: Passwort wurde offen an den Browser geschickt, der Speicher-Endpunkt hatte keinerlei Schutz, Admin-Ausgabe war anfällig für Script Einschleusung, und Links ohne http/https-Prefix wären möglich gewesen.
- Claude hat die Dateien direkt repariert (neue auth.php für serverseitige Passwortprüfung, Session Check in save.php, Escaping im Admin-Bereich, URL-Validierung) und zum Download bereitgestellt.
- Beim Testen ist aufgefallen: neu gespeicherte Links verschwanden nach Neuladen wieder.
- Claude hat den eigentlichen Grund erklärt (save.php meldete "OK", auch wenn das Schreiben fehlschlug z.B. wegen fehlender Dateirechte) und den Code so angepasst, dass jetzt eine echte Fehlermeldung kommt statt einer stillen Falschmeldung.
- Danach noch einen kurzen HTML-Beitrag zum ganzen Vorgang erstellen lassen, als Dokumentation der gefundenen Fehler.
Ergebnis
Aus einem funktionierenden, aber unsicheren Tool wurde eine Version mit echter serverseitiger Passwortprüfung, geschütztem Speichern und ehrlichen Fehlermeldungen statt stiller Fehlschläge.
Ein passwortgeschütztes Link Tool mit PHP bauen und aus den Fehlern lernen
Manchmal braucht man kein großes CMS, sondern nur eine einfache Seite, auf der man Links sammeln und mit einem Passwort schützen kann. Genau so ein kleines Tool habe ich kürzlich gebaut: eine HTML Seite mit Passwortabfrage, dazu ein PHP Backend, das die Links in einer Textdatei speichert, plus einen Admin Bereich zum Bearbeiten. Klingt simpel und genau da liegt die Gefahr.
Die Ausgangslage
Der erste Entwurf bestand aus fünf Dateien:
- links.html die öffentliche Seite mit Passwortfeld und Linkliste
- config.php lieferte Konfigurationswerte als JSON
- save.php schrieb neue Links in eine Textdatei
- admin.php ein separater Admin Bereich zum direkten Bearbeiten der Datei
- links.txt die eigentliche Datenbank, ganz simpel als Textdatei
Funktional lief das Ganze auch. Trotzdem steckten darin gleich mehrere klassische Anfängerfehler, die man beim schnellen Bauen eines Tools leicht übersieht.
Fehler 1: Das Passwort wurde an den Client geschickt
Die Konfigurationsdatei lieferte das Master Passwort im Klartext als JSON aus. Die eigentliche Prüfung fand dann im Browser per JavaScript statt. Das Problem: Jeder, der die Konfigurationsdatei direkt aufruft, sieht das Passwort sofort ganz ohne es zu erraten. Eine clientseitige Passwortprüfung ist im Grunde keine Prüfung, wenn das Passwort vorher ungeschützt übertragen wird.
Die Lösung: Das Passwort bleibt auf dem Server. Ein neuer Endpunkt nimmt die Eingabe entgegen, vergleicht sie serverseitig und setzt bei Erfolg eine Session. Der Client bekommt nie mehr als ein einfaches "ok" oder "falsch" zu sehen.
Fehler 2: Der Speicher Endpunkt hatte gar keinen Schutz
Die Datei, die neue Links entgegennahm, prüfte überhaupt nicht, ob jemand eingeloggt war. Wer die URL kannte, konnte die komplette Linkliste überschreiben unabhängig davon, ob er das Passwort je eingegeben hatte. Der ganze Login Bildschirm war damit reine Fassade.
Die Lösung: Der Speicher Endpunkt prüft jetzt, ob eine gültige Session existiert, bevor überhaupt etwas geschrieben wird.
Fehler 3: Ungefilterte Ausgabe im Admin Bereich
Im Admin Bereich wurde der Inhalt der Textdatei direkt in ein Textfeld geschrieben, ohne die Zeichen zu escapen. Enthielt ein Eintrag zufällig bestimmte HTML Sonderzeichen, konnte das Textfeld verlassen und beliebiger Code eingeschleust werden eine klassische Cross Site Scripting Lücke.
Die Lösung: Jeder Ausgabetext, der aus gespeicherten Daten stammt, wird vor der Anzeige escaped.
Fehler 4: Erfolg gemeldet, obwohl gar nichts gespeichert wurde
Der subtilste Fehler zeigte sich erst später: Das Backend meldete dem Browser immer "OK" zurück auch dann, wenn das Schreiben der Datei aus Rechtegründen gescheitert war. Das Frontend prüfte diese Antwort nicht weiter, sondern räumte einfach die Eingabefelder auf. Für den Nutzer sah es so aus, als sei der Link gespeichert worden. Erst beim nächsten Laden der Seite fiel auf, dass der neue Eintrag fehlte.
Die Lösung: Das Backend prüft jetzt aktiv, ob die Datei überhaupt beschreibbar ist und ob der Schreibvorgang wirklich funktioniert hat. Bei einem Fehler kommt eine echte, sichtbare Fehlermeldung zurück und das Frontend übernimmt eine Änderung erst dann in die Anzeige, wenn der Server den Erfolg bestätigt hat.
Was man daraus mitnehmen kann
Keiner dieser Fehler war exotisch. Genau das macht sie gefährlich: Passwörter an den Client zu schicken, Schreibvorgänge ohne Rückmeldung ablaufen zu lassen oder gespeicherte Daten ungefiltert wieder auszugeben das sind Muster, die sich in vielen kleinen, selbst gebauten PHP Tools finden. Ein Tool muss nicht groß sein, um Sicherheitslücken zu haben. Es lohnt sich, bei jedem Formular, jedem Speicher Endpunkt und jeder Ausgabe kurz zu fragen: Wer könnte diese Stelle sonst noch aufrufen und was passiert, wenn etwas schiefgeht, ohne dass es jemand merkt?