[php] 1/2 OT Session und Google Cache

[Yannik Hampe]

Ringo Großer wrote:
> Hallo Liste,
Hallo Ringo,
> 
> ich habe mit PHP einen geschützten Bereich gebaut, welcher
> über  eine Authorisierung per Session zu erreichen ist. Also der
> User gibt Benutzernamen und Passwort ein, beides wird gegen
> seinen Account in der DB geprüft, danach erfolgt der Login per
> Schalter in seiner Session.
> Im geschützten Bereich kann der User u.a. auch seinen Punktestand
> abrufen, eine Art Bonuspunkte für seine Teilnahme.
> 
> 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.

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.
Schau doch einfach mal in der access.log nach, wann die seite mit dieser
sessionid das erste mal aufgerufen wurde und wann sie vom googlebot
aufgerufen wurde, und was der googlebot auf deinem Server ggf. zuvor
aufgerufen hat.
du kannst übrigens mit den richtigen <meta>-Tags robots verbieten die
Seite zu durchsuchen. Ich weiss nur nicht, ob die sich daran halten...

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

Alles andere wäre auch schlimm :-). Wenn der bot den Link mit sessionid
irgendwo fand, muss auch der Logout-button da sein.
> Schlimm genug, dass Google solche Informationen für jeden zugänglich im
> Internet darstellt. Man denke mal nur an sensiblere Daten wie beim online
> Banking. 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.

Woher soll google denn bitte wissen, dass es sich um einen geschützten
Bereich handelt. google kann nicht hellsehen ;-).
Selbst wenn google dies bei ssl nicht macht, solltest du dich nicht
darauf verlassen, denn google ist nicht die einzige Scuhmaschine im Web.
Ausserdem gibt es noch ganz normale Menschen, die den Link mit der
sessionid finden.
> 
> 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.

Eine plausible Lösung habe ich ja geschrieben...
Frage ist, wie du das Problem löst.
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.
2. Mit ethereal oder vergleichbar, wenn man im gleichen Netzwerk sitzt.
3. Durch Trojaner auf dem Computer der Zielperson
4. Durch Unvorsichtigkeit des Benutzers (wenn der einen Link mit
sessionid veröffentlicht).

Gegen 1 und 4 hilft es cookies vorrauszusetzen, denn dann kommt die
sessionid nur im http-request vor, aber wird nichtmehr als URL in der
Adressleiste des Browsers proklamiert.
Gegen 2 hilft SSL. Aber das ist auch die einzige Attacke, die ssl
verhindert.
Gegen 3 bist du machtlos. Wenn sich irgendwer hinsetzt und es schafft
ein Progrämmchen auf dem Zielcomputer zu installieren, welches die
sessionid herausfindet und versendet (cookies sind einfach auf der
Platte und der Verlauf des Browsers bei ausgeschalteten Cookies genauso).

In deinem Fall handelt sich sich wahrscheinlich um 4.
Cookies könnten das zwar verhindern, dafür hast du mit cookies andere
Probleme. Zum Beispiel kannst du den Benutzer dazu bringen eine andere
Seite zu öffnen während er eingeloggt ist. Dann kann diese Seite den
Benutzer dazu bringen auf einen Link zu klicken, der eine Seite in
deinem geschützten Bereich ansteurt. Ganz ohne deine sessionid zu
kennen, denn die schickt der Browser praktischerweise automatisch mit.
Mit ajax macht das ganze noch mehr Spass...
Ob das mit ajax funzt habe ich allerdings noch nie getestet.

Im Internet Explorer gibt (oder gab es zumindest) auch ein paar
Sicherheitslücken, mit denen man mit VBScript Cookies anderer Seiten
auslesen kannst.
So einfach kommst du an die sessionid nicht dran, wenn du nur mit ssid
in der URL arbeitest.

Fazit: Cookies sind auch nicht sicherer ;-).

Es gibt aber noch eine Methode, wie du dich vor den Auswirkungen des
Bekanntwerdens der sessionid schützen kannst:
Speicher die IP!
Mit ip2long() kannst du die ip des Benutzers bequem in einem
Longint-Feld einer DB (oder sonstwo) speichern und dann bei jedem Aufruf
prüfen, ob die ip sich geändert hat.
Nachteil: Wenn der Nutzer eine der berüchtigten in Deutschland üblichen
24h-Trennungen hat, dann kann er sich direkt ein einloggen.
Ausserdem bekommst du Probleme mit anonymizern, die ständig den proxy
wechseln.
Dann könntest du noch den User-Agent (oder einen substring daraus)
speichern und vergleichen. Der googlebot hat nämlich seinen eigenen
User-Agent. Ausserdem darf es dir ruhig verdächtig vorkommen, wenn der
Benutzer plötzlich den Browser wechselt. Das ist dann doch sehr
unwahrscheinlich. Allerdings ist auch diese Methode nicht wirklich
verlässlich: Wenn ein anderer Benutzer den Link findet und zufällig den
gleichen Browser hat (wahrscheinlich!) dann hat die Methode schon wieder
nichts gebracht.
> 
> Einen schönen ersten Advent wünsche ich noch, Ringo. 
> 

Yannik