pcschröda

Schade gibt es keinen Bereich "PHP Fortgeschrittene"...

Ok, folgendes Problem:

ich hab eine HP erstellt, bei der beim ersten Aufruf eine Startseite angezeigt werden soll. Realisiert habe ich das mit einem include() in der index.php. Kehrt man später von einer anderen Unterseite auf die index.php zurück, soll die Startseite natürlich nicht mehr angezeigt werden - funktioniert auch, allerdings eröffne ich dazu eine Session.
Da läuft natürlich nix, wenn Cookies nicht zugelassen werden. Mit einer URL-Übergabe wär's ja auch kein Problem, doch ich las in den FAQ's, dass man das auf jeden Fall vermeiden soll.

Meine Frage: Was bringt es mir, wenn ich die Session in der URL übergebe, falls keine Cookies gesetzt werden können? Das wär ja genauso unsicher. Und gerade mit SSL will ich ja nicht anfangen wegen so ner Lappalie. Was muss ich also berücksichtigen bezüglich der Sicherheit?

Danke für die Tipps,


mfg

Michael

Mister Ad

imported_Ben

das anfänger-forum ist für anfänger und fortgeschrittene ..
der name trügt etwas ..

du beschreibst da zwei sachen .. einmal, dass du etwas mit include() einbindest und einmal das du eine session eröffnest.

ich habe das sicherheitsproblem schon verstanden .. habe aber leider keine akzeptable antwort.
allerdings wollt ich nochmal nachfragen, ob du mit dem include() auch probleme hast..

grüße ben

__________________
Webentwickler-Blog - Buchbesprechung PHP Design Patterns - SQL-Antipatterns

Ohrwurm83

Hi
ich arbeite immer mit sessions
die sessions werden auf dem SERVER nicht auf dem heim pc gespeichert!
also sind sessions die sichere mehtode. es ginge nach meiner erfahrung auch nur sehr schwer sessions zu knacken... also für einen nicht admin! ^^

benutze sessions ist easy und sicher

__________________
Auch eine Faust war einmal eine offene Hand

imported_Ben

haste auch gelesen, gelle?
http://www.dclp-faq.de/q/q-sessions-methode.html

__________________
Webentwickler-Blog - Buchbesprechung PHP Design Patterns - SQL-Antipatterns

pcschröda

Hallo Ben,

nee, mit inlude() gibt's keine Probleme. Ist halt wirklich nur die Frage, was passieren kann, wenn jemand die in der URL übergebenen Werte manipuliert und mit welcher Methode (GET, Session) man da besser zu Werke gehen sollte. Ich nehm an, das Thema ist nicht ganz neu, für mich hingegen schon...

Zum FAQ-Text: die kryptische Zeichenfolge, die im Cookie gespeichert wird ist also quasi der Schlüssel zu den dazugehörigen Daten aufm Server? Ahhhhh, jetzt schnall ich.


Seh ich leider nicht so. Alles was Du brauchst, ist schließlich die Session-ID, um z.B. Zugang zu passwortgeschützen Bereichen zu erhalten.
Und wenn Du das Teil per URL übergist, haste evt. ein Problem.

Es geht bei mir ja gar nicht um hochsensible Daten. Aber ich will halt auch nicht, dass man die Site irgendwie manipulieren kann.



mfg

Michael

Den Bereich müßte man erst mal definieren. <g>

Sessions:

Sessions wurden für den Fall "erfunden", wenn der Webserver den Client wiedererkennen muß, um auf gespeicherte Zwischenergebnisse zugreifen zu können (Warenkorb, Authentifizierung, mehrseitige Formulare usw.). Der Client muß also bei jedem Request im Protokoll ein Merkmal/Schlüssel mitschicken.

Der Knackpunkt ist, wenn es hier die sicherheitsrelevante Aktionen geht. In diesem Falle muß man einiges beachten, wenn man einem potentiellen Angreifer keine Hintertür bauen will.

1. wenn möglich das ssl Protokoll verwenden:
Leider ist das sauteuer, wenn man auf ein "echtes" Zertifikat wert legt. Weiterhin benötigt man je Zertifikat (egal ob echt oder selbstgebaut) eine eigene IP.

