PHPSESSID über URL ist ein sch**** Sicherheitsproblem!

Hinter einem Router z.B. haben (nach außen hin) alle Rechner die dahinterhängen die selbe ip. Also könnten die sich untereinander fröhlich die Sessions stehlen...

[Waq]

http://www.dclp-faq.de/q/q-sessions-ip.html

Ich versteh irgendwie das Problem nicht. Man macht ja nicht aus oder mit der IP die SESSID, sondern fragt nur zusätzlich die IP ab.

Du hast aber schon versucht, dass, was hinter dem Link steht, auch zu verstehen? Oder zumindest einmal zu lesen?

Somit ist das Problem mit dem weitergeben von Links keins mehr, weil ja nicht gleichzeitig 2 Benutzer am PC arbeiten können (?).

Erstens können an einem Rechner, wie HINTER DEM LINK STEHT, locker 110 Leute arbeiten. In der 1PC-1Monitor-1Tastatur-1User-Windows-Welt ist das unüblich, aber in etwas exotischeren Bereichen kommt das aber schonmal vor. Und ja natürlich geht es um 110 User gleichzeitig.

Mal ganz abgesehen davon, dass eine öffentliche IP zwar eindeutig sein muss, aber keinesfalls den Rechner repräsentieren muss, an dem der Nutzer sitzt, sondern gerne auch mal einen Proxy oder Router, hinter dem sich entsprechend viele Nutzer verstecken können.

Sollte die IP tatsächlich während einer Sitzung wecheseln, muss sich der Benutzer neu einloggen, was ja kein Problem darstellen sollte (es sei denn die IP wecheselt alle 2min ).

Die Abstände können unter 2 Minuten liegen... da müsste man mal mit nem AOL-User testen, ob da nicht sogar bei jeder einzelnen Anfrage ne neue IP verwendet wird. Genau weiß ich es um ehrlich zu sein nicht.

http://www.dclp-faq.de/q/q-sessions-ip.html

Ich versteh irgendwie das Problem nicht. Man macht ja nicht aus oder mit der IP die SESSID, sondern fragt nur zusätzlich die IP ab.

Du hast aber schon versucht, dass, was hinter dem Link steht, auch zu verstehen? Oder zumindest einmal zu lesen?

Du hast aber schon versucht, dass, was in meinem Beitrag steht, auch zu verstehen? Oder zumindest einmal zu lesen?
Sind solche Aussagen wirklich notwendig?

Somit ist das Problem mit dem weitergeben von Links keins mehr, weil ja nicht gleichzeitig 2 Benutzer am PC arbeiten können (?).

Erstens können an einem Rechner, wie HINTER DEM LINK STEHT, locker 110 Leute arbeiten. In der 1PC-1Monitor-1Tastatur-1User-Windows-Welt ist das unüblich, aber in etwas exotischeren Bereichen kommt das aber schonmal vor. Und ja natürlich geht es um 110 User gleichzeitig.

Ich muss zugeben, dass ich hier nicht sattelfest bin, deshalb auch das Fragezeichen. Aber bei der Methode zusätzlich die IP zu überprüfen, müssten dann mehrere Benutzer am gleichen Rechner mit dem gleichen Browserfenster arbeiten, um nicht eindeutig identifizeriert werden zu können.

Mal ganz abgesehen davon, dass eine öffentliche IP zwar eindeutig sein muss, aber keinesfalls den Rechner repräsentieren muss, an dem der Nutzer sitzt, sondern gerne auch mal einen Proxy oder Router, hinter dem sich entsprechend viele Nutzer verstecken können.

Ändert aber nichts daran, dass zumindest zusätzliche Sicherheit gegeben ist.
Für die Benutzer hinter dem Proxy oder am selben Computer hat diese Technik natürlich keinen Nutzen, aber mir würde nichts einfallen, um die eineutig identifizieren zu können (mit SSL vielleicht).

Sollte die IP tatsächlich während einer Sitzung wecheseln, muss sich der Benutzer neu einloggen, was ja kein Problem darstellen sollte (es sei denn die IP wecheselt alle 2min ).

Die Abstände können unter 2 Minuten liegen... da müsste man mal mit nem AOL-User testen, ob da nicht sogar bei jeder einzelnen Anfrage ne neue IP verwendet wird. Genau weiß ich es um ehrlich zu sein nicht.

Da muss ich dir absolut recht geben, wenn das wirklich der Fall ist, ist die Lösung mit der IP (ohne zusätzliche Techniken) nicht brauchbar.

