[php] 1/2 OT Session und Google Cache

[Ringo Großer]

Hallo,

ich antworte gleich mal gesammelt auf eure bisherigen Emails zum Thema.

>> ich habe mit PHP einen geschützten Bereich gebaut, welcher
>
> Befindet sich dieser geschützte Bereich in einem Unterverzeichnis
> oder läuft das alles über die /index.php?

Prinzipiell beides. Die physikalischen Ordner dienen lediglich der
Einordnung von Skripten. Ansonsten läuft alles über eine framework.php.
Neben den öffentlichen Contents werden nach einem Login auch die
nutzerbezogenen Frames angezeigt. Und im Abbild im Google Cache
sind eben solche Teile auch enthalten.

> Was findest du, wenn du in google nach "site:<deineURL>" suchst?

Ich finde einige weitere Ergebnisse. Alles offizielle Inhalte, jeder
Eintrag mit einer anderen PHPSESSID.
Die betreffenden Einträge, welche auch nutzerrelevante Teile zeigen,
weise aber die gleiche Session-ID auf und betreffen daher bislang nur
diesen einen User.

> Wenn sich dein geschützter Bereich in einem Unterverzeichnis befindet,
> sollte eine entsprechende robots.txt (zumindest für Google)
> ausreichen, um eine Indizierung zu unterbinden.

Die einzelnen Ordner enthalten keine ausführbaren Skripte, also keine
Skripte, die eine direkte Ausgabe in den Browser machen würde. Es
läuft wie gesagt alles über ein Zentrales Framework-Skript.

> nein, nicht ok. :-) Wenn die Daten so sensibel sind, wie es scheint,
> dann darfst Du hier auf keinen Fall die Session-ID-Lösung als
> Alternative zur Session-Cookie-Lösung anbieten! Anwender, die den
> Cookie nicht annehmen wollen, müssen - wie jetzt gesehen - zu ihrem
> eigenen Schutz aus dem geschützten Bereich Deiner Website
> ausgeschlossen werden. Ggf. mußt Du auch zusätzlich über eine
> verschlüsselte Verbindung im geschützten Bereich nachdenken.

So wirklich sensibel sind diese Daten nicht. Es geht hier erstmal nur
um einen persönlichen Punktestand und keine Daten für eine Bank-
verbindung. Aber auch die persönliche Adresse ist dort vermerkt und
da sehe ich schon eher einen Konflikt mit dem Datenschutz, zu dem
ich gegenüber dem User verpflichtet bin.

> Naja, wenn der Spider erstmal die URL mit der Session-ID erwischt hat,
> dann ist es klar, daß er in dem gesamten geschützten Bereich indizieren
> kann. Die Session-ID ist ja der Zugangsschlüssel.

Soweit erscheint mir das auch völlig logisch. Ich möchte jedoch noch
an einer früheren Stelle ansetzen und zwar noch vor dem "wenn".
Über die Lösungen für oder gegen das eine oder andere Problem mach
ich mir dann nochmal Gedanken bzw sind die Lösungen von euch
bereits genannt worden oder mir schon bekannt.
Aber ich erstmal das konkrete Problem lokalisieren. Wie hätte ein
Spider in die Kenntnis einer laufenden Session gelangen können?

> Wahrscheinlich hat dein Benutzer einen Link, in dem seine Sessionid
> srtand unwissentlich in irgendeinem Forum geposted und schwups hat ein
> bot die gefunden und die session gab es zufällig noch.

Denkbar ist sicherlich, dass der User einen entsprechenden Link mit
enthaltener Session-ID veröffentlich hat, aber ich halte dies eher für
unwahrscheinlich, mangels relevanter Inhalte auf meiner Seite. Aber ok,
ich hab auch schon viel sinnfreie Bedienung von Webseiten erlebt...

Meine Sorge geht aber momentan in eine andere Richtung, vielleicht
bin ich da durch die Dokumentation, die ich letztens über Google und
deren Geschäftspraktiken gesehen hatte, zu sehr sensibilisiert.
Aber ich möchte herausfinden oder zumindest ausschließen, dass
URLs aus dem eigenen Browser heraus ohne aktives Zutun des Users
von Google erfasst werden, z.B. durch die Toolbar oder einen Desktop.

