1UnitedPower: PHP Code in externer Datei

Beitrag lesen

Hakuna matata!

Wenn die mögliche Manipulation / das Auslesen der Daten egal ist (wobei das Auslesen ja auch immer möglich ist, auch beim Platzhalter-Ersetzen und die JS-Manipulation nach dem zur Laufzeit der Seite auch immer möglich ist) halte ich meine Methode immer noch für schöner.

Du verstehst hotti einfach falsch. Die Sicherheitsbedenken, die er hat, richten sich nicht gegen das clientseitige Auslesen der Daten.

Das Problem ensteht, weil man Daten-Ping-Pong spielt. Der Server schickt dem Client die Nutzer-ID über ein Cookie, beim nächsten Request schickt der Client die Nutzer-ID an den Server zurück. Das selbe gilt für dei hidden-input-Variante: der Server schreibt die Nutzer-ID in ein hidden-input, beim Absenden des Formulars schickt der Client die Nutzer-ID zurück an den Server.

Für den Server besteht in der zweiten Runde keine Gewissheit mehr, dass es sich bei der Nutzer-ID, um die selbe handelt, die er vorher dem Client verraten hat. Der Server sollte sich deshalb nicht darauf verlassen und sollte zum Beispiel keine Authorisierung auf Basis dieses Cookies bauen.

Wenn der Server das Nutzer-ID Cookie immer nur schreibt und niemals liest und davon ausgehend weitere Logik startet, dann ist das Cookie in diesem Fall überhaupt kein sicherheitsrelevantes Problem. Ebensowenig das hidden-input-Feld.

Die JavaScript-Lösung von dir hat mit diesem potenziellen Sicherheitsrisiko sowieso nichts zu tun, weil die Daten nicht an den Server zurück geschickt werden. Es besteht also auch kein Grund zur Panik, dass der Server irgendwelche naiven Schritte unternimmt.

--
“All right, then, I'll go to hell.” – Huck Finn