Was ich sagen will:
Ich sehe keine Nachteile darin, die IP zusätzlich zur SESSID abzufragen, es bietet immerhin mehr sicherheit, wenn nicht mehrere Benutzer am selben Rechner/hinter dem selben Proxy arbeiten.
Einzig und allein einen Nachteil gibt es: Sollte die IP oft wechseln, kann man dem Benutzer nicht zumuten, sich jedes Mal neu einloggen zu müssen.

Du hast recht, es ist ein kleines bißchen sicherer aber natürlich längst nicht ausreichend. Solange man jedoch nicht mit hochsensiblen Daten wie Bankverbindungsdaten etc. hantiert, empfinde ich diesen Schutz als ausreichend. Wirklich hinnehmbare Sicherheit bietet eben wie schon erwähnt nur SSL.

Ich muss zugeben, dass ich hier nicht sattelfest bin, deshalb auch das Fragezeichen

Hier gibt es genaue Info

http://www.dclp-faq.de/q/q-sessions-methode.html
http://www.dclp-faq.de/q/q-sessions-ip.html

Hier ein Beispiel, falls Cookies verweigert

Am besten mit Firefox~Mozilla ansehen, vorher Cookies sperren - bzw. nur nach Anfrage -- Einstellen

http://www.novo-terra.de/angebote.php

Ich muss zugeben, dass ich hier nicht sattelfest bin, deshalb auch das Fragezeichen

Hier gibt es genaue Info

http://www.dclp-faq.de/q/q-sessions-methode.html
http://www.dclp-faq.de/q/q-sessions-ip.html

Ich meinte nicht sattelfest im Bezug auf Multiuser-Systeme

Es geht mir hier nicht darum, ob man die SESSID im Cookie speichern sollte oder nicht, sondern darum, einen Weg zu finden, Daten möglichst gut abzusichern (ohne SSL oä.) wenn dies nicht möglich ist.
Ich glaub wir sind uns da eh alle einig. Ich meinte nur, dass ich nur einen Nachteil erkennen kann, wenn man die SESSID an eine IP bindet, nämlich wenn sich die IP häufig ändert (abgesehen vom kleinen Mehraufwand ) und deshalb die oft gemachte Aussage
"SESSID & IP ist nicht sinnvoll oder gar böse"
nicht verstehe

Hier ein Beispiel, falls Cookies verweigert

Am besten mit Firefox~Mozilla ansehen, vorher Cookies sperren - bzw. nur nach Anfrage -- Einstellen

http://www.novo-terra.de/angebote.php

Ist das jetzt ein gutes oder ein schlechtes Beispiel Ich verstehe nicht ganz, was du damit sagen willst

Ich meinte nicht sattelfest im Bezug auf Multiuser-Systeme

Da Problem hast Du schon bei AOL und T-Online Nutzern.

SESSID & IP ist nicht sinnvoll oder gar böse