2. keine Schlüssel per GET versenden:
einfach Cookies verwenden.

3. Sessiondaten löschen, wenn der Vorgang abgeschlossen ist:
$_SESSION = array(); # löscht alles.

Nur dass Cookies mehr als nervig sind und viele User diese ablehnen.
Da ist es einfacher die Session an eine IP zu binden, Proxy User haben in dem fall zwar Pech, aber nach meinen Erfahrungen sind das eh nicht so viele (wer hat schon AOL??? *G*) und damit hat man dann das Problem der Übergabe gelöst. Wenn es wirklich sicher sein soll, dann kommt man um SSL nicht vorbei. Und wenn es ganz sicher sein soll, dann müssen Client Zertifikate benutzt werden (SEHR großer Aufwand!)
Fazit: Am besten beides implementieren, zuerst über Cookies versuchen, wenn Cookies verweigert werden, dann auf GET + IP umsteigen... imho die sinnvollste Variante für "normale" Webseiten.

a. was ist "nervig" an Cookies?
b. klar, es gibt genug DAUs
29.15. Warum verwendet PHP nicht die IP-Nummer des Browsers als Schutz gegen eine Übernahme der Session?
http://www.dclp-faq.de/q/q-sessions-ip.html

Naja, bei meinem Zeuch haben User mit Keksallergie eben Pech. Ich will keine Session IDs im Link haben.

Auch dann muß der Server den Client wiedererkennen können.

... dann hat der User bei mir zumindest Pech. Jut, für einfaches Zeuch baue ich auch mal einen Fallback ein, aber ich denke definitiv nicht daran, diese dämliche Kekshysterie mitzumachen.

IP? So lange es keine "statischen IPs für jedermann" gibt, ist es ehrlich gesagt sinnfrei, sich darauf zu verlassen.

Cookies sind nervig und ich lasse sie i.d.r. bei mir nicht zu. Normale Webseiten benötigen keinerlei Infos über mich oder über meinen Besuch (außer den Infos die sie so oder so von mir bekommen), sprich normale Webseiten benötigen überhaupt keine Sessions. D.h. sie benötigen auch keine Cookies o.ä.
Cookies sind genau so unnötig wie Javascript. Darauf zu beharren ist so wie "ich code nur für den IE"...
Von SSL haste offensichtlich nicht so viel Ahnung, denn die Usererkennung funktioniert bei Clientzertifikaten auch ohne Sessions, denn genau dafür sind sie ja da!
Normalerweise sind dynamische IPs auch völlig ausreichend für eine Erkennung des Clients. Proxies benutzen eh nur wenig User. Und wenn die Sessions ach so wichtig sind, dann muß man eben mehrere Lösungen implementieren.
Und ich habe auch nicht gesagt, dass die Erkennung NUR über die IP geht, sondern über IP UND Session ID. Zudem kommt, dass Sessions normalerweise nicht ewig gelten sollen, sondern nur für den meist kurzen Besuch auf der Seite, und die Wahrscheinlichkeit, dass sich die IP in dem Zeitraum ändert ist ziemlich gering! (von Proxies mal abgesehen)
Btw. statische IPs für jedermann wird es nie geben. Wenn IPV6 mehr benutzt wird, gibt es überhaupt keine statischen IPs mehr...

Im Thema geht nicht um "normale" Webseiten sondern um Webseiten, bei denen der Server Zwischenergebnisse weiterverwerten soll.

Falsch.

Davon wollen wir mal im Profi Forum nicht ausgehen.

Nutzlos, weil in dem Zertifikat dann der Vermerk auf die jeweilige Session ID drin stehen müßte. Wir reden hier über PHP Applikationen, die Zwischenergebnisse in die Session packen, um beim nächsten Request nicht wieder das Fahrrad neu zu erfinden müssen.

Falsch, wenn es sich dabei um Userauthentifizierung handelt.

Fast jedes lokale Netzwerk benutzt NAT -

Findest Du es wirklich gut, wenn der Kollege am Nachbar PC auf Deine Kosten Waren bestellten könnte, weil der gesamte Laden nach außen unter einer einzigen IP auftritt?