[Nimroy]

Hi

ich sitz gerade an ner kleinen Anwendung mit ner MySQl dahinter. Dabei werden nach erfolghreichem login links in einer Liste die Projekte des Users angezeigt und auf der rechten Seite befindet sich ein menü, welche Aktionen man auf diesen Projekten durchführen kann. Einer Aktion muss ich also sagen, was zu tun ist und auf welchem Projekt. Wie bring ich beide Sachen möglichst sicher zusammen? Projekt-ID in ne Session-variable schreiben und beim Aktions-Aufruf auf diese Session-Var zugreifen? Dann würde ich nach dem Login einfach das erste projekt nehmen und das default setzen. Oder ist das alles totaler quatsch?

Ich versuche übrigens, das ganze möglichst nach dem FuseBox-Modell aufzubauen.

Würde mich freuen, wenn da jemand ne Idee hat. Gerne auch was ganz anderes...

[pixelpapst303]

willst du mit der session grundsätzlich vermeiden, dass beim klick auf eine aktion eine verifizierung mit db-abfrage stattfindet? das, denke ich mal, ist eine entscheidende geschichte für die vorgehensweise...

edit: und gleich nächste frage. gibt es also einen festen katalog an möglichen aktionen?

[Nimroy]

Ja, es gibt einen festen Katalog an Aktionen

ichhab nochmal drüber nachgedacht. ich muss ja verhindern, dass jemand mit böser absicht, sich über Manipulation eines Aufrufes ne fremde ID in die eigene Session schreibt und dann Aktionen darauf ausführt. ich dachte also, ich ruf mit der Aktion nur a la FuseBox ne Funktion auf, die an hand des übergebenen Namens und der ID des Users herausfindet, ob das überhaupt der Besitzer ist und wenn ja, die Projekt-ID in die session schreibt. Die Aktionen selbst suchen sich dann die Projekt-ID aus der Session und eigentlich brauch ich die dann nicht mehr überprüfen, weil ich ja schon das schreiben in die Session abgesichert hab. Oder überseh ich da gerade irgendeine Hacker-Schweinerei?

[bacon]

Irgendwann wirst du die info, welche projekt-(id) denn nun gewählt ist, auf jeden Fall zum Server senden müssen. D.h. alleine du brauchst das Aktionsattribut und die Projekt-Id (bspw. "index.php?action=projektDetail&pId=1"). Da spricht auch nix dagegen. Ab diesem Zeitpunkt kannst du das Projekt auch gerne in ner Session speichern, warum auch nicht. Dann kannst du CRUD-Operationen (action=delete/edit/retrieve) durchaus auch ohne die pId vornehmen.

Aber: Was passiert, wenn der User in mehreren Browsertabs arbeitet? Das kann dann schonmal zu unvorhergesehenen Ergebnissen führen.

Ne Faustregel ist bei solchen Sachen: Wenn du schon nicht auf eine verschlüsselte Leitung zurückgreifen musst, würde ich mich auf den Login konzentrieren. Ein guter Weg: Userdaten nicht im Klartext übertragen! (Also bspw. ein md5-Javascript saugen.) Zusätzlich noch das verschlüsselte Passwort beim Login mit ner Random-Challenge versehen, damit auch der Hash nicht im "Klartext" übertragen wird. Vorgehensweise. Challenge generieren, in Session ablegen. Beim Login clientseitig aus den Usereingaben bzw. nur ausm Passwort (sorry) + challenge nen hash generieren. Nach dem Absenden diesen Hash mit einem Hash aus PW + challenge aus der Datenbank vergleichen.

Zusätzlich: Niemals die SessionId mit übertragen, sondern ausschließlich mit cookies arbeiten.

[Nimroy]

[pixelpapst303]

naja, da die aktionen ja eh über ein neuladen der seite aufgerufen werden spräche kurz gesagt wirklich nichts über ein folgendes (sehr einfach gestricktes) modell:

bei projektaufruf die allows aus db holen und dann bspw so speichern.

$_SESSION['Projekt_id'] = array ("aktions_id1" => "true",
"aktion_id2" => "false",
etc etc etc);

bei jedem aktionsaufruf übergibst du dann nur noch projekt_id und aktions_id und prüfst diese, obs erlaubt ist.

wenn du ein sauberes session-handling hast, solltest bezüglich der sicherheit keine probleme haben.

[Nimroy]

[pixelpapst303]