Wozu das Rad neu erfinden, hierbei geht es doch nur darum einen 'DAU' zu verhindern - z.B. BOOKMARKS oder eine leicht manipulierte Eingabe wie [http://domain.de/index.php?PHPSESSID=0815].

Einfach auf Cookies beschränken, Fehlerhinweis einbauen - FERTISCH

Alles andere ist kontraproduktiv, oder hast Du schon mal einen Session-Cookie manipuliert, außer der Sessionid sollte da sowieso nichts stehen. Und wer den COOKIE manipuliert, der hat auch andere Energie Dich zu ärgern.

Das mit der IP - einfach vergessen

Alles weitere an Sicherheit geht nur über SSL

Session-Cookie ist die 'DAU'-bremse - SSL ist die Sicherheit

Ist das jetzt ein gutes oder ein schlechtes Beispiel

Dieses Beispiel zeigt lediglich eine Fehlermeldung falls das Session-Cookie verweigert wird, und erklärt warum ein weitere Service nicht möglich ist.

Die User, die Cookies zulassen merken nichts davon, die Cookies ablehnen bekommen eine Notice, beurteilen mußt Du nun selbst.

Gerade eben, beim Schreiben meines Beitrags, hab ich endlich kapiert was du eigentlich meinst (hoff ich zumindest ).

Sollte ein DAU hinter einem Proxy sitzen und seine SESSID an jemanden hinter dem gleichen Proxy weitergeben, kommt derjenige an sensible Daten.
Sicherheitslücke

Das Problem besteht bei cookies only nicht, eine Lücke weniger.
Und sollte die SESSID sowieso per cookie weitergegeben werden bringt ein IP-Logging auch kein Plus an Sicherheit.

Und sollte die SESSID sowieso per cookie weitergegeben werden bringt ein IP-Logging auch kein Plus an Sicherheit.

Ähm..~

Andersrum wird ein Schuh daraus, Du hast ein Shopsystem, die IP mitgelesen, es ist ein AOL-User, dieser bekommt pro Session permanent eine andere IP (das ist bei AOL so)

Fazit, der Warenkorb ist permanent gelöscht

Auf die IP-Adresse kannst Du Dich nicht verlassen.

Die Jungs von PHP haben sich ja schon was dabei gedacht eine SESSIONID einzuführen, ist übrigens bei ASP auch so.

Damit ist auch die Session geschlossen falls der Browser beendet wird !!!!

Also sind wir uns im Endeffekt eh einig

Versuch einer Lösung

Hallo Jungs,

ich bin neu in eurem Forum, hier meine Vorgehensweise.

Ich habe immer eine Einstiegsseite (index.php) diese generiert alle SESSION-Variable die ich benötige. Soweit glaube ich alles ein alter Hut.

Ich setze weiter eine bestimmte Variable z.B $ID über microtime()
diese übergebe ich wie die Session_id in der URL.

Jetzt kann ich bei gleicher Session mehrere Nutzer (Router-problem) unterscheiden, denn ich definiere alle Variablen je Nutzer folgendermaßen

<?
$ID = $_GET["ID"]
$_SESSION["Beispiel_$ID"]
?>

und habe somit eine spezielle Variable für jeden Nutzer. trotz scheinbar gleicher Variablenbezeichnung

Jetzt das Problem Sicherheit und Session-Klau

Dies versuche ich zu verhindern, indem ich zusätzlich bei jedem Seitenaufruf ein Variable definiere:

$SICO = microtime() oder Zufallsgenerator

Diese einmal in einer Sessionvariable speichere

$_SESSION["SICO_$ID"] = $SICO

und einmal an die URL anhänge ...&Sico=$SICO...

die aufgerufene Seite vergleicht jetzt beide Variablen
die Getvariable und die Sessionvariable

if($_GET["SICO"] != $_SESSION["SICO_$ID"]) {

//-- Abweisen und springen auf Indexseite

} else {

//-- alles OK,

}

Jetzt muß natürlich die $SICO - neu initialisiert werden.
Damit ändert sich jedesmal diese Seite. Sollte jetzt einer Versuchen die Seite gleichzeitig zu öffnen, so kommt es zu einer Differenz und beide fliegen Raus.

Wenn man jetzt noch eine Seite einbaut, welche ein Logout generiert kann man alle Session-variablen mit $ID löschen und somit die Nutzung der SESSION-ID für eventuell noch offene SESSIONs unterbinden. Hierbei ist man aber auf die Mithilfe der User angewiesen.

Der Vergleich der IP ist soweit OK
Dies kann alles in einer kleinen Log-datei geschehen.

Vielen Dank für das bißchen Aufmerksamkeit.

[supertramp]

Re: Versuch einer Lösung

hier meine Vorgehensweise

Das schützt auch nicht 100%ig!, denn ich kann dann immernoch die Adresse der zuletzt aufgerufene Seite mit allen GET-Variablen weitergeben.
Wenn ich das Browserfenster schließe und die Adresse weitergebe, dann habe ich die Lückge genutzt.

Denn dann stimmen GET und Session-Variable immernoch überein!

[Tutti]

In meinen Postnukezeiten habe ich dieses hier gelernt.

php_flag session.use_trans_sid off

in eine .htaccess schreiben.
Die SID erscheint so nicht mehr in der Adresszeile, wird aber trotzdem mit weitergeführt. Somit hat man mindest erstmal unterbunden, dass man URL's mit angehängter SID weitergibt.

Allerdings ist die Einstellung abhängig von der Serverkonfiguration.

[imported_Ben]

@tutti:
einfach mit
http://php.net/ini_set
konfigurieren.

wenn die SID nicht per URL weitergegeben wird, dann müssen kekse verwendet werden, wobei man dann wieder auf ein verfügbarkeitsproblem stößt.
ist also alles nicht so das wahre


@supertramp:
du hast aber ganz schön in der vergangenheit gekramt