phpbar.de logo

Mailinglisten-Archive

[php] Tempo

[php] Tempo

Werner Stuerenburg ws_(at)_art-quarter.com
Mon, 30 Aug 1999 14:49:09 +0200


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