[php] Tempo

[Werner Stuerenburg]

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)