Moin!
wieso verwendest du keine cookies ??
session-handling sollte höchstens als fallback eingesetzt werden. aber auch nicht unbedingt notwendig. wenn cookies deaktiviert gibts halt nix.
Also, ich weiß nicht. Diese Aussage zeugt irgendwie von gefährlichem Halbwissen in Bezug auf PHPs Sessionmanagement.
PHP verwendet selbstverständlich automatisch Cookies für die Herstellung einer Browsersession, also ist die Frage "Wieso verwendest du keine Cookies" schon mal gegenstandslos - weil genau das in der Regel passiert.
Zweiter Einwand: "Session-Handling sollte höchstens als Fallback eingesetzt werden" soll was genau bedeuten? In PHP kriegt man Sessions ganz einfach hin, indem man die verfügbaren eingebauten Session-Funktionen benutzt - und natürlich sollte man darüber informiert sein, was sie im Detail bewirken. Den Einsatz dieser Session-Funktionen verstehe ich als "Session-Handling" - und das sollte eben gerade NICHT als Fallback eingesetzt werden.
und manipulationen an der url erkennst du, indem du deine parameter auf gültigkeit überprüfst bevor du irgendwas weiteres damit anstellst. wichtig dabei auch das escapen von werten für die datenbank.
Naja, ein Absatz mit vielen Allgemeinplätzen.
Man verhindert das "Herumspielen" eines eingeloggten Users im Allgemeinen dadurch, dass man prüft, ob dieser User für die angeforderten Daten überhaupt eine Zugriffsberechtigung hat. Denn bei allem, was der User grundsätzlich sehen darf, ist es ja vermutlich egal, auf welchem Weg er diese Information abruft. Wenn es mindestens einen gültigen Weg dorthin gibt, wird er im Zweifel genau diesen Weg gehen - warum also soll man ihm dann Abkürzungen verbieten.
Wenn er hingegen Informationen abrufen will, die nicht für ihn freigegeben sind, dann muss dies im Moment des Informationsabrufs geprüft werden, und zwar idealerweise "live" auf Basis der zu diesem Zeitpunkt relevanten Accountzustände. Nicht, dass der Admin den Useraccount zwar schon lange geschlossen hat, dieser User aber immer noch mit seiner vor Tagen eröffneten und am Leben erhaltenen Session beliebig weitermacht.
Die Sicherheit erhält man also nicht dadurch, dass man z.B. bei der Auflistung von Datensätzen einfach die IDs rausfiltert, die der User nicht sehen soll, dann aber beim Detailaufruf darauf vertraut, dass der User halt nur die Links anklickt, die er sehen kann, sondern es ist zwingend notwendig, auch dort nochmal zu prüfen, ob der User auf die übermittelte ID zugreifen darf, oder nicht.
Ein Wort zum Escaping: Das ist IMMER wichtig. Natürlich auch, wenn man Daten in SQL-Statements einfügt, aber eigentlich noch viel wichtiger ist es, wenn man Daten in HTML einfügt. Weil das Gefährdungspotential höher ist - denn die Zerstörung der Datenbank ist zwar schlimm, beeinträchtigt jedoch nur den eigenen Server, das Einschleusen von Schadcode in Webseiten beeinträchtigt jedoch sämtliche zugreifenden User.
Dass es insgesamt natürlich keine Sicherheit geben kann, wenn es eine einzige Lücke gibt, sollte sich von selbst verstehen.
- Sven Rautenberg
"Love your nation - respect the others."