[php] 1/2 OT Session und Google Cache

[Lutz Zetzsche]

Hallo Ringo,

Am Samstag, 02. Dezember 2006 23:37 schrieb Ringo Großer:
> Nun hat mich ein Nutzer angesprochen, der seinen Namen per
> Google gesucht hat und dort aus dem Google Cache meine Seite
> angezeigt bekommt, und zwar aus dem geschützen Bereich und
> samt Informationen dieses Nutzers.
> Da stehen im Google Cache quasi im Klartext Informationen über den
> User (z.B. sein Punktestand), die eigentlich nur der User selbst nach
> einem Login sehen können sollte.
>
> Ich suche nun nach irgendeiner Erklärung, wie das möglich ist.
>
> Das betreffende Suchergebnis zeigt einen Link zu meiner Seite
> inklusive des GET-Parameters PHPSESSID, das bedeutet, dass
> bei diesem Zugriff nicht mit Cookies gearbeitet wurde und PHP
> dadurch den Fallback ausgeführt hat und die Session-ID an alle
> URLs selbst anhängt. Bis dahin alles ok.

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.


> Wenn man jetzt diesen Link aufruft, dann landet man natürlich nicht
> im geschützten Bereich in der Session des Users, weil die Session
> bereits abgelaufen ist. Aber selbst wenn die Session noch aktiv wäre,
> kann ich mir nicht erklären wie ein Spider in diese hineingelangt
> wäre.
> Des Weiteren listet der Google Cache einen Link in Verbindung mit
> meiner Seite, welcher auf einen Logout der selben Session-ID dieses
> Users hinweist. Den Link zum Logout kann man aber nur sehen, wenn
> man überhaupt eingeloggt ist. Einloggen kann man sich nur per
> Formular und indizierenden Robots werden wohl keine Formulare
> absenden und sich erst recht nicht erfolgreich einloggen können, weil
> die Zugangsdaten nicht bekannt sind.

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.


> Der hat ja sicherlich nicht so ohne weiteres Zugriff auf die Session-
> daten im tmp-Ordner meines Servers. Außerdem ist das bisher ein
>Einzelfall mit diesem User.

Ess kann auch nur ein Glückfall sein, daß es ein Einzelfall ist. 
Überlege mal, wie wahrscheinlich es ist, daß der Spider Kenntnis von 
einer URL mit Session-ID bekommt und noch rechtzeitig vor Ablauf der 
Session die URL zum Indizieren besucht...


> Daher würde ich einen Robots oder sonstigen Automatismus auschließen
> und das Erscheines des betreffenden Links mitsamt den heiklen
> persönlichen Informationen im Google Cache eher in Zusammenhang mit
> dem User selbst bringen. Aber wie zum Teufel ist Google an diese
> Infos gelangt?

Kann Du eine Sicherheitslücke auf Deiner Website ausschließen? Gibt es 
nirgends ein Skript, wo z.B. angemeldete Benutzer oder aktuelle Session 
aufgelistet werden - z.B. in einem Skript in einem 
Administrationsbereich, der unzureichend geschützt ist?

Mach doch mal ein HTTrack-Abzug Deiner Website und gucke, was HTTrack so 
alles erwischt! Der Vorschlag ist wirklich ernst gemeint.


> Wäre die Google Toolbar oder ein beim User aktiver Google Desktop
> denkbar? Damit hab ich leider bisher keine Erfahrungen gesammelt, da
> ich beides nicht nutze. Aber vielleicht hat jemand in dieser Richtung
> schonmal von einem Vorfall gehört?

Möglich wäre es eventuell:
http://www.google.com/support/firefox/bin/static.py?page=privacy.html


> Schlimm genug, dass Google solche Informationen für jeden zugänglich
> im Internet darstellt.

Wieso schlimm von Google? Die haben nur eine offensichtlich frei 
zugängliche Seite indiziert. Ich verstehe Deinen Ärger, der Fehler 
liegt allerdings eindeutig bei Dir. Für Sicherheitslücken auf Deiner 
Website bist Du verantwortlich, nicht der, der sich - bei Google im 
übrigen auch unwissentlich - nutzt.


> Man denke mal nur an sensiblere Daten wie beim 
> online Banking.

Die arbeiten wohl auch nicht mit der Session-ID in der URL, was 
bekanntermaßen höchst unsicher ist. ;-)


> Wobei ich hoffe, dass so etwas mit 
> SSL-verschlüsselten URLs nicht passiert. Aber man kann doch nicht
> gleich jeden User-Bereich mit einem Zertifikat versehen. Das ging
> doch bisher auch mit ausschließlich PHP.

Es geht bei Dir zunächst einmal nicht um die Verschlüsselung. Wenn Du 
weiterhin die Session-ID in der URL verwendest, kannst Du 
verschlüsseln, wie Du willst, dann kann trotzdem jeder die Daten sehen, 
der die URL mit der Session-ID hat.


> Also falls jemand irgendeine Idee hat, wie Daten aus einem nicht
> offiziellen Bereich einer Webseite, auf den wirklich nur ein User
> Zugriff haben kann, in den Google Cache gelangen können, ich wäre für
> Hinweise sehr dankbar.

Ich würde an Deiner Stelle prüfen, ob Du nicht doch irgendwo eine 
Sicherheitslücke in Deiner Website hast. Taucht irgendwo in dem 
Quelltext einer öffentlich zugänglichen Seite eine URL mit Session-ID 
auf?

Darüber hinaus würde ich an Deiner Stelle ab sofort zwingend den 
Session-Cookie vorschreiben. Wer das nicht akzeptiert, hat halt Pech. 
In einem Fall wie dem vorliegenden hast sonst Du das Problem, weil Du 
aus meiner Sicht gegen das Datenschutzgesetz verstoßen hast, weil Du 
die Daten Deiner Benutzer nicht ausreichend geschützt hast.

Anschließend kannst Du zusätzlich über eine Verschlüsselung der 
Verbindung im geschlossenen Bereich nachdenken. Ob das erforderlich 
ist, hängt von der Sensibilität der Daten ab. Liegen dort z.B. 
Bankverbindungen o.ä. wäre eine Verschlüsselung auf jeden Fall 
angesagt.


Viele Grüße
Lutz