Mailinglisten-Archive |
Carsten Brenner wrote: > <a href="<? form_submit() ?>"> oder ähnliches.. oder gibts ein <a > href="javascript:submit"> ?? Selbst wenn es so etwas gäbe (ich habe mir nicht die Mühe gemacht, das nachzusehen) bedeutet dies, daß der Zustand der Anwendung mit jedem Submit zwischen dem Browser und der Anwendung Ping-Pong spielt: Browser Anwendung Variablen -- submit ---> Variablen (1) Variablen <-- neue Seite --- Variablen (2) Variablen -- submit ---> Variablen (3) Variablen <-- neue Seite --- Variablen (4) und so weiter. Das bedeutet, daß auf der Seite des Browsers der Benutzer jedesmal die Chance hat, mit den Werten der Anwendung herumzuspielen und diese Werte zu manipulieren. Die Anwendung akzeptiert also mit jeder Seite neu Variablen aus einem untrusted Area, die sie jedesmal neu validieren muß. Die Anwendung kann sich ja nicht darauf verlassen, daß sie die Werte, die ihr zurück gepostet werden, auch jemals aus der Seite erzeugt hat - der Anwender kann inzwischen alles mit den Werten gemacht haben. Nimm zum Beispiel eine Authentisierung. PHPLIB merkt sich intern in einer Variablen uid ($auth->auth["uid"]) die interne Benutzerkennung des Anwenders und in einer anderen Variablen exp ($auth->auth["exp"]) den Zeitpunkt, ab dem die uid ungültig wird und der Benutzer sich neu anmelden muß. Würden diese Variablen immer wieder zwischen Browser und Anwendung gepingt werden, könnte der Anwender durch Manipulation des Wertes exp ein ewiges Login erzeugen, ohne daß die Anwendung dies prüfen kann. Oder er kann durch Manipulation von uid eine beliebige Identität annehmen, wenn es ihm gelingt, eine gültige uid zu raten. Tatsächlich realisiert PHPLIB aus genau diesem Grunde das ganze etwas anders: Browser Anwendung Datenbank session id -- cookie --> session id <-- r/w --> variablen[session id] session id <-- setcookie -- session id session id -- cookie --> session id <-- r/w --> variablen[session id] session id <-- setcookie -- session id Da die Anwendung und die Datenbank Bestandteil der Anwendungsseite sind und beide in derselben Trust Domain sind, kann man den von dort geladenen Daten vertrauen und braucht sie nicht jedesmal neu zu validieren. Einmal vom Browser in die Anwendung submittete Daten müssen also nur einmal validiert werden und können danach vom Anwender nicht mehr manipuliert werden. exp und uid aus dem Beispiel oben sind dem Zugriff des Anwender also entzogen, ja, sie gelangen noch nicht ein einziges Mal in den Zugriffsbereich des Anwenders. Auf diese Weise werden jede Menge Sicherheitsprobleme konstruktionsbedingt vermieden. Kristian -- Kristian Köhntopp, NetUSE Kommunikationstechnologie GmbH Siemenswall, D-24107 Kiel, Germany, +49 431 386 436 00 Using PHP3? See our web development library at http://phplib.shonline.de/ (GPL)
php::bar PHP Wiki - Listenarchive