nicht angemeldet
Session & URL
Hallo leute,
ich habe da eine ziemlich amateurhafte Frage:
Ich habe eine Homepage mit einem Mitgliederbereich. Die Leute können sich einloggen und bekommen vom System eine Session zugewiesen.
(Transparentes Sessionmanagement)
In den weiteren Seiten werden natürlich auch Parameter an andere Seiten übergeben & Co.
Ich möchte nun verhindern, dass jemand an der URL rumspielt bzw. über die URL irgendeinen Schadcode einbringt.
Die einzige Möglichkeit, die ich kenne, um eine Manupulation an der URL zu verhindern ist, dass ich überprüfe, ob die Session noch vorhanden ist. Wenn ja, dann wurde Seite korrekt aufgerufen. Ist sie nicht mehr vorhanden, dann wurde höchstwahrshceinlich an der URL rumgespielt und ich logge den User aus.
Problem: Wenn der User den Vor- oder Zurück-Button des Browsers benutzt, ist die SID auch weg und ich logge den User aus. --> doof!
Wie kann ich alternativ eine Manupulation an der URL erkennen?
Alternative Sicherheitsmechanismen?
Gruß, Hakan
-
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.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.
-
Leider hab ich angefangen die Sessions per transp. URL weiter zu geben. Momentan auch zu spät, dass zu ändern.
Eine Überprüfung der Parameterinhalte und Maskierung findet bereits statt. Aber ich wollte eben noch eine Stufe weiter und will jegliche Manipulation an der URL verhindern.
Also wenn die URL heisst:
http://www.meinepage.com/content.php?id=23&name=Hakan
dann kann ein user immer noch direkt in der URL ändern
http://www.meinepage.com/content.php?id=99&name=Hakan
Die Prüfung auf Inhalte bringt nicht viel, da beide id´s gültig sind, nur der Inhalt, die der User erhält wäre nur mist bzw. wären falsche Inhalte. Und das will ich verhindern.
Für weitere Tipps bin ich total dankbar!
Gruß, Hakan
-
Hi,
Also wenn die URL heisst:
http://www.meinepage.com/content.php?id=23&name=Hakan
dann kann ein user immer noch direkt in der URL ändern
http://www.meinepage.com/content.php?id=99&name=Hakan
und wo ist da das Problem bzw. wie sollte eine Session dies verhindern?
Die Prüfung auf Inhalte bringt nicht viel, da beide id´s gültig sind, nur der Inhalt, die der User erhält wäre nur mist bzw. wären falsche Inhalte. Und das will ich verhindern.
Verhindern solltest Du lediglich, dass diese Abfrage "Mist" ergibt.
D.h. wenn es keine Seite mit der id=99 gibt, dann sollte eine Fehlerseite (mit Statuscode 404) ausgegeben werden. Und wenn es eine solche Seite gibt, dann ist es auch die, die der User angefordert hat, ob nun über enen Link oder manuell - in letzterem Fall weiß der User entweder, was hinter der ominösen 99 steckt oder er ist sich zumindest des Blindversuches bewusst.freundliche Grüße
Ingo
-
-
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."
-
-
Hi,
Ich möchte nun verhindern, dass jemand an der URL rumspielt bzw. über die URL irgendeinen Schadcode einbringt.
Dann nutze saemtliche uebergebene Werte nur innerhalb eines streng definierten Rahmens.
Die einzige Möglichkeit, die ich kenne, um eine Manupulation an der URL zu verhindern ist, dass ich überprüfe, ob die Session noch vorhanden ist. Wenn ja, dann wurde Seite korrekt aufgerufen. Ist sie nicht mehr vorhanden, dann wurde höchstwahrshceinlich an der URL rumgespielt und ich logge den User aus.
So lange ich die Session-ID uebergebe, erkennt der Server meinen Client wieder. Ueber alle anderen Parameter, die per URL uebergeben wurden, sagt dieser Umstand absolut Nichts aus.
Wie kann ich alternativ eine Manupulation an der URL erkennen?
Gar nicht.
Du kannst hoechstens Werte als ungueltig abweisen. Dazu musst du aber zuerst mal genau definieren, was gueltig ist.Alternative Sicherheitsmechanismen?
Du solltest erst mal die Gefahr definieren, bevor du dir Gedanken um ihre Abwehr machst.
MfG ChrisB
--
„This is the author's opinion, not necessarily that of Starbucks.“