Murphy`s Importanst LAWS
Jede Lösung bringt nur neue Probleme
Das Fluchen ist die einzige Sprache, die jeder Programmierer beherrscht.
In jedem kleinen Problem steckt ein großes, das gern raus moechte.
da ansonsten jemand eine der folgenden Seite bookmarken könnte und indem Fall wäre die ganze Autorisierung sinnlos!
Daran verhindert aber die Verschlüsselung der GET parameter nicht.
Vorrausgesetzt du identifizierst den Benutzer anhand von "nick" und "pass" die du per GET übergibst, dann braucht man nur den Link im Browsercache nachzuschauen und schon ist man drin in deinem System, obwohl sich der Benutzer schon ausgeloggt hat.
Ich würde ein Sessionsystem empfehlen, das ist in jedem Fall sicherer.
Also ich würde dir empfehlen, das ganze mal ganz ganz gründlich zu überdenken. Dein Konzept scheint jedenfalls nicht sehr gut durchdacht zu sein.
Ich würde sagen, les' dir mal den owasp Guide (OWASP Guide to Building Secure Web Applications and Web Services) durch.
Zuletzt geändert von Troublegum; 17.12.2002, 20:28.
Murphy`s Importanst LAWS
Jede Lösung bringt nur neue Probleme
Das Fluchen ist die einzige Sprache, die jeder Programmierer beherrscht.
In jedem kleinen Problem steckt ein großes, das gern raus moechte.
wie richte ich in meiner Testumgebung Sessions ein, hab gerade so ein Tool runtergeladen weil ich mir das mit den Session anschauen wollte, aber die Installation funzt nicht da Sessions fehlen,
Murphy`s Importanst LAWS
Jede Lösung bringt nur neue Probleme
Das Fluchen ist die einzige Sprache, die jeder Programmierer beherrscht.
In jedem kleinen Problem steckt ein großes, das gern raus moechte.
Sessions sind sowohl ohne Cookies als auch mit Cookies möglich. Damit kann der User sie auch nicht blockieren.
Sessiondaten werden serverseitig gespeichert, deshalb sind dort die Daten sicher - sie werden nicht übers Web versand. Das einzige, was der User braucht ist die Session ID. Die wird entweder in einem Cookie gespeichert oder per URL weitergegeben. (seite.php?session_id=$session_id). Die Cookievariante ist wenn möglich vorzuziehen, weil es doch etwas mehr Aufwand ist, den Cookie auszuspionieren, als die Session ID im Verlauf des Browsers nachzugucken. Das Dilemma entschärfst Du aber, weil Sessions nur eine begrenzte Lebensdauer haben und nach einer Stunde (oder 20 Minuten, wie du willst) wieder vom Server gelöscht werden. Wenn du unbedingt möchtest, kannst Du noch die IP Adresse an die Session binden (sprich: Integrität der IP innerhalb der Session prüfen).
Sessions sind an sich ne schöne Sache. Gut, die Sessionfunktionen von PHP sind "erst" ab PHP4 integriert, aber wer hat denn noch PHP3. Soviel zur Verfügbarkeit. Und wenn nicht, kannst Du dir deinen eigenen Sessionsystem schreiben, was auch nicht so viel Arbeit ist (wir helfen Dir schon ;D).
Das ganze erfordert natürlich auch ein wenig Einarbeitungszeit, ganz klar.
Aber an der Verfügbarkeit von Sessions soll es nicht scheitern - da ist die mcrypt library ein viel größeres Problem.
Aber gerade wenn Du einen Mitgliederbereich oder sonstwas (alles was mit Benutzerauthentifikation oder Login zu tun hat) planst, sind Sessions doch schon recht nützlich und auch weitverbreitet.
Schau mal unter http://owasp.org/guide/ im Kapitel Benutzerauthentifikation/Sessions, etc. etc. Ist ganz interessant, wenn auch in englisch.
Oder schlag mal in einem Buch über PHP Sessions nach.
Kommentar