> Das Problem zusammengafasst ist:
> Unbefugte erlangen Zugriff zuer Sessionid. Dazu gibt es mehrere
> Möglichkeiten:
> 1. Am Bildschirm abtippen, wenn man neben der entsprechenden Person sitzt.

Ein Spider hat diese ID bestimmt nicht abgetippt, auf dem Webserver selbst
dürfte sie nicht zugänglich sein und dass eine andere Person am PC des
Users diese ID samt Link veröffentlicht... meiner Meinung nach 
unwahrscheinlich,
aber lässt sich nicht 100% ausschließen.

> 2. Mit ethereal oder vergleichbar, wenn man im gleichen Netzwerk sitzt.

Diese Software kenn ich zu wenig, aber der Bescheibung nach, könnte
dies eine Möglichkeit sein, URLs mitsamt Session-ID abzufangen.
Erklärt aber immernoch nicht, wie diese ID dann auf Google gelangt ist.

> 3. Durch Trojaner auf dem Computer der Zielperson

Und hier habe ich eben noch Sorge, dass man mittlerweile die Google
Toolbar oder den Google Desktop schon als eine solche Art einstufen
muss. Das wäre für mich die Version, die momentan am liebsten glauben
möchte, aber mit dem Glauben ist das ja bekanntlich so eine Sache.

> 4. Durch Unvorsichtigkeit des Benutzers (wenn der einen Link mit
> sessionid veröffentlicht).

Dafür seh ich eben keine Veranalassung. Meine Seite dient keiner
Kommunikation zwischen den Usern und die URL vor der Session-ID
im Google Cache verweist auf den Hilfetext auf meiner Seite. Es ist
eben nur schwer vorstellbar, warum ein User diesen Link veröffentlichen
sollte. Einen Bookmark in seinem Browser könnt ich noch nachvollziehen
oder vielleicht eine web-öffentliche Bookmark-Verwaltung wie delicio.us.

Mögliche Szenarien gibt es also zahlreich. Ich werde die einzelnen beim
User auch nochmal abfragen. Vielleicht klärt sich dadurch etwas auf.

> Ist die Session-ID in der URL, läuft der unbedarfte Anwender Gefahr,
> eine URL mit seiner Session-ID selbst an andere zu verraten, wenn er
> ihnen die URL als Link schickt. Ferner taucht die URL ist der
> Browserhistorie auf, was ein Problem werden kann, wenn mehrere Personen
> Zugriff auf diese Browserhistorie haben. Darüber hinaus erscheint die
> Session-ID auf anderen Servern in den Serverlogs, wenn man aus dem
> geschützten Bereich heraus auf einen Link klickt.
>
> Du mußt zugeben, daß diese Szenarien weitaus wahrscheinlicher sind, als

Full ACK. Ich werd mich zunächst auch an der Wahrscheinlichkeit orientieren.

Also insgesamt sehe ich für allein 3 der oben genannten 4 Probleme die
Lösung zunächst darin, die Session-ID in der URL wirklich zu unterbinden.
Zum eigenen Schutz des Users, wie Lutz schon gesagt hatte.
Ich werde beim User auch mal nachfragen, ob und warum er keine Cookies
benutzt, falls er das überhaupt selbst erklären kann, falls es überhaupt 
sein
eigener PC ist und er überhaupt weiß, was ein Cookie ist.
Solche User, welche Cookies ablehnen oder diese Entscheidung einer
entsprechenden installierten Software überlassen haben, werde ich dann
wohl "zu ihrer eigenen Sicherheit" aussperren oder zum Umdenken
anhalten müssen.

Und das Fallback-Feature von PHP muss ich dann in Sinne meiner aktuellen
Anwendung als Bug einstufen. Ok, nicht wirklich, weil es ist ja ein Schalter
in der php.ini und meine eigene Entscheidung, wie ich diesen Schalter lege.

regards, Ringo