Sicherheit bei URL-Übergabe

[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

[imported_Ben]

Re: Sicherheit bei URL-Übergabe

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

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

[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

[imported_Ben]

benutze sessions ist easy und sicher

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

[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.

benutze sessions ist easy und sicher

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

Re: Sicherheit bei URL-Übergabe

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

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

Sessions:

- 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.

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.

Nur dass Cookies mehr als nervig sind und viele User diese ablehnen.

a. was ist "nervig" an Cookies?
b. klar, es gibt genug DAUs

Da ist es einfacher die Session an eine IP zu binden,

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

Proxy User haben in dem fall zwar Pech,

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

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!)

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

Fazit: Am besten beides implementieren, zuerst über Cookies versuchen, wenn Cookies verweigert werden,

... 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.

dann auf GET + IP umsteigen... imho die sinnvollste Variante für "normale" Webseiten.

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...

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.ä.

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

Cookies sind genau so unnötig wie Javascript.

Falsch.

Darauf zu beharren ist so wie "ich code nur für den IE"...

Davon wollen wir mal im Profi Forum nicht ausgehen.

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!

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.

Normalerweise sind dynamische IPs auch völlig ausreichend für eine Erkennung des Clients.

Falsch, wenn es sich dabei um Userauthentifizierung handelt.

Proxies benutzen eh nur wenig User.

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?

Cookies sind genau so unnötig wie Javascript.

Falsch.

Nein, nicht falsch, sondern vom User abhängig, i.d.R. aber überflüssig.
Cookies sind genauso wenig sicher wie über GET übergebene Sessions. Wenn jemand den Verkehr abhören kann (denn genau darum geht's ja), dann kann man auch das Cookie replizieren.

Darauf zu beharren ist so wie "ich code nur für den IE"...

Davon wollen wir mal im Profi Forum nicht ausgehen.

Das hoffe ich zumindest!

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!

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.

absolut falsch. In Clientzertifikaten gibt es eine nicht fälschbare, eindeutige ID, diese ist EINEM (!!) User zugewiesen. Aber Client Zertifikate sind für die meisten eh unerschwinglich.

Normalerweise sind dynamische IPs auch völlig ausreichend für eine Erkennung des Clients.

Falsch, wenn es sich dabei um Userauthentifizierung handelt.

Blödsinn. Warum sollten dynamische IPs weniger sicher als statische sein? 1. kann man IPs fälschen und umleiten, 2. wenn die dynamische IP gewechselt wird (z.b. wegen auto trennung), dann passt die Session nicht mehr zu der ip, ergo muss ne neue Session (mit evtl. login) erzeugt werden!

Proxies benutzen eh nur wenig User.

Fast jedes lokale Netzwerk benutzt NAT -

NAT != Proxy!
Wenn du's sicher haben willst, dann vergleich doch die clientports und schätze ab, ob der User den selben Rechner benutzt oder nicht... zusätzlich könnteste ja die IP Sequenznummern überprüfen... aber dann ist es echt einfacher SSL zu benutzen.

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?

Wenn ein normaler User neben einem anderen Sitzt, dann wird der Nachbar bestimmt eben rübergucken und die Session abschreiben, damit er zugriff auf dessen Daten hat! Ganz bestimmt, passiert mir auch immer!
Da ist es noch einfacher sich über vermutlich vorhandene Freigabe und wenger sichere Passwörter das Cookie vom Nachbarrechner zu holen....

Es gibt wirklich keinen Grund zu sagen "Cookies sind toll und GET Variablen sind sch***". Beides ist gleich unsicher. (wenn man mal nicht vom superdau absieht...) Cookies haben den Nachteil, dass sie IMMER einen negativen Beigeschmack haben. Ich hab weder Lust noch Zeit mir immer die Cookies anzuschauen die gespeichert werden... daher verbiete ich sie.

Cookies und JavaScript

Nein, nicht falsch, sondern vom User abhängig, i.d.R. aber überflüssig.

Und genau das ist immer noch falsch.

Cookies sind genauso wenig sicher wie über GET übergebene Sessions. Wenn jemand den Verkehr abhören kann (denn genau darum geht's ja), dann kann man auch das Cookie replizieren.

Na klar kann man das. Aber vom "Mann in der Mitte" war erst mal nicht die Rede sondern es geht immer noch um die Wiedererkennung des Clients. Und damit der Server die Session wieder aufnehmen kann, benötigt er die session_id. Warum PHP dazu nicht die IP benutzt, willst Du ja nicht wahrhaben.

Deine Keksallergie erinnert mich etwas an (wo isser eigentlich?) SteveBird.

SSL

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.

absolut falsch.

Lern lesen!

In Clientzertifikaten gibt es eine nicht fälschbare, eindeutige ID, diese ist EINEM (!!) User zugewiesen. Aber Client Zertifikate sind für die meisten eh unerschwinglich.

a. wie kann PHP darauf zugreifen?
b. wie findet PHP dann die dazugehörige Session?

Normalerweise sind dynamische IPs auch völlig ausreichend für eine Erkennung des Clients.

Falsch, wenn es sich dabei um Userauthentifizierung handelt.

Blödsinn. Warum sollten dynamische IPs weniger sicher als statische sein? [/quote]Weil die IP nicht an den User sondern nur an einen DSL/ISDN/Modem Port gebunden ist. Und genau deshalb ist es unsicher, sichg darauf zu verlassen, die IP wäre ein eindeutiges Erkennungsmerkmal.

2. wenn die dynamische IP gewechselt wird (z.b. wegen auto trennung), dann passt die Session nicht mehr zu der ip, ergo muss ne neue Session (mit evtl. login) erzeugt werden!

Ja eben.

Proxies benutzen eh nur wenig User.

Fast jedes lokale Netzwerk benutzt NAT -

NAT != Proxy![/quote]
In dem Falle unwichtig. Es geht schlicht und einfach darum, daß es nicht nur dynamische IPs gibt sondern auch lokale Netzwerke, die unter einer gemeinsamen öffentlichen IP ins Netz gehen.

Es gibt wirklich keinen Grund zu sagen "Cookies sind toll und GET Variablen sind sch***".

Eine Session_id als GET Variable dranzupappen, ist generell Mist.

Beides ist gleich unsicher. (wenn man mal nicht vom superdau absieht...)

Beides ist dann unsicher, wenn Du dabei den Mann in der Mitte meinst. Ansonsten ist die Übermittlung der Session_id per Prozeß-Cookie um Längen besser als die ellenlangen Links, die mindestens in 2 Logfiles und in der Browser History auftauchen.

Cookies haben den Nachteil, dass sie IMMER einen negativen Beigeschmack haben.

Den Beigeschmack haben Cookies nur deshalb, weil damals inkompetente DAUs diesen HOAX in die Welt gesetzt hatten.

Ich hab weder Lust noch Zeit mir immer die Cookies anzuschauen die gespeichert werden... daher verbiete ich sie.

Dein Ding. <ggg>

Wenn jemand den Verkehr abhören kann (denn genau darum geht's ja), dann kann man auch das Cookie replizieren.

Meiner Meinung geht es nicht darum. Wenn man den Netzwerkverkehr zum Beispiel durch einen Man-in-the-middle-Angiff belauscht, kann man sowohl Session Id per Cookies, als auch per GET Variablen, als auch SSL-Verbindungen abhören.

Das Problem ist eher folgendes: Man kann seine Sessionid selber aus Versehen preisgeben, z.B. weil man den Link kopiert und in einem Forum postet. Oder man klickt auf einen Link, der direkt (ohne Dereferer) auf eine Drittanbieterseite führt. Dann kann der Betreiber dieser Seite nämlich über die Environment-Variable "HTTP_REFERER" die SessionId erlangen.

An die Session Id in einem Cookie kommt man dagegen nur, wenn man auf den Rechner des Benutzers Zugriff hat oder den Netzwerkverkehr belauscht. Aber kein DAU auf der Welt kann seine SessionId aus einem Cookie selbst preisgeben. Und allein deshalb sind Cookies schon sicherer als GET-Variablen...

KMAssS

Das Problem ist eher folgendes: Man kann seine Sessionid selber aus Versehen preisgeben, z.B. weil man den Link kopiert und in einem Forum postet. [ ... ] An die Session Id in einem Cookie kommt man dagegen nur, wenn man auf den Rechner des Benutzers Zugriff hat oder den Netzwerkverkehr belauscht. Aber kein DAU auf der Welt kann seine SessionId aus einem Cookie selbst preisgeben. Und allein deshalb sind Cookies schon sicherer als GET-Variablen...

Mal sehen, ob er wenigstens Dir glaubt...

Ich dachte hier geht es um Profis...
also 1. sollte die Sessionid recht schnell veraltet sein, von daher ist ein posten in einem Forum kein Problem!! (vielleicht sind eure Sessions ja ewig gültig, aber meint ihr, dass dann das hier das richtige Forum ist?)
2. wenn du von SSL und den dazu passenden PHP Schnittstellen keine Ahnung hast, dann lern du erst mal, dich vorher damit zu beschäftigen, bevor du dein Unwissen preisgibst. (Btw. z.b.: $SSL_CLIENT_M_SERIAL für die Client ID...)
3. wenn mein Nachbar in meinem LAN auf eine "Sessionseite" surft bekommt er eine Sesseion. Wenn ich das gleichzeitig mache bekomme ich eine ANDERE!!!!!!!!! Session. Das heißt aber, dass der Webserver anhand der Kombination (!!!!) von IP und Session den User erkennt.
4. Wenn man nicht vom mitm spricht, woher zum Geier soll denn jemand während der Gültigkeit der Session die ID bekommen? Es sei denn man verschickt die spontan über nen IM... und wenn man das in nem LAN macht, das hinter nem NAT GW liegt, dann kann man ja wohl grade noch von nem User erwarten können, dass er die Sessionid wegläßt....
5. seit wann ist es ein problem, wenn man ne lange URLs in der Adresse hat? PHP stört das in der Regel wenig!
6. zu kmasss: nein, eine SSL Verbindung kann bei vernünftigen, zertifizierten Zertifikaten nicht abgehört werden, es sei denn, dass Fehler in der Implementierung vorhanden sind, aber davon gehe ich spontan grade nicht aus, auch wenn es wahrscheinlich ist
7. Ich hab ja nie gesagt, dass die IP ALLEINE(!!) als Erkennung ausreicht, sondern immer, dass IP + Session ID... aber das scheint hier ja keiner zu verstehen.

Letztlich ist mir egal was ihr macht, nur sollte man sich nicht wundern, dass es User gibt, die keine Cookies erlauben. Und das sollte man bei seinem Konzept bedenken. Wie gesagt, woher soll ich, ohne extra (!!) nachzuschauen wissen, was der Seitenbetreiber in sein Cookie packt...
Wenn man eine Seite betreibt, für deren Login es unumgänglich ist Cookies zu akzeptieren, dann ok, aber solange man sich nur normal auf einer Seite bewegt haben cookies da nichts zu suchen!