nicht angemeldet
-> Apache::Session::MySQL -> Variablen sicher übergeben
Frohe Ostern!
Vorhanden:
Mein Script mit mehreren Bedingungen.
In der Endbedingung werden die übermittelten Daten
in die MySQL-Datenbank geschrieben.
Und zwar genau dort in die DB geschrieben,
... WHERE ID=$ID
$ID wurde bisher im Url von der ersten Bedingung (Einloggen)
bis zum schluss (wo die DB geschrieben wird) mitgeschleppt.
Das schaute in der Endbedingung so aus:
$ID = $cgi->param("id");
gut, jetzt geht aber der bösartige, eingeloggte User her,
und bastelt mal aus id=123 ein bisschen herum im URL
und macht id=999 daraus.
Dann editiert das Script in der Endbedingung
den total falschen User in der DB !!
Ich dachte auch schon daran,
die Daten simple per POST und nicht per GET zu übermitteln,
aber das ist mir nicht die sicherste Variante.
Ab hier wieder aufpassen *g*
##################################
Gut,
also dachte ich daran,
das ganze gleich in der allerersten Bedingung,
also der Login-Bedingung so einzubauen,
dass der die "id" die sich beim login ergibt in der SESSION
abzuspeichern,
und zum Schluss wieder aus der Session auszulesen,
um mit der ID dann die DB zu schreiben.
Das Modul für die Sessions ist:
Apache::Session::MySQL
In der ersten Routine (beim Login) müsste ich dann halt machen:
$session={'id'} = $id_von_DB
somit wäre die ID in der Session....
Die ID bekommt das Script an dieser Stelle
dank der username/passwort Kombination aus der DB.
Einziges Problem:
Einen normalen $cgi->param("foo") kann man ja im Browser ändern.
Kann der im prinzip dieses oben genannte
$session{'id'} auch im Browser verändern?
Die Eigentliche Frage:
Also im Prinzip ist ja die ID die
das Script zum Schluss zum schreiben der DB hernimmt
in seiner Session-ID dann drin,
aber angenommen der User hängt dann am URL an:
?session{'id'}=999
^^ der syntax ist sicher falsch für den Browser,
aber nur mal als Beispiel,
könnte er damit
$session{'id'} verändern????
Danke!
LG
Aquariophile
PS.: Wie soll ich das nun machen bitte?
-
Hi,
ganz einfach... wieso verwendest du nicht ganz einfach eine SessionID anstatt der echten ID... das ist a) sicherer, b) sinnvoller und c) effektiver... und das beste ist, fuer den User ist es nicht ersichtlich was diese ID die er sieht bedeutet.
Kleine Anleitung dazu:
du kreierst nach dem Login des Users eine ca. 18-20 stellige Nummer, am besten ueber zwei randomizer (so mach ich das)... so, die packst du jetzt, zusammen mit der echten ID und eventuellen weiteren Daten, in deine DB... die SessionID haengst du jetzt einfach an jede URL intern mit dran und fertig. Der User ist immer eindeutig identifiziert und kann mit der ID die er da hat garnichts anfangen... die Chance das er naemlich eine andere aktive ID erraet ist schon bei 10 Stellen sehr sehr gering... bei 18 eruebrigt sich dann jedes raten :))
Hoffe ich konnte dir weiterhelfen.
CU Quitschi
-
Hi,
gut, jetzt geht aber der bösartige, eingeloggte
User her, und bastelt mal aus id=123 ein bisschen
herum im URL und macht id=999 daraus.Das darf er eben nicht können.
In $ID muß wesentlich mehr drin stehen als nur die tatsächliche Session-ID - beispielsweise Informationen aus dem ursprünglichen Login-Vorgang (die Benutzerkennung) und ein zufälliges Element.
Und das alles zusammen versehen mit einer Prüfsumme, welche dafür sorgt, daß ein zufälliges Bitmuster nur mit exorbitant geringer Wahrscheinlichkeit überhaupt zu einer syntaktisch korrekten Angabe führen kann.Zerlegen muß Du das Zeug natürlich selbst, und prüfen ebenfalls. Aber nach der Zerlegung liefert Dir die Prüfsumme schon mal einen sehr zuverlässigen Ansatzpunkt, ob das überhaupt alles sein kann. Nur im Falle einer gültigen Prüfsumme mußt Du die Inhalte auch noch semantisch validieren, um damit zu prüfen, daß dieser Anwender die Session-ID auch zu Recht verwendet.
Auf diese Weise ist die Verarbeitung eines Angreifers, der versucht, IDs auszuwürfeln, zudem wesentlich performanter möglich, als wenn Du jedesmal einen Datenbankzugriff etc. brauchst, um die fehlerhaften Angaben zu erkennen.
Viele Grüße
Michael