Superfrischer Privacy-GAU bei StudiVZ
Hi Jojo, ich hätte jetzt gerne eine Fortsetzung hiervon, und zwar, wie ich durch eine Bresche in die von diversen Sicherheitslücken Belästigungs– und Nazipostillenskandalen erschütterten Startupburg StudiVZ reite, die Lanze eingelegt und sich der Junge aus dem Morgenland vor mir in den Turm zu retten versucht, wo das Kapital gerade bittere Tränen vergiesst. Denn StudiVZ hat mal wieder ein irrwitziges Sicherheitsproblem, das das weitestgehende Ausspähen anderer Leute erlaubt.
Also, stellen wir uns mal vor, wir sind so ein universitärer Stalker. Wir waren in der berüchtigten *****-Gruppe, wir haben mehrfach die Blogbar gespamt, wir sind der echte Abschaum des Netzes und finden es geil, wenn wir ganz einfach anderen was anhängen können. So wie unserer Mitstudentin Susi, die uns für einen stinkenden, versoffenen Schwachkopf hält und das auch deutlich zum Ausdruck brachte, als wir versucht haben, sie zu betatschen. Jetzt sitzen wir also im Projektraum, Susi ist an einem PC und grinst sich eines, kichert und hat offensichtlich Spass. Wir ärgern uns, wir würden ihr nur zu gern zeigen, was es heisst, uns anbetteln zu müssen, weil wir etwas über sie wissen, was keiner wissen darf. Du, Susi, sagen wir, ich müsste auch mal ans StudiVZ, sagen wir. Aber bitte, sagt Susi, logt sich aus und lässt uns ran. Und damit haben wir sie im Sack, wir können spielend leicht sehr viel über Susi herausfinden. Denn StudiVZ ist
SO BESCHISSEN PROGRAMMIERT, DASS WIR PROBLEMLOS AUF IHR VERHALTEN BEI STUDIVZ ZUGREIFEN KÖNNEN.
Und das ohne Hack, ohne Erraten von URLs, einfach mit einem einzigen Button und unserem Password. Denn zuerst loggen wir uns auf dem geöffneten Browser wieder mit unserem eigenen Benutzernamen ein – am besten mit einer Fakeidentität, deren Besuche nirgends angezeigt werden. Das sieht dann so aus.
Und jetzt brauchen wir nur noch ein Werkzeug, um Susis letzte Zeit bei StudiVZ zu durchschnüffeln. Es ist ganz einfach – der grüne Rückwärtsknopf links oben beim Firefox oder bei diesem anderen Browser, na, Internet Explorer, glaub ich heisst der. Den drücken wir einmal, kommen auf die Einlogseite, dann nochmal und Oooops:
“Aber Du kannst Dich nicht selbst gruscheln”, steht da. Nanu? Wir haben niemanden gegruschelt, das muss wohl ein Rest aus Susis betätigung sein, und das Programm denkt jetzt, wir würden das Gruscheln abbekommen. Nochmal auf Zurück clicken und, des Rätsels Lösung:
Susi wollte den – hier geschwärzten – Herrn gruscheln! Na sowas. Da schau an. Soso, gruschelt sie also. Das wird sicher spannend. Gehen wir noch einmel zurück und schauen wir, was da kommt:
Seine Profilseite. Interessanter Herr. Keine Freunde, aber Mitglied in zwei Gruppen. Einmal Analsex, und einmal eine Gruppe, die sich wohl intensiv mit der Beschaffenheit weiblicher Unterkörper auseinandersetzt, um das mal höflich zu sagen. Aber wir dreckige Stalker, wir lieben das; Susi hat diese Sau gegruschelt! Geil! Und weiter zurück!
Wohoo! Daher also hat sie ihn! Susi hat sich die Analsexgruppe angeschaut. Prima, dass wir es und mit diesem simplen Trick auch anschauen können. Jetzt ist es so gut wie sicher: Susi ist bei StudiVZ, weil sie Interesse an Analsex hat. Und nochmal weiter zurück.
Aha! Susi hat gezielt nach Analsex-Gruppen gesucht! Klar, sie hat keine Lust, als Mitglied bekannt zu werden, aber sie geht einfach in die Gruppen und sucht sich über die Mitgliederliste einen Kerl raus. Und sie denkt, das würde keiner merken. Hähä. Morgen ziehen wir wieder eine Stalkergruppe auf, (sowas ist ja nie ganz auszuschliessen, vermute ich, solange die führendne Köpfe der alten Gruppe bei StudiVZ sind) und dann erzählen wir es ALLEN. Und nochmal etwas zurück.
Prima – da kommen wir auf die Seite eines Albums, das wir uns nicht ansehen können. Ansehen nicht – aber dafür die Album-ID aus fünf Zeichen eindeutig Susi zuordnen. Was sie da drin wohl für Bilder versteckt haben wird? Nachdem die Bilder ja trotzdem frei auf dem Server liegen, wird man halt etwas rumprobieren müssen, aber wir wissen, dass Susi hier geheime Bilder hat. Den Inhalt können wir uns lebhaft vorstellen. Und nochmal zurück:
Ha! Ihre Profilseite! damit schliesst sich der Kreis. Susi glaubt, ihre Daten bei StudiVZ sind sicher. Fakt ist aber: Nichts ist sicher. Man kann ihren Weg im angeblich geschützten StudiVZ problemlos mit dem eigenen Passwort und einem offenen Browser nachvollziehen, sich ihr Verhalten anschauen, ihre privaten Beziehungen ausspionieren und Informationen über ihre Inhalte sammeln – und das, obwohl sie ihr Profil scheinbar ideal abgesichert hat.
Kurz: StudiVZ hat ein enormes Datenschutzproblem, und es ist so gross, dass ich vermute: Sie kennen es. Es gibt einfach keinen Mechanismus, der eine Session abschliesst. Da hilft übrigens auch kein Leeren des Browsercaches. Und das Problem besteht seit Wochen, vermutlich sogar von Anbeginn. Es ist unfassbar, es ist kinderleicht, und wie dann einer von denen behaupten kann, dass ihnen die Sicherheit der Nutzer am Herzen liegt – muss reiner Zynismus sein.
Dass Unister übrigens auch Probleme hat, weil sie Session-IDs vergeben, die, so die URL irgendwo die Runde macht, jedem erlauben, auf die Profile der betroffenen Nutzer unbegrenzt zuzugreifen, ist auch nicht schön. Eher eine Katastrophe. Aber wenigstens hat man sich um etwas mehr Sicherheit der Sessions bemüht. StudiVZ hat absolut nichts getan, sie sind meines Erachtens ein Fall für den Datenschutzbeauftragten in Berlin, und, falls jemand durch so eine Aktion wie auch immer zu schaden kommt, ein guter Grund, mal mit dem Rechtsanwalt zu sprechen. Susi ist zum Glück nur ein Fake – hunderttausende Leute, die StudiVZ von öffentlichen Computern in der Uni nutzen, dagegen nicht. Ich habe nit einem Projekt zu tun, bei dem 250 sich nicht immer grüne Leute auf 30 frei nutzbare Internetrechner verteilen – und ich werde jetzt gleich mal mit dem Leiter sprechen. StudiVZ dagegen sollte das Teil schleunigst vom Netz nehmen.
[Edit]: Weil die Frage aufkam: Es geht auch,
– wenn sich der Nutzer ausgeloggt hat
– man sich anders einloggt
– zurückgeht
– und dann zu den internen Mails kommt
Das sieht dann Schritt für Schritt zurück so aus – Susi hat sich auf ihrer eigenen Seite ausgeloggt, dann beim nächsten Zurück kommt:
Man drückt auf OK, und es erscheint:
und nochmal zurück, viola:
Man wird ironischerweise selbst als Absender für die Mail von Susi sichtbar, erkennt aber, an wen die Mailvon Susi ging. Der Text ist glücklicherweise nicht sichtbar.
Sorry, the comment form is closed at this time.
oh man, fast jeden Tag ein neuer Daten-Skandal…
Und anscheinend ist der letzte immer noch zu toppen.
Mir fehlen die Worte! Dann heißt es jetzt wohl nur abwarten, wann die wieder Käffchen trinken gehen…
btw. Erster ;-)
Und hier die Spammer aufschlagen. Aber heute wird gnadenlos deleted.
Wie krass ist das denn?
UNd hast du für auffinden des Fehlers das versprochene Geld bekommen?
Mal eine Frage: Wäre es nicht durchaus interessant sich als StudiVZ Mitarbeiter einzuloggen ;) Nur mal so als Ratschlag für deinen nächsten Beitrag :) Lass es dir durch den Kopf gehen.
Gruß
Schön rausgefunden wie sicher die Daten nun nach der Downtime sind.
Klappt das “zurück”-Spielchen auch mit Nachrichten?
Hat das jmd. selbst ausprobiert ?
funktioniert das tatsächlich?! ich kriegs mit zwei konten nicht hin..
Das ist kein Hack. Das ist absolut nichts, es dürfte vermutlich noch nicht mal illegal sein, weil hier absolut nichts geschützt ist. Es gibt Null Sicherheitsvorkehrungen bei StudiVZ. Zahlen tun sie nur, wenn man einen Fehler findet.
Das hier ist kein fehler. Das ist Standard. Und das schon seit langen Zeiten. Ich glaube nicht, dass ich der erste bin, der das gefunden hat. Ich bin de este, der darüber schreibt. Was die anderen getan haben – keine Ahnung.
@Kay & Dominik
Ja, das funktioniert einwandfrei… ich bin dann mal im Rechenzentrum :-P
@Don: Gratulation! Hoffentlich geht das auch an Heise?
Bastian, es geht über weite Strecken. Nicht überall. Man sieht nicht, was verschickt wurde, aber an wen.
Immerhin da ein kleiner Teil Sicherheit…
Im dritten Screenshot von oben scheint nicht gründlich genug geschwärzt worden zu sein, der Name taucht nochmal auf.
1. Im ie7 funktioniert das bei mir NICHT.
2. Beim Firefox halte ich es nicht für eine Sicherheitslücke des StudiVZ, sondern um ein Feature der aktuellen Version des Browsers 2.0, die neue session history. Schließlich funktioniert es bei mir (Firefox 2.0) auch mit z.B. GMX nach dem Logout.
@Don:
Das Problem ist ja wohl eher der Browser-Cache. Dass ist ein grundsätzliches Problem, das einzige wäre, den Browser (Firefox oder Safari können das, für den IE gibt’s wahrscheinlich auch Tools, die das erlauben) auf “Privat surfen” zu stellen.
Und deswegen ist der Fehler bei unister.de vielleicht doch schlimmer, als Dir klar ist. Denn mit der wunderbaren URL-Vervollständigung vieler Browser kommt man so ja auch leicht an gar nicht so alte Sessions. By the way: An das Profil des Herren gestern komme ich mit der Session von gestern immer noch! Und Ausloggen hilft auch nicht, die Session wird offenbar nicht vernichtet – was ja im Zusammenhang mit dem Ausloggen naheliegend sein sollte. Machen die aber leider nicht.
auf meinem (privaten) rechner sind die zugangsdaten meiner freundin gespeichert und eben meine.. da sie nichts dagegen hat, habe ich das eben getestet.. login bei ihr, ausloggen (browser firefox2 bleibt an) und dann mit meinem einloggen.. mit dem rück-button komme ich maximal zur auslogg-seite von ihrem konto, weiter definitiv nicht!
Es funktioniert. Gerade getestet.
Damals, als zum Ende des letzten Jahrtausends Webanwendungen programmiert habe, war es eine meiner ersten Aufgaben auf meiner Liste, so eine Lücke zu verhindern.
Eine Session gehört beim Ausloggen gekillt und die Cache-Routinen der Browser so angewiesen, dass sie auch nix gecacht haben, was sie nicht sollten.
Mal wieder Privacy bei StudiVZ – Ein Blick hinter die Kulissen
Vor ein paar Minuten berichtete Don Alphonso auf BlogbarÃber eine neue SicherheitslÃcke bei StudiVZ. Was ist passiert? Naja, eigentlich nichts schlimmes, nur daà eben beim Logout die Sitzung nicht beendet wird. Somit kann man nachdem Logout eine ander
Hilt es nichrt das Browserfenster zu schließen? Das geht doch nur, wenn jemand _im selben_ browserfenster wieder einloggt, oder? Ich meine, sorry, dass ich Fenster schließen soll, wenn ich aus einer sensiblen Seite auslogge, darauf macht mich sogar meine _Unibibliothek_ jedesmal aufmerksam (weil sonst andere mein Konto verwenden könnten)…
Also, entweder, die haben diese Sicherheitslücke alle…oder man muss eben das Fenster zumachen und gut is…Da ich nicht soviel davon verstehe wäre es nett, wenn mir jemand das erklären kann.
Nachtrag zu 14:
Und im sechser-IE klappt es bei mir ebenfalls nicht. Wäre noch mit einer FF-Version
don: hast du das von einem der programmier-nerds mal checken lassen. du sagst ja selbst, dass du ingenieursmäßig, also durch anwendung die sicherheit prüfst. ein nerd könnte deine feststellung durch sachkenntnis stützen.
vorsichtshalber: habe nichts gegen nerds. und ingenieursmäßiges vorgehen ist selbst in der wissenschaftlichen forschung verbreitet.
Das ist doch lächerlich. In welchem Uni-PC-Pool lässt man denn sein Konto unangetastet offen und sogar den Browser offen? Bei uns meldet man sich als komplett neuer Benutzer an.
Abgesehen davon, wie oben gesagt, funktioniert das auch bei GMX.
–> Leider wirst du niemals ernst zu nehmen sein, weil du nicht objektiv berichtest, sondern den Machern von Studivz offensichtlich persönlich an den Karren fahren willst. Was war denn passiert, hatten sie vergessen, dich zu einer ihrer Parties einzuladen, oder was konnte diese schwere Kränkung hervorrufen?
@Oli:
Ja das sehe ich auch so… zumal am heimischen PC die Sache nicht wirklich relevant ist und in ordentlich konfigurierten Internetcafes/CIP-Pools/etc. der Cache inkl. History bei jedem Benutzerwechsel gelöscht werden sollte…
Das Unister-Problem ist da bei weitem gravierender!
@17: Gerade wollte ich dasselbe schreiben … das ist ein Fehler, der mir zu Anfang des Aufstiegs der Webmailer wie Hotmail, FreeMail oder GMX begegnet ist. Dort wurde das schnell behoben und ist (sollte?) seitdem Standard bei der Verwendung von Session-IDs in diesem Anwendungsrahmen sein.
Du bist ja ein Schlauberger, das ist studivz unabhängig (“Standard” wie du es selbst nennst) und trifft natürlich auf den gesamten Verlauf des Browsers zu. Also wenn in deinem Beispielsfall die Dame “Analsex” oder irgendwas anderes gegoogelt hat, dann kann man dies auch sehen. Oder jede andere Website die sie besucht hat. Aus diesem Grund werden auch in jedem Rechenzentrum nach dem Ausloggen die persönlichen Daten gelöscht. Wenn man dies tut, gibt es kein Problem.
Btw, man sollte eigentlich von einem mündigen Bürger oder mündigen Verbraucher ausgehen, der zumindest einige grundsätzliche Sicherheitsvorkehrungen bzgl seiner Daten selber treffen kann. Dazu gehört es sich an öffentlichen Computern auszuloggen oder, wenn dies nicht geht, den Verlauf zu löschen. Warum auch immer du so eine Aversion gegen studivz hast, dieses von dir geschilderte “Problem” kannst du ihnen jedenfalls nicht entgegenhalten.
Funktioniert mit meinem Browser nicht…
Abgesehen davon ist das Beispiel mit der Analsex Gruppe wirklich unter aller Sau!!!
Das wird das, ach so hochgeschätzte heise, bestimmt nicht gerne sehen.
Bitte nicht persönlich nehmen, aber das musste mal gesagt werden.
Ohne StudiVZ verteidigen zu wollen….Aber Dein Beispiel hinkt ein wenig. Ich habe das gerade mit dem Firefox 2.0 bei GMX ausprobiert. Geht auch.
Morgen,
also das mit der Session-ID ist ja wohl ein uralter Hut und funktioniert übrigens fast überall, auch bei gmx und web.de, wenn man sich nicht explizit ausloggt, sondern einfach nur den Tab schliesst.
Dass die Session-ID nicht abläuft … ok, das ist einfach nur schlampige Programmierung, denn man kann das sehr wohl sehr fein und detailliert machen … wenn mqaan`s denn kann
Alle neuen Browser haben übrigens `ne Funktion, Surfdaten am Ende zu löschen … kann sogar automatisiert werden …
Und wenn ich wirklich mal gezwungen bin, woanders als an meinem eigenen PC ins Net zu gehen, dann nutze ich die auch ….
Auf jeden Fall log ich mich nicht einfach irgendwo aus und lass den Browser offen … soooo schlau müsste eigentlich auch ein/eine Student/in sein …
Felix, Du bist ein asoziales Stück Spam. Weil Du vermutlich genau weisst, dass es in der Praxis kaum jemand macht. In der Praxis heisst es “Lass mih mal schnell ran”. In dem Fall hilft auch nicht Cache löschen, man muss schon in den verlauf. Und ich glaube nicht, dass die mehrhit der Internetnutzer auch nur weiss, dass es sowas gibt. Zumindest nach meinen Erfahrungen mit Studenten.
Es ist darüber hinaus vollkommen egal, ob das jemand tut oder nicht. Wenn da steht “raus hier”, hat der Betreiber Sorge dafür zu tragen, dass der Betreffende definitiv raus ist. Sogar bei einer nicht gesicherten Seite wie Immobilienscout24.de fliegt man nach 30 Minuten Inaktivität automatisch raus und kann nicht zurück. Und bei einem Auto, das keine Bremsen hat, wirst Du wohl auch kaum verlangen, dass die Leute die Beine raushängen und damit auf dem Asphalt bremsen.
Damit ist der Teil der Debatte abgeschlossen, weitere “Selbst-Schuld”-Einlassungen werden hier immer wieder mal gelöscht, wenn sie allzu doof daherkommen. Wie Felix.
Das ist definitiv NICHT Standard bei den Browsern oder ein neues Feature. Wie kann man nur so unqualifizierte Aussagen machen? Offensichtlich wird die Session nicht terminiert bzw. der serverseitige Session-Cache nicht gelöscht. Dies sind Mangel in der Programmierung der Webapplikation und von daher ist Don’s Fingerzeig angebracht.
@Jochen 26 Wieso? Siehst du hier Analsex diskreditiert, oder wo ist das Problem?
btw. man vortrefflich darüber streiten wie “gefährlich” dieses “Loch” wirklich ist. Fakt 1 ist bei Leuten mit gesundem Menschenverstand ist das Problem zu vernachlässigen, Fakt 2 jedoch ist, dass gerade die in dieser Diskussion sehr rar gesät waren und Fakt3 ist nun mal, dass das überhaupt nicht sein muss, wie man woanders lesen kann
Cat: Es gibt bei StudiVZ meines Erachtens keine funktionierende Session-ID, ausser der, die nach 30 Minuten automatisch ausloggt.
Liest hier keiner den Artikel? Susi hat sich AUSGELOGGT!
Versucht dann mal nach dem Ausloggen wieder per Back-Button in ein Webmailer-Postfach zu kommen. Bei zB. FreeMail geht es nicht. Hier werde ich korrekterweise zur Neueingabe von Benutzernamen und Passwort aufgefordert.
@Cat #28:
Problem: ausloggen hilft nix!
Die Session besteht auch nach dem Ausloggen weiter… Der unglückliche Poster von gestern kann sich heute immer noch im Profil rumpfuschen lassen – weil er einmal einen Link mit einer Session-ID unbedarft in einem Blog gepostet hat!
Und wie oft wird denn nicht ein Link wie “Schau mal die Gruppe/das Mädel/den komischen Foreneintrag/das Bild/… an” irgendjemand geschickt?
Bzgl. meines Kommentars #34 in Bezug auf #28 :p
Es geht um das Session-Management von unister.de…
Hi!
Ist interessant, aber mich würde noch viel mehr interessieren, ob bzw. daß die alten Lücken nach der Fünf-Tage-Downtime immer noch da sind. Zumindest ging das aus einigen Kommentaren im anderen Artikel hervor. Stimmt das? DAS wäre für mich ein noch viel größerer Skandal, der viel mehr Durchschlagskraft hätte als das hier. Wie steht es damit? Die neue (bzw. jetzt aufgedeckte) Lücke ist zwar “schön und gut”, aber wirkt auf mich jetzt nicht soo schlimm; mit den anderen “alten” Lücken konnten die Daten von Jedem ausspioniert werden, mit dieser Lücke hier nur noch von dem, der Zugang zum Rechner hat. (Oder verstehe ich da was falsch?)
Grüße
Netter Bug, DonAlphonso. Parallel dazu kenne ich noch einen der mit diesem zusammenhängt. Den poste ich lieber nicht.
Ich bin sehr froh, mich dort nicht mit meinem echten Namen und echten Angaben registriert zu haben.
Moin Leute,
Hier an der Uni Regensburg ist es wohl kaum möglich, sich fremde studivz Profile aus dem Browser Cache anzeigen zu lassen. Der Zugang zum Internet in einem der zahlreichen CIP Pools erfordert stets die Anmeldung mit Uni-Benutzername und Passwort. Deswegen meldet man sich nach jeder Benutzung auch wieder ab (Selbst die Grundschullehramtsstudentinnen vergessen das nicht).
MuhSki, ich habe eine Email: donalphonso | ät | gmail | dot | com
also das wird dann auch mein 2. und letzter Kommentar.
1. du hast unrecht, in dem urz, in dem ich bin, wird es so wie in #28 geschildert gemacht und auch sonst ist meine beobachtung dass sich leute nach ihrer session ausloggen und dass “lass mich mal ran” allenfalls eine ausnahme ist.
2. was genau war an meinem Kommentar “asozial”? guck mal im wörterbuch nach
3. schön dass du den teil der debatte für abgeschlossen erklärst, der den kern des “problems” erfasst.
Flo: WGs, Projekträume, Uniradios… Es ist klar, dass es nicht immer und überall geht. Aber es geht. Und nur, weil ein Auto bei 10 mal grün an der Ampel nicht bremsen muss, ist es keine gute Sache, wenn die 11. Ampel rot ist und keine Bremse eingebaut wurde.
Es geht nicht um den Browser-Cache, es geht hier nicht um Sessions sondern um die History. Wenn Du die History von jemanden einsehen kannst, erfährst Du halt, auf welchen Seiten er rumgesurft ist. Und nebenbei können wir auch sehen, ob Susi analsex.de, peitschenundgummi.com oder die neusten Diddl-Comics. Im Cache sollten BTW noch die Bilder aus dem geheimen Album liegen.
Würde die Session beendet, hilft das gar nichts. Einfach die URLs aus der History fischen und sich das Userprofil xyz und die Gruppen-ID abc ansehen.
Dieser Angriff setzt voraus, dass man den Computer oder die Session eines anderen Nutzers einfach übernehmen kann. Wenn der Blödmann Susis Laborcomputer haben will, sollte sie den Browser schließen. An unserer Uni werden History-Informationen seit Jahren gelöscht, wenn der User seine Session beendet.
Ich war lage nicht mehr an einer Uni – ich vermeide das auch so gut es geht. Aber: Wer geht denn in die CIP-Pools? Ich kann mir eher vorstellen, dass der Kumpel mit dem Notebook gefragt wird, ob man mal schnell in studivz gehen können.
Hat nur indirekt etwas damit zutun, aber wofür ist der “BIGipServerwww_studivz_net” Cookie gut, auf dem Testsystem gibt es den nicht…
Auch wenn das Problem bei verschiedensten Unternehmen im Netz auftaucht, scheint es ja eine Lösung zu geben, indem man die Session nach dem Ausloggen killt. Dann sollten StudiVZ UND GMX UND so weiter sich um dieses Problem zugunsten ihrer Mitglieder kümmern.
Torsten, nochmal: Susi hat sich ausgeloggt. Susi denkt, dass ihre Session damit beendet ist. Wie bei jeder Email und zig anderen Webseiten. Wenn ich mich auslogge, gehe ich in aller Regel davon aus, dass sich keiner mehr in meine Daten einloggen kann. Das geht aber. Und das ist ein erhebliches Problem.
Social Engineering ist eines der wichtigsten Werkzeuge beim Hacken. Ein vernünftiges Terminieren der Session nach dem Ausloggen aus dem Account eines Dienstes ist der beste und einfachste Weg dieses “Lass mich mal kurz ran” sauber zu verhindern.
Zu argumentieren, dass dies ja nur die Ausnahme sei oder dass man dies per Löschen des Caches nach Schliessen des Browser-Fensters umgehen kann, ist im höchsten Maße leichtfertig, dumm und gefährlich, da die eigentliche Lücke (Zugang zum Account trotz Logouts) im Dienst immer noch besteht.
Muss man eigentlich wirklich Zugang zu Rechner, Browserfenster und Verlauf haben? Wenn es sich um eine echte serverseitige Luecke handelt dann waere es viel interessanter eine man-in-the-middle Attacke zu fahren. Also den Datenverkehr zwischen Browser & sVZ irgendwo abzugreifen und mitzuprotokollieren. Und dann die “Sessions” zu uebernehmen.
@Don: Du hast nicht bei allen screenshots die url geschwärtzt…
Ich glaube dein Kampf ist so aussichtslos wie der von Don Quijote gegen die Windmühlen.
Bei Dir ist der Gegner sogar schon leider viel verbreiteter.. gegen die Bildungsneutralität der heutigen Jugend ist einfach kein Kraut (mehr) gewachsen.
Man in the middle: Es ist vermutlich möglich, aber illegal. Ich glaube ohnehin nicht, dass nach dem CCC-Kongress in Berlin bei StudiVZ noch ein Stein auf dem anderen ist. Hier geht es nicht um die Hacker, sondern um den Drecksschnüffler von nebenan, der mit einfachsten Mitteln und ohne Spuren ausspionieren will.
Habe alle deine Beiträge der letzten Wochen zur Sache StudiVZ aufmerksam
und größtenteils dankbar verfolgt – die Nummer hier ist allerdings mit Abstand die schwächste!
Klingt ein bisschen so, als ob Du krampfhaft nach irgend etwas suchst, das Du noch nachlegen kannst. Denn das hier ist nun wirklich kein StudiVZ spezifisches Problem. Wie Kommentar 25 bereits anmerkte, kann jeder, den ich an meinen Rechner lasse, meine nicht beendete Session im Browser ohne weiteres nachvollziehen. Sofern der Browser Passwörter gespeichert hat, hat die Person sogar Zugang zu meinem E-Mail Account etc. Deshalb lasse ich aber auch keinen mal einfach so unbeobachtet an meine Mühle!
Solltest Du der Auffassung sein, dass man nicht jedem Nutzer das Beenden des Browsers zutrauen kann, dann weite den Gegenstand deiner Kritik doch am besten auf Mozilla, noch besser: auf das gesamte System Internet aus!
Ernsthaft Mann, Du hast über weite Strecken gute Arbeit geleistet und viele Leute für die generelle Problematik sensibilisiert. Aber das ist doch schon ein wenig an den Haaren herbeigezogen…
Das Problem hat vermutlich nichts mit den Cookies zu tun, sondern eher mit dem Browser Cache. Habe das gerade bei GMX nachvollziehen können, bei Web.de geht das nicht. Damit es kein Problem mit dem Browser Cache gibt kann man allerdings schon von Anwendungseite aus steuern und man muss das nicht dem Browser überlassen…
@49: täusch dich da mal nicht. studiVZ ist seit einigen wochen thema unserer vorlesungen und übungen. ein aktuelleres und vor allem studi-näheres objekt für diskussionen hinsichtlich geschäftsmodell, gündung und wachstum, wahl der rechtsform, un/lauteres wettbewerbsverhalten, krisenbewältigung usw gibt es momentan kaum.
Der Cookie BIGipServerwww_studivz_net stammt vom LoadBalancer und sorgt dafür, dass er euch immer an die gleiche Kiste weiterleitet.
@Torsten #42:
Um Sessions geht es indirekt schon:
Denn nur weil StudiVZ die ganzen Aktionen wie z.B. Gruppen beitreten, Nachrichten schreiben, “gruscheln” (Kann das mal einer als Unwort des Jahres vorschlagen??), Freunde ansehen etc. direkt über die URI xxx.php?ids=xxxxx aufgerufen wird ist es erst möglich im nachhinein noch nachzuvollziehen was der Benutzer vor einem alles beim StudiVZ getan hat…
Aber das ist eigentlich nur die Spitze des Eisbergs… denn nahezualle Sicherheitslücken und Spielereien die in den letzten Wochen bemerkt wurden sind auf das Ãœbergeben von Parametern über die GET-Methode direkt in der URL zurückzuführen… Des macht es sogar mir mit ein HTML und Basic-PHP-Kenntnissen leicht z.B. Leute durch nen simplen Link Leute Mitglied in Gruppen werden zu lassen in die sie eigentlich nicht wollten ;)
Geigenhans, diese eine Album-ID ist bewusst offen, als “Proof of Concept”.
@48: sorry, deine These macht keinen Sinn. MiM-Attacken klappen hier nicht, ebenso wenig Session-HiJacking. Zwar kann man mit manipuliertem JavaScript irgendwelche User dazu bringen einem die Session ID zu schicken, aber die ist clientseitig bei StudiVZ nicht ersichtlich. Ausserdem werden die (hoffentlich) nicht so dumm sein, die IP/hostname und vielleicht den Browser-Agent (eine Kennung) auszulesen und gegen die gespeicherte Session zu prüfen.
Das ganze wird jetzt etwas technisch, aber es wird schon deutlich, das jemand bei der Programmierung nicht an die Sicherheit gedacht hatte.
DonAlphonso:
Ihre Session ist beendet. Du hast Dich nicht in ihre Daten eingeloggt. Deshalb kannst Du ja nicht Susis Kontaktdaten ändern oder das geheime Album ansehen.
Daniel H., bei einem zweiten des obigen Versuchs wurde der Cache unter Internet Explorer vorher gelöscht, der Browser holt sich selbst die Bilder wieder vom Server…
Torsten: Ändern kann ich nichts, das sage ich auch nicht. Ich sehe auch nicht ihre geheimen Bilder. Aber ich sehe, wen sie gegruschelt hat, wem sie geschrieben hat, welche Gruppen sie gesucht hat – würdest Du wollen, dass ich mal Deinen Weg im Internet verfolge?
P.S.
das Konzept funktioniert definitiv auch bei GMX. Nach dem -ausloggen- komme ich mit der Rücktaste des Browsers wieder in mein Postfach.
Tut mir leid, aber selbst wenn es eine Uni ohne Benutzerkennung im PC-Pool geben sollte(?), würde ich nicht wildfremde Leute an meinen PC lassen ohne den browser zumindest zu schließen. Erst recht nicht, wenn ich was zu verbergen hätte. Ist doch ein vollkommen lächerliches Beispiel.
@Don: Ok, dann ist es ihr Proxy/Load Balancer (quasi dein Cache Server-seitig), der Mist baut… Aber ich habe eigentlich nichts anderes erwartet…
Don:
Wie gesagt: wenn Susi den Browser am Uni-Rechner schließt, ist das Problem gelöst.
Voraussetzung: der PC ist tatsächlich für eine öffentliche Nutzung konfiguriert. Wenn er das nicht ist, ist die Browser-History eins der geringeren Probleme.
Hier mischen sich wild unterschiedlichste Diskussionsstränge – das trägt nicht gerade zur Verständlichkeit bei …
Ich versuche mal zusammen zu fassen:
1. – und von Don gestartet: Trotz Logout kann man teilweise in den Account des vorigen Users. Irgendwie scheint studiVZ da den neuen (korrekt angemeldeten) und alten User zu vermischen. Ändern kann man beim alten User nichts, aber ein wenig sehen, was der wohl so gemacht hat.
2. Die allgemeinere Problematik, dass der Cache des Browsers noch was gespeichert haben kann – wenn man nicht von vornherein “privat surfen” eingestellt hat (bzw. das vom jeweiligen Admin so eingerichtet wurde). Hier sollte in der Tat jedes vernünfte RZ und Internetcafe nach schließen des Browsers alles löschen. Gleiches gilt für die History.
3. Die Unister-Problematik, bei der – wenn man angemeldet ist – in (einigen?, allen?) URL offenbar immer eine ID (vielleicht ist es ja nicht mal die Session ;-) dabei ist. Und wenn man dann einfach einen solchen Link komplett weitergibt (ob per Mail oder wie auch immer), kann der Empfänger sich damit wunderbar als Absender ausgeben. Ausloggen hilft nicht, da diese ID offenbar nicht vernichtet wird.
3. halte ich eigentlich für am bedenklichsten – wer denkt schon daran, dass der Link, den er verschickt, die Eintritskarte für seinen Account enthält?
Ja. Und wenn sich immer alle 100% an alle Sicherheitsregeln halten, passiert nie ein Unfall, und wir könnten uns Leitplanken, Gefahrenzeichen und Stopschilder im Strassenverkehr sparen.
Ich zitiere mal aus dem Nachtrag zur “Wir sind wieder online”-Meldung von StudiVZ ( http://blog.studivz.net/?p=97 ):
“- Wir haben das Sicherheitskonzept generell überarbeitet und z.B. die Anwendung von One-Time-Tokens auf alle Seiten ausgeweitet.”
Ohne Worte.
strappato: In den meisten Unis/Pool-Räumen gibt kaum noch “Surfrechner”, die man ohne eigenen Account nutzen kann (Ich halte es hier zudem so, dass beim Schließen des Browsers Cookies, Cache und History gelöscht werden). In öffentlichen Bibliotheken oder Internet-Cafes sind sie hingegen die Regel.
Bei aller berechtigten Kritik an studiVZ: es ist doch eine Frage des eigenverantwortlichen Nutzerverhaltens. Wer einen anderen Nutzer mit dem eigenen Account unbeaufsichtigt surfen lässt, gibt damit jegliche Privatsphäre preis. Denn die Privatsphäre ist am PC in der Uni und auch am Arbeitsplatz an das eigene Nutzerprofil gebunden. Dann kann der Typ ja auch gleich ihre E-Mail (im Outlook) lesen oder in ihrem Namen anderen Schwachsinn anstellen.
Wenn sich die Nutzerin wirklich abmeldet, kann der nächste Nutzer definitiv nicht ihre “history” einsehen. Sie kann aber darüber hinaus noch ein weiteres Sicherheitswerkzeug nutzen: im Firefox gibt es den Befehl “clear private data” und damit ist die “history” auch gelöscht.
Die Story ist übrigens auch in sich unlogisch: Wenn Susi den Typen bereits als unsympathisch (“stinkenden, versoffenen Schwachkopf”) eingestuft hat, wird sie sicher nicht so blöd sein, dass sie ihn mit ihrem Uni-Account unbeaufsichtigt surfen lässt. Da sollte man noch mal über das Drehbuch drüberschauen ;-)
Ich habe das mal soeben gestest mit dem FF. Bei mir ging es nicht. Habe es mehrfach ausprobiert, aber kam nie auf Seiten eines Accounts, der ausgeloggt war. Ist das möglicherweise brwoserspezifisch?
Don: sorry, diese Lücke ist einfach keine Lücke von Studivz, sondern im Verantwortungsbereich des Nutzers. Man lässt fremde Leute nicht an seinen offenen Browser – erst recht nicht wenn sie einem nachstellen.
Es ist schön, wenn Du die Leute drauf aufmerksam machst, dass sie nicht einfach unbedacht Privatdaten auf öffentlichen Rechnern lagern – aber das war es dann auch.
BTW: Die Fehlermeldung mit dem “selbst gruscheln” wird bei Susis schmierigem Verfolger nicht auftreten – es sei denn, dass Susi ihn gerade gegruschelt hätte.
Moin Moin !
Das Problem läßt sich auf viele Webdienste anwenden und ist eigentlich auch mit ein Problem der Browser.
Vermeiden läßt es sich ganz einfach: Über eine SSL-Verschlüsselung.
Die kostet aber wiederum Performance und Bandbreite. :)
im Header jedes PHP-Skriptes sollte das Problem lösen.
<?php header(“Cache-Control: no-cache,no-store,max-age=0, must-revalidate”);>>
im Header jedes PHP-Skriptes sollte das Problem lösen.
Torsten, nochmal für Langsamdenker zum Mitdenken: Wenn Du Dich bei Gmeil ausloggst, kommst Du mit einem anderen Login nicht zurück. Warum wohl? Weil Gmail irre Sicherheitsfanatiker an der Spitze hat? Oder geht es bei StudiVZ, weil da ein paar Hansel im Bonker in Berlin mehrfach schon gezeigt haben, dass sie es nicht können? Was meinst Du? Und glaubst Du wirklich, dass der normale Internetnutzer weiss, dass so etwas nach Ausloggen möglich ist?
Genau genommen wäre letztlich alles im “Verantwortungsbereich des Nutzers”. Aber so einfach ist es nicht. Nirgendwo steht im Browser: “Ey Susi, pass auf, das kann ins Auge gehen”. Und solange das nicht dasteht, hat derjenige, der einen Dienst zur Verfügung zu stellen, dafür Sorge zu tragen, dass sich kein Fremder derartig rumtreiben kann. Gmail schafft das, Web.de schafft das – aber StudiVZ kackt voll ab. Schon mal mitbekommen, dass es sowas wie ein Bundesdatenschutzgesetz gibt?
Doch. Probiers aus. Genau das passiert. Warum? Frag die Coder. Deren Problem, und das ihrer Nutzer, die ihnen was anvertrauen.
Wie erschreckend, das funktioniert tatsächlich. Aber wisst ihr, was fast noch schlimmer ist?
DAS FUNKTIONIERT AUCH BEI GMX!!
Wo kann man sich denn überhaupt noch sicher fühlen?
@74: Immer brav den Browser-Cache löschen :)
Man fliegt mehrere Male raus, deshalb klappt Don’s Trick nicht immer. (Zumindest erscheint ziemlich oft der Einlog Screen..)
Aber ansonsten.. Habe gerade einem Kommolitonen einen ziemlichen Schreck damit eingejagd. Funktioniert mit IE 7 sowie dem Safari.
@porschekiller:
Danke fürs rausgraben. Sehr interessant.
Schönen Tag noch..
Warum funktioniert es denn bei einigen und bei anderen wieder nicht?
Die Kommentare sind dazu ja sehr widersprüchlich
Off-Topic, aber neu:
“Das Gruseln mit dem Gruscheln”
http://www.fr-aktuell.de/in_und_ausland/multimedia/aktuell/?em_cnt=1026709
—
“Holtzbrinck: StudiVZ-Gründer hat Fehler gemacht”
http://www.netzeitung.de/internet/470125.html
@MissE (Kommentar Nr. 74) GMX benutzt auch keine SSL-Verschlüsselung , gMail dagegen schon.
Ein SSL-Zertifikat kostet nicht die Welt, das Problem wird bei StudiVZ und wahrscheinlich auch bei GMX sein, dass sie zu wenig Server und Bandbreite zur Verfügung haben. Sollte StudiVZ einfach die ganze Kommunikation vom Login an über SSL laufen lassen, hätten sie eine Menge Lücken weniger.
Bei mir ging es von drei unterschiedlichen Rechnern und 2 Providern und 2 unterschiedlichen IPs und drei Browsern (Opera, Firefox, IE) aus. Und zwar immer. Auch mit gelöschtem Cache.
GMX ist auch ein Saftladen! Selbst beim Secure Login via https://gmx.net wird man einfach auf die normale http-URL ins Postfach geleitet. Nur die Passwort-Übergabe wird verschlüsselt.
Deswegen bekommt GMX auch jedes Mal bei diversen Testvergleichen bei Sicherheit ein fettes Minus!
Deswegen bekommt StudiVZ hier ein fettes Minus!
Ich hab mittlerweile das Gefühl, dass StudiVZ nicht nur nicht kann, sondern erst gar nicht *will*, dass da normale Sicherheitsanforderungen für private Daten umgesetzt werden. Der hanebüchene “Nachtrag” (s.o.) schreit geradezu nach “Lüge!!” und die Downtime über mehrere Tage war garantiert nicht erforderlich, um die dort beschriebenen “Lücken” zu stopfen. Das kann man im laufenden Betrieb mit kurzen Reboots problemlos machen.
Don hat es mehrfach gesagt: Dort werden Daten über Vorlieben, Kontakte und Lebenslauf *in strukturierter Form* gesammelt. Ausspähen per Google & Co. ist ja für nicht-total-Vetrottelte schon simpel; für den Rest ist halt StudiVZ da.
Sie haben schnell reagiert. Bei mir funktioniert es nicht mehr: Seit ein paar Minuten benutzen sie den gleichen Cache-Control-Header wie Facebook, und siehe da, das Problem ist weg *g*
mist http://www.gruschln.de is schon weg ;) auch ne nette idee fürs gruschln. Bei mir heisst das eh gruschln und nicht gruschELLN mit e is doch blöd.
Übrigens, StudiVZ lässt Nutzer wissen:
Eigentlich müsste da stehen:
So, nun machen wir es noch einfacher:
– wir loggen uns NICHT bei StudiVZ ein
– wir clicken im Browser of “Offline surfen”
– wir öffnen die History vom heutigen Tag
– wir clicken auf eine von Susi’s Seiten
– wir sehen alles, was sie gemacht hat
Das geht bei:
– Amazon
– eBay
– Postbank.de
– GMX
– Google
– Web.de
– und überhaupt überall, solange der Benutzer dumm genug ist, dich an seinen PC mit seinen aktiven Account zu lassen. Da allerdings in jeder Uni jeder Student clever genug ist, fremde nicht an seinen Account zu lassen. Und Leute, die man mit “lass mich mal kurz” ranlässt, die kennt man normalerweise aus dem eigenen Freundeskreis.
Ist das nun eine Sicherheitslücke von den Anbietern oder Abuse vom Browser?
Elias, ich bin mir ziemlich sicher, dass sie ihre Nutzer von dem monatelang existierenden Problem keinerlei Mitteilung machen werden.
Unister hat übrigens nicht nur Privacy-, sondern auch massive XSS-Probleme (i.e. in User-Blogs oder der Suche). Ist alles derselbe Mist auf dem Markt.
Ja Don, aber über diese dreiste Informationspolitik von StudiVZ sind wir uns doch einig, oder?
Haben die nicht schon im Sommer behauptet, sie hätten das System von unabhängigen Security Experten testen lassen? Das war definitiv eine Lüge. Oder die Security-Experten haben während der Arbeit crack geraucht.
Bei einer bestimmten Sorte von Managern ist das einfach Teil des Arbeitsstils, ständig irgendwelche Experten zu erfinden, die es nicht gibt. Dient lediglich zur Beruhigung der Kundschaft.
Mayflowe: Nachdem sie gerade ihr Teil notdürftig geflickt haben, dürfte es wohl eine Sicherheitslücke gewesen sein.
h1ro: Wenn Du Beweise hast, kannst Du sowas gerne behaupten. Einfach mal einen mutmasslich geschäftsschädigenden Satz ablaichen ist dagegen ein Problem. Daher das Edit.
Sehr lustig Don. Warum geht das dann bei ALLEN Webseiten, sogar https:// ?
Weil man das “Offline Betrieb” nennt und der Browser einen Cash hat.
Es handelt sich also nicht direkt um eine Sicherheitslücke, sondern um eine fatale Entwicklung im Kozept von Internetbrowsern.
Das war ein echter Flachschuss. Sorry, Alphonso.
SSL ist eigentlich in öffentlichen Netzen ein Minimum an Sicherheit, aber für das obige Problem nicht die benötigte Lösung.
Das Problem ist, dass sie Squid oder ähnliches benutzen und der speichert die aufgerufenen Seiten serverseitig zwischen (deshalb kann man auch den lokalen Browser Cache löschen) und die Cacheverwaltung nicht richtig steuern.
Mayflow, Du bist ein Schwachkopf. Wie oben ausgeführt, ging es auch mit gelöschtem Cache. Cache, nicht Cash. Cash ist das, womit man Zeug kauft, um sich die Birne einzunebeln. Das ist nicht klug. Lies besser erst mal, bevor Du Dich mit sowas blamierst.
Bravo Don, wieder. Aber wenn wir schon persönlich werden:
Mein Name ist “Malfoy”, nicht “Mayflow” und auch nicht “Mayflowe”.
Das, was du meinst ist vermutlich die “Mayflower”.
Aber ich weiß, im Hass macht man Schreibfehler. Das gilt für mich und für dich.
Und wenn du schon vom Löschen des “Caches” redest, dann sollte im gleichen Atemzug auch das Löschen des “Verlaufs” genannt werden. Und dann funktioniert das leider nicht mehr.
Mal davon abgesehen, dass man einen Browser SCHLIESST, wenn man seinen Arbeitsplatz verlässt.
Klar, wenn du dein Auto vor dem Bäcker stehen lässt und der Schlüssel steckt und die Tür offen ist, dann KÖNNTE damit jemand durch die Gegend fahren. Aber so dumm ist man ja auch nicht.
Was mich da ein bischen nervst.
Es ist auch überhaupt nicht so, dass Web2.0 Seiten grundsätzlich unsicher sein [b]müssen[/b]. Bei Gmail existieren nämlich eine Menge der Sicherheitslöcher nicht. Es gibt auch Leute, die sich dafür Lösungen überlegen (wie dieser sympathische Texaner, z.B.: http://radio.javaranch.com/pascarello/)
Jaha – blöderweise denkt der normale Nutzer aber, dass er den schlüssel in der Tasche und zugesperrt hat, was nun mal des Sinn des Ausloggens ist.
[Edit: Manchmal ist es besser, immer sofort seinen Intentionen zu folgen und gewisse Herrschaften gleich in Richtung Spamkarma zu schicken]
Werter Malfoy,
ich möchte ja zu gerne sehen, wie Du Dir per Verlauf den Inhalt von entsprechend geschützten (!) Seiten anzeigen lässt, NACHDEM sich der Account-Inhaber ordentlich aus seinem Account abgemeldet hat und die Session dabei geschlossen wurde.
Und zum Thema Social Engineering habe ich bereits etwas erwähnt. Wenn man durch einfache technische Maßnahmen (die ja offenbar gerade bei StudiVZ umgesetzt wurden) Accounts schützen kann, sollte man nicht hergehen und diese Verantwortung stattdessen auf den Nutzer abwälzen.
Ich glaube vielen hier ist aufgrund mangelnder Kenntnisse im Bereich Webcoding nicht bewußt, worum es eigentlich geht. Browsercache und History sind erstmal egal, es geht darum, daß selbst wenn der Browser beim Zurückspringen in der History die Sites neu lädt, trotzdem die Inhalte angezeigt werden, aber halt so daß man unter seinem eigenen Namen surft und nicht unter seinem Vorgänger. Deshalb auch die Kuriositäten beim Mailversand wo der eigene Name als Absender steht. Man man seinen Browser so einstellt daß er *immer* erst aus dem Cache lädt braucht man diesen Trick natürlich nicht. Aber auch bei augenscheinlich sicheren Systemen mit zwangs-Reload und geleertem Cache kommt man so noch an die Spuren des vorigen Benutzers.
Also kommt mal klar Leute und hört auf mit dem pseudoklugen Gelaber von wegen Cache und Tabs schließen und kA.
@Malfoy:
Hmmm, mit dem FF klappt das nicht … aber mit dem IE 7. Ok, da hast Du recht gehabt, mea culpa!
das problem von dem du da in deiner üblichen nicht ernstzunehmenden weise berichtest ist doch seit jahren allgemein bekannt und ist auf keinen fall exklusiv in verbindung mit studivz zu betrachten, wie du es in deinem “bericht” praktizierst. kindergarten!
An die Programmierer unter euch: Wie löst man so ein Problem mit dem Cache? Grundsätzlich wird ja – auch wenn Sessions vorhanden sind – die Seite aus dem cache gelesen. Da nützen Sessions auch nicht viel. Was muss man also beachten, damit ein wirksamer Schutz vorhanden ist?
Hab auch eine in Php realisierte Internetseite mit Login. Aber da ist das Problem weniger schlimm :-)
Gruß
Kann es sein, dass die Macher dieses Bloggs auch ein Datenschutzproblem haben? Wenn ich den Inhalt der abgebildeten Screenshots richtig interpretiere, steht dort ein Mal der echte Name von “Susi”. – Und zwar ungeschwärzt…
bei der Unzahl der Kommentare verliere ich die Ãœbersicht, aber habt ihr schon das hier gesehen?:
http://blog.beetlebum.de/2006/12/04/vorweihnachtsgeschichte
http://www.frickelvz.net/
Was für ein geniales Comic – ich komme aus dem Lachen nicht mehr raus … ;)
“Brüste!”
@DonAlphonso (#29)
“Felix, Du bist ein asoziales Stück Spam”
“Damit ist der Teil der Debatte abgeschlossen, weitere Selbst-Schuld-Einlassungen werden hier immer wieder mal gelöscht, wenn sie allzu doof daherkommen. Wie Felix.”
Locker bleiben, willst doch sicherlich nicht den Anschein erwecken, noch nervöser auf berechtigte Einwände und Kritik zu reagieren, als gewisse “Macher” des StudiVZ!?
Die Partei hat halt nicht immer Recht…
Sicherheitshinweis. Aus Sicherheitsgründen empfehlen wir Ihnen, das Browserfenster zum Ende der Nutzung unserer Internetseiten zu schließen und nicht für den Besuch weiterer Seiten im Internet zu verwenden. Dieser Hinweis gilt insbesondere dann, wenn Sie das Online-Banking nicht von zu Hause, sondern von einem öffentlichen Ort aus nutzen (z.B. Arbeitsplatz, Internet-Café).
An welcher Stelle kommt bei SrasiVZ dieser Hinweis?
@107: das ist absolut falsch – und wenn es bei deiner Hausbank so ist, dann empfehle ich dir einen Wechsel. Intelligent programmierte Webseiten im Onlinebanking-Bereich haben nämlich idR eigene “Zurück” Buttons, damit die Session gewahrt wird und bestimmte Security-Tokens (google danach) mitübergeben werden, um die Validität des Aufrufs zu prüfen. Wenn man dann trotzdem mal per Browser-Back Button versucht rückwärts zu surfen, dann wird entsprechend dieser Security-Token nicht mitgeschickt und man wird auf eine Hinweis-Seite geleitet, die einem erklärt, dass man so nicht durch die Seite navigieren kann.
Ok, der mittlerweile gelöschte 107 war gemeint.
C., die Lebenserwartung für Leute ohne valide Email und mitunter auffälliger IP ist hier generell nicht hoch. Zum einem, weil es bei StudiVZ eine Gruppe zum Absprechen solcher Verhaltensweisen gibt, zum anderen, weil hier momantan lieber mal einer zu viel gelöscht wird, als zu wenig. Wenn oben einer nicht genau liest, wenn einer die Kommentare nicht verfolgt oder gleich auffällig hier unten einsteigt, wars das.
Warum? Weil ich kann. Das hier ist kein Müllabladeplatz für Trolle, und wenn ich die Wahl habe, ob die Trolle ihren Spass haben sollen oder ich, dann ist meine Entscheidung klar.
gabb: die Banken schreiben den Sicherheitshinweis trotzdem hin.
Hi,
ist zwar etwas OffTopic, hat also nix mit StudiVZ zu tun.
Aber hier gibt’s Profile zu verschenken. 14000 persönliche Profile zu verschenken!
http://www.nurstudenten.de/index_start.php?trefferid=XXXXX
XXXXX mit einer Zahl zwischen 1000 und ca. 15000 ersetzen.
Bester Don Alphonso. Respekt für deine bisherige Arbeit, ich habe sie gerne gelesen. Aber diese ‘Vorwürfe’ sind jetzt mal so hanebüchen und an den Haaren herbeigezogen, wie es nur geht.
Diese ‘Vorwürfe’ treffen genauso auch auf viele tausend andere social Networks / Internetprojekte (z.B. auch openBC/Xing, die genauso ‘BESCHISSEN PROGRAMMIERT’ sind)
Um im Text überhaupt den Leser an der Stange zu halten musstest du dich auf das billigste Boulevard-Niveau begeben und (Männerphantasie live) eine scharfe Analsexliebende Kommilitonin erfinden. Einfach nur billig!
Genauso könntest du jetzt über die gleiche ‘Sicherheitslücke’ herausfinden, dass Susi nach Analsex gegooglet hat, o.ä. Dass jeder Browser eine History und ein URL-Autocomplete hat und du darüber ähnliches herausfinden konntest, mal ganz beiseite gelassen.
Mit derartigen ‘Recherchen’ disqualifizierst du dich leider als kompetenter Gesprächspartner, aber wirst sicherlich beim Springer Verlag in Hamburg gerne als Redakteur eingestellt…
Gruß,
gulli
@111 (flawed): Richtig, aber hinter dem Sicherheitshinweis steckt wie beschrieben auch ein Sicherheitsmechanismus – im Gegensatz zu studiVZ. Obfuscation is not Security
@113 (gulli): Die Mentalität musst du mir mal erklären ..
Weil es andere Seiten gibt, die genauso miserable Sicherheitsvorkehrungen haben und sehr schwache Programmierer anstellen, ist studiVZ nun auf einmal doch nicht so unsicher? Sicherheit und Datenschutz sind relativ? Duh ..
Hi .. als ich heute früh meine WELT-Kompakt las … hat mich folgender Artikel angesprungen:
http://www.studivz.net/showalbum.php?id=Vfk2LB
Bitte entschuldigt die schlechte Qualität aber mein Scanner ist sehr alt und nciht mehr der Beste :/
Der Artikel ist in der Printausgabe so rausgekommen. Der Artikel nimmt die ganze Seite ein und die WELT-Kompakt ist eine Zeitung die vornehmlich von Studenten gelesen wir. Sie erscheint unter anderem hier in Berlin aber auch in Hamburg, Frankfurt und eine Menge anderere große Städte in Deutschland.
Die Welle der schlechten presse geht weiter und endlich erreicht es auch mal ein paar Printmedien, so dass auch eine größere Menge an Studenten erreicht wird ….
Gruß Matze
P.S.: Ich bin hier neuer Stammleser, thx Don ;)
Don, wäre es nicht ratsam den Beitrag dennoch zu präzisieren?
Ja, per “Offline Betrieb” kann man auch geschützte Seiten aufsuchen.
Nein, das ist noch lange kein Grund, NICHT dafür zu sorgen, persönliche Daten so gut wie nur möglich zu schützen und sich nicht nur auf das bereits von anderen kritisierte “Security by obscurity” zu verlassen.
Denn entsprechende No-Caching-Anweisungen sind kein Hexenwerk und sollten gerade bei Diensten, die persönliche Daten enthalten, eine Selbstverständlichkeit sein.
Mmmm sehe grad dass das VZ die Bilder ziemlich runterskaliert hat :/, den Artikel unlesbar macht .. hehe fast ironisch …
mm hat jemand mal ne seite wo ich biler hochladen kann ohne dass sie resized werden?`bin normalerweise nicht so groß im Bildersharen, daher hab ich a keine zu hand ….
http://217.188.35.147/albums/2006-12/07/Vfk2LB/DDz01YT-26697766.jpg
http://217.188.35.147/albums/2006-12/07/Vfk2LB/xRz01YT-40152617.jpg
Direktlinks zu den Bildern von TwiStEr
@118: imageshack.us
Ok .. Dons sry für den Extrapost … hier also er Artiekl aus der WELT-kompakt, enjoy:
http://static.flickr.com/116/316369223_4a59e78b64_b_d.jpg
http://static.flickr.com/103/316369226_eb14a6f8fa_b_d.jpg
ich versuche das mal zu erfassen, das System erkennt durchaus, dass du eben nicht Susi bist, zeigt dir aber Susis weg an. Es geht also nicht um Dateien im Cache, sondern um Dinge, die StudiVZ an dich, obwohl du das Böse (TM) bist, liefert, die eigentlich für Susi bestimmt sind?
Also mit anderen Worten (Beispiel Mail da oben) wenn ich die URL-Struktur kenne, komme ich überall hin?
Oder verstehe ich das immer noch komplett falsch? (Ich hol mir da keinen Login)
@122: Du brauchst ja keinen eigenen.
http://www.bugmenot.com/view/studivz.net
Richtig, Dave-Kay. Sie schreiben den NAMEN DES BÖSEN dahin, wo vorhin Susis Name im Mailformular stand.
Der Rest des Gedankengangens dürfte für Securityleute vielleicht nicht ganz uninteressant. Und gibt, wenn sie es nicht bald wieder abschalten, vielleicht Anlass zu einem neuen Beitrag in der Blogbar, tun sich da doch ungeahnte Möglichkeiten auf. Sagt einer, der davon mehr versteht als ich.
@122: Da sind wir schon 2! Ich lock mich auch nich in die rein!
@ alle GMX Kritiker. NEIN, es geht nicht! Ich hab das mit 2 Accounts probiert, und bekomme – wie gewohnt – folgende Meldung:
ABER die schnelle Vor- und Zurückfunktion, die Firefox seit 1.5 hat ( http://www.golem.de/0505/37902.html ) hält besuchte Seiten im gerenderten Zustand im RAM. Beim Anklicken von Links oder dem Reload der Seite ist dann aber Feierabend. Geht das auch bei Eurem Onlinebanking? Oh nein, das ganze Internet ist plötzlich unsicher.
@ Don. So wie es aussieht, hat das von Dir vorgestellte “Phänomen” nix mit vorgerenderten Seiten zu tun, da ja in den Feldern der Name des aktuell eingeloggten Users erscheint. Stell das mal bitte noch besser heraus.
Mal abgesehen von StudiVZ. Ich bin in den Achtzigern groß geworden. Ich weiß, was Datenschutz ist. Ich bin besonders vorsichtig. Ich bin am Compi eher überdurchschnittlich informiert und bemühe mich um Schutz meiner Daten.
Aber von sowas hab ich noch nie gehört.
Ich will auch mal drauf aufmerksam machen, dass man nicht nur in professionell eingerichteter Umgebung surft. Ich zum Beispiel teile mir bei meinem Nebenjob den Computer in einem Laden, wo sie drei Tage gebraucht haben, um mir überhaupt ein Passwort einzurichten. Da hat noch nie einer was davon gehört, dass man einen Browser auf “Privat” einstellen soll. Ich werd mich jetzt mal drum kümmern.
Aber ich betone: Unter den Nichttechnikern bin ich eher den Powerusern zuzurechnen und halte viel von Datenschutz.
Deshalb: Danke Don, dass Du dieses super-wichtige Thema am köcheln hälst und immer mehr Leute für immer feinere Einzelheiten sensibilisierst!
Langsam werde ich ein wenig ungemütlich. Wer Unister und andere angreifen will, soll das machen, aber bitte
– nicht in meinen Kommentaren
– und nicht mit Hinweisen auf konkrete Punkte zum Ansetzen von Injections.
Wo sind all die Leute eigentlich wenn es um Fehler bei Studivz geht? Plötzlich wimmelt es ja nur von Sicherheitsexperten, die Fehler und sonstiges auf anderen Portalen finden!!
Hier wollen einige nicht die Sicherheitslücke verstehen stimmts? Loggt euch mal AUS bei GMX, WEB.de oder sonst was, und schaut ob ihr als ein anderer User auf ähnliche Daten kommt?
Auch ein Danke von mir Don.
#112
Das ist wirklich krass! Da kann man sich durch die ganzen Profile klicken!
Ein Scheunentor ist ein Mauseloch dagegen!
Sauberes Sessionhandling, PREG Pattern ( http://www.theserverside.com/tt/articles/article.tss?l=RedirectAfterPost ), und das senden der richtigen Status-Codes helfen. Auch bei diesem Problem.
na ja, also unterm Strich nichts Neues, eigentlich. Es existiert kein Sicherheitssystem und egal auf welche Lücke man auch immer stößt, irgendwie ist der Hintergrund beinahe immer, dass kein Sicherheitssystem existiert, bzw. das gedachte Sicherheitssystem auf Unkenntnis der URL beruht.
Mit anderen Worten, JEDE Information ist frei verfügbar, wenn ich die URL kenne/erahnen kann. Ungeahnte Möglichkeiten, ja.
@131/ulf:
Schöner Artikel – klingt nach einer sehr sauberen Lösung für die meisten Session-/Formular-Probleme.
Desweiteren frage ich mich gerade, warum man an einem öffentlichen Rechner überhaupt den Verlauf speichert und nicht das Löschen von Sitzungsdaten beim Beenden aktiviert.
Was allerdings nichts daran ändert, dass es nicht sehr schlau ist, Sessions nicht explizit beim Ausloggen zu beenden.
Bin ja mal gespannt, wann StudiZV wieder offline geht und im Blog irgendwas von “Angriff” gefaselt wird :D
Nur kurz zum Thema Man-In-The-Middle Attacke:
Dazu muss man sich gar nicht lange den Kopf machen, wie man die Daten abgreift.Man braucht eigentlich nur ein Laptop oder PDA mit W-Lan.
An jedem Uni-Campus hängen ja zig Leute mit ihren Laptops im StudiVZ.
Und da StudiVZ sich anscheinend keinen SSL-Zertifikat für 7 im Monat leisten kann, kann man die ganzen Email/Passwort-Kombinationen einfach aus der Luft abgreifen. Automatisch. Einfach im Vorbeigehen.
So viel zur Sicherheit beim StudiVZ.
Praktisch einfach vollkommen egal. An jeder Uni gibt es wohl getrennte, einzelne Benutzerkonten… und wer vom PC weggeht und sich da nicht ausloggt ist selber schuld und wird nachdem er das ein paar mal gemacht hat, nach den meisten Benutzerordnungen, gesperrt.
Und im Internetcafe sollte man ja wohl immer History und Cache löschen? Wirklich trivial…
@Medved
Fast jede Uni bietet VPN-Clients an. Bei manchen ist es sogar unmöglich ohne Verschlüsselung/Client-Software W-Lan zu benutzen.
Ja, stimmt schon das habe ich vergessen zu erwähnen ;) aber es gibt auch Ausnahmen. Und ausserdem viele surfen von zu Hause aus und haben nicht einmal WEP an. Ich wohne z.B. in einer Gegend wo viele Studenten leben und kann dies recht oft beobachten.
Ja, ich weiss, selber schuld und so…
@ Don:
Du hast bei einigen bildern vergessen die Namen an allen sichtbaren stellen zu schwärzen. Mach das mal. Von wegen Datenschutz.
@112,130 Hier bringt ihr etwas durcheinander. Bei nurstudenten.de sind die Profile der Öffentlichkeit zugänglich. Jeder User hat à la Myspace eine eigene URL http://www.nurstudenten.de/NICKNAME.
Auch wenn man nicht auf der Seite registriert ist, kann man also Profile (die übrigens mit css personalisiert werden können) aufrufen. Das ist also so beabsichtigt. Die Kontaktdaten bzw. Adressdaten sind allerdings nicht öffentlich einsehbar.
Die vermeintliche Verbesserung ist nur kosmetischer Natur. Zwar bekomme ich jetzt eine Fehlermeldung beim “Zurück”, kann aber weiterhin die URLs in der History abrufen und erfahre alles über Susi, was Don per Zurück-Knopf rausbekam.
seb: Das sind keine echten Charaktere. Die haben keinen richtigen Datenschutz.
@143: Mit dem Argument haben aber kaum noch StudiVZ-User Datenschutzrechte :D Von denen haben die wenigsten Charakter und sind echte Charaktere.
@Harm
Also ich konnte auch die Kontaktdaten einsehen…
Mal ernsthaft Don – das wovon du redest (viele Leute benutzen denselben PC ohne unterschiedliche Benutzerkonten) ist wirklich nicht der Normalfall.
Das gibts so gut wie garnicht. Und wenn doch, dann liegt es wirklich in der Verantwortung der User alle Fenster zu schließen, sodass (in der Regel) sowohl History, als auch Cache gelöscht werden.
Ohne History gibts keine “Zurück”-Buttons, ohne Cache keine gespeicherten Bilder.
Diese Sicherheitslücke ist ein bisschen an den Haaren herbeigezogen.
Für meinen Geschmack ist es nicht an den Haaren herbeigezogen, sondern schlicht und einfach unsauber ‘gebastelt’. Basteln tut man allenfalls mit den Kindern im Kindergarten. Fakt ist, das gesamte Backend ist mit der heissen Nadel gestrickt.
Ich habe sehr viel Erfahrung mit einem Uniradio. Da laufen alle Rechner. Immer. Und wenn einer mal eine halbe Stunde weg ist, macht der nicht sofort den Browser zu. So sind die Leute. Ãœbrigens bin ich selbst auch nur draufgekommen, weil ich den Browser auch meistens auf lasse.
Es ist schon klar: Es geht nicht immer und überall. Aber es gibt kritische Orte im universitären Raum, an denen das möglich und StudiVZ entsprechend verbreitet ist. Da kommen also zwei Probleme zusammen, die grundsätzliche Machbarkeit und die Chance, es zu tun. Und Datenschutz bedeutet,. Daten zu schützen und nicht darauf zu hoffen, dass schon nichts passiert.
@Dennis
Also die Postleitzahl und den Ort wo man herkommt (Heimat, Heimat-PLZ), kann man einsehen. Aber nicht die aktuelle Adresse oder Telefonnummer.
Also mal ernsthaft angenommen, man ist zu Hause und en Bekannter kommt vorbei, und fragt einen ob er mal kurz ins StudiVZ schauen kann. Man mledet sich ab und denkt sich nichts böses, geht was essen macht sonstwas und ne viertelstunde später stellt sich raus dass besagter Bekannter auf einmal weiß wen man so alles geruschelt hat etc.
Das der jenige das nicht unbedingt alles wissen soll, es aber schon rausfinden wenn er nur ein paar mal öfter die zurück Taste an der Maus bedient als eigentlich nötig ist irgendwie erschreckend.
@Don: Aber die Argumentation ist doch unsinnig – selbst wenn man serverseitig dafür sorgen würde, dass die Bilder nicht mehr abgerufen werden können und dass die Seiten vom anderen Account über die History nicht einsehbar sind – das alles ändert nichts an der Tatsache, dass
1. die Bilder der besuchten Seiten weiterhin im Cache verfügbar sind
2. die History eindeutig Auskunft über die besuchten Seiten gibt, auch wenn sie nicht mehr aufrufbar sind (und zwar Auskunft in gleichem Umfang wie die verkrüppelten Seiten auf Deinen Screenshots oben).
@Martin(151)
Natürlich ist Dons Beispiel etwas konstruiert – über die History wäre ein entsprechender Zugriff genauso möglich, fällt allerdings dann in den Bereich der Sicherheit, für welche der Nutzer selbst verantwortlich ist.
Kernaussage des Beispiels von Don ist für mich allerdings vielmehr, dass das VZ schon elementarste Sicherheitsvorkehrungen nicht bieten kann, und einfach an vielen Stellen kein Konzept besitzt.
Man kann somit mehr als nur Mutmaßen, dass Sicherheit und saubere Programmierung bei den VZ Leuten nur geringe Priorität hatten. Zielsetzung war von Anfang an möglichst schnelles Wachstum, wobei Userbelange höchst nachrangig waren. Gutes Management ist dies nicht, sondern ein übler Nachgeschmack bleibt bei diesen “Webpreneuren”.
Das Motto des VZ’s scheint mir stark in Richtung “Datengrüscheln” zu gehen:
zu grüscheln:
http://www.rzuser.uni-heidelberg.de/~cd2/drw/e/gr/usch/gruscheln.htm
Martin: Wenn Du bei einem Auto bremsen einbaust, und jemand einen Unfall baut – sein Problem.
Wenn Du bei einem Auto keine Bremsen einbaust, behauptest, Du hättest welche eingebaut, und dann kracht es – Dein Problem.
Andere schaffen es ja auch. StudiVZ schafft es nicht. Und wenn Du denkst, das hier sei konstruiert, hast Du noch nie Studenten Einführungen in Computernutzung gegeben.
Auch wenn hier in den letzten 4 Wochen viel berechtigte Kritik zu lesen war, so halte ich den aktuellen Pseudo-Datenschutz-GAU für Quatsch.
Genauso gut könntest du, Don, StudiVZ dafür verantwortlich machen, wenn der Stalker Susi Sorglos beim VZ-nutzen beobachtet. Da können die auch nicht viel gegen machen. Der Browser fordert nunmal Seiten an und speichert diese lokal zwischen. Wenn der diese dann nachträglich wieder verfügbar macht, hat das VZ damit nichts zu tun. Selbst wenn die sonstwas für Cache-verhindernde Mechanismen installieren, heißt das nicht automatisch, dass sich jeder Browser daran hält.
Ok – aber warum sollte man Bremsen einbauen, wenn sich das Auto sowieso auf einer Eisfläche bewegt?
Dein Argumentationspunkt ist folgender: Es ist viel einfacher den “Zurück”-Button zu benutzen, als sich manuell durch die History zu wühlen.
Da geb ich Dir in gewissem Maße recht. Allerdings ändert das nichts an der Tatsache, dass es keine Sicherheitslücke von StudiVZ ist. Die Sicherheitslücke ist die nicht gelöschte History.
Und Du meinst, das sollte verschleiert werden?
@152/dangermouse:
Womit mal wieder bewiesen wäre, dass die Schweiz ein tolles und nützliches Land ist ;)
@martin (155)
Deine Argumentation ist für mich reichlich absurd – “wieso Bremsen einbauen wenn ich sowieso weiss dass die Fahrer Idioten sind?”
Technisch einwandfrei und Stand der Technik wäre, dass die Session beendet ist, wenn der User sich ausloggt. Ganz einfach. Dies ist anscheinend nicht der Fall.
So. Jetzt liest Du bitte nochmal die obigen Texte und Kommentare GENAU durch. Danach denkst Du drüber nach, und dann kannst Du Dir überlegen, ob Du dabei bleibst. Und bedenke: StudiVZ hat da inzwischen was gemacht – warum wohl, wenn angeblich alles ok ist?
Wenn Du dann immer noch auf verlorenem Posten Schmarrn erzählen willst, such Dir ein eigenes Blog. Dann kannst Du ja erklären, warum es bei StudiVZ geht, und bei Gmail oder Immobilienscout24 zum Beispiel nicht
@ember(152)
..na umsonst soll Ehssan Dariani ja nicht in St. Gallen studiert haben. Dabei kam ihm wohl das abgrüscheln der Studentenschaft in den Sinne. Irgendwie doch paradox: Durch’s fröhliche gruscheln grüschelt studiVZ unredlich mit anvertrauten Daten…
Herzlichen Glückwunsch Don zum erflogreichen Kopieren von “Bild”-Methoden.
Sicherheitslücke hin oder her, ohne deine erfunde Analsex-Gruppe wäre dieser Beitrag genuso langweilig wie deine anderen.
Bei aller berechtigten Kritik um die nach wie vor bestehenden Sicherheitsmängel, die letzten Tage war das studiVZ ein riesen Spaß. Nein nicht das echte, sondern der von den Betreibern eröffnete Testserver. Von uns Teilnehmern schlicht anarchoVZ genannt. Es war ‘ne herrlich anarchische Zeit und keiner von uns vermisst mehr das real studiVZ. Es wirkt jetzt – neben aller Mängel – vor allem sehr bieder und fad. Hoffentlich bleibt uns unser anarchoVZ noch ein weilchen als Paralellwelt erhalten. Was man von den studiVZ dort so denkt, sieht man in Gruppen wie “Ehssan Dariani hat nen kleinen Penis” oder “Ehssan Dariani spielt an sich rum, statt am StudiVZ”.
Leider wurden wir von den studiVZ-Machern auch dort ständig überwacht, beobachtet und bespitzelt. Besonders der fiktive user “Stephan Siebert” erwies sich als kurioser stasiVZ-Spitzel, der in jeder aber wirklich jeder der Testerserver-Gruppen beigetreten war, sich mit allen usern “freundschaftlich verbindete, aber niemals nie eine Nachricht, einen Beitrag oder etwas auf den Pinnwänden hinterließ.
Nichtsdestotrotz – es lebe das anarchoVZ – auch wenn das von den Machern sicherlich SO nicht beabsichtigt war!!!
noch existiert es:
http://195.71.2.182/
OT: tut mir leid, aber die Performance eurer seite is für’n Popo.
wie oft mir heute hier schon mitgeteilt wurde, dass die SQL-Connection nicht established war…
@Martin, 151, 155, 163
Du hast es ja eigentlich selbst gesagt: Wären die Seiten nicht einsehbar, dann bliebe ausschließlich die URL, um zu erraten, auf welchen Seiten die Person war (da auf dem Bildschirm dann ja immer nur ein ‘Du bist nicht eingelogt.’ bzw. ‘Zugriff nicht erlaubt’ o.ä. erschiene.)
Das war – bis vor Dons Post – aber nicht so.
Alles in allem muss ich schon sagen – studiVZ kann sich wirklich bedanken. Die bekommen hier umsonst bzw. fürn Appel unn Ein (Danke, Jörg-Olaf), einen universalen Sicherheitscheck ihres Systems geliefert.
Aber da – freundlich gesprochen – die Initiative zum Lösen dieser ganzen Probleme einfach nicht von ihnen selbst ausging, sind sie wirklich selbst schuld, dass ihnen das jetzt als PR-Gau um die Ohren fliegt. Sie eignen sie einfach _zu_ gut als Beispielfall für grundsätzliche Probleme eines falsch verstandenen Web 2.0.
Und Dons Artikel ist schon absolut gerechtfertigt: Bevor ich als Unternehmen mit aggressivem Marketing europaweit expandiere, sollte das Log-Out in meinem System schon wenigstens ein wirkliches Log-Out sein und kein halbherziger ‘quick and dirty hack’.
@Martin(163)
mea culpa maxima. Hab’s ausprobiert..ja hier liegt kein Riesendatenleck vor. Da hast du Recht. Taucht beim VZ aber nach dem abmelden eine Meldung auf, dass man den Browser schließen sollte?
Addendum und @all whitehats
Ich bin mir allerdings sicher dass deutlich krassere Lecks noch voll zur Verfügung stehen…;-)
Dangermouse: Sie haben es vor ein paar Stunden gefixed.
Und Typen, die glauben, hier Sachen sagen können wie “Du wirst inzwischen auch zugeben”, unterhalten sich pronto mit Dildowerbung und Viagraspam bei Spam Karma.
Darf ich mich kurz selbst zitieren? ;)
Hmpf… Zitieren will gelernt sein… Zweiter Absatz ist kein Zitat mehr :p
http://rebellmarkt.blogger.de/static/antville/rebellmarkt/images/gatjagend.jpg
8. screenshot von oben, ganz rechts unten steht in rot der Name. Zusammen mit der Uni und dem Bild konnte ich sie auffinden: Ihre ID lautet 5fk***. Besser mal ändern, wenn es die wirklich gibt.
Name schwärzen wäre wohl net schlecht.
Sonst könnte das für dich ein Problem geben.
@167/168 / Matthias:
Prinzipiell ist gegen die Verwendung von GET nicht wirklich etwas einzuwenden (o.k. das Beitreten in Gruppen und Nachrichten über GET sind dann doch nicht wirklich schlau gelöst mit GET) – nur wäre es vielleicht irgendwie schlau, dort kleine Klartext-Angaben reinzuschreiben und außerdem bei jedem(!) Seitenabruf die gültige SessionID zu prüfen (oder wie oben angemerkt wurde, besser mit session_regenerate_id() eine neue zu erzeugen).
@christian (169): Sagt Dir der Begriff Fake-Account etwas?
Ãœbrigens scheint StudiVZ die Auszeit tatsächlich produktiv genutzt zu haben, nämlich zum Löschen von eben Fake-Accounts. Wahrscheinlich bieten sie jetzt facebook “nur noch 700.000, aber qualitativ super!” Records an.
Loggt euch mal mit Opera bei web.de ein und schaut, was passiert: Mit Opera kann man trotz erfolgreichem Logout-Vorgang immer noch im BrowserCache rumwühlen. das ist ebenso ein Skandal!
Neeiiiiin. Hans, das ist was gaaaaaaaanz annäräs. Das güldet hier nich.
Damit würdest du doch den Blog entkräften!
StudiVZ: Und wieder der Griff daneben …
So langsam solltet ihr den Laden wirklich dicht machen. Es gibt wieder eine neue Lücke:Superfrischer Privacy Gau bei StudiVZ. Ihr braucht mehr als nur fünf Tage Pause. Ihr braucht ein komplettes Redesign eurer Software.
Ich werd mir jetzt nicht die Mühe machen zu erklären was genau es mit dieser “Sicherheitslücke” auf sich hat und warum diese bei GMail nicht auftritt. Die Kommentare hier zeigen sehr deutlich, dass die meisten Menschen lieber bei einer einmal gefassten Meinung bleiben, als die Wahrheit zu erfahren.
Wer es gerne wissen möchte, dem empfehle ich, sich in ner ruhigen Minute mit jemand der etwas Ahnung vom Thema und keine emotionale Vorbelastung hat die dargestellten Schritte durchzugehen und dann sehr genau zu
überlegen wo die Gründe wofür sind.
Für alle anderen habe ich noch ein haarsträubendes Sicherheitsloch:
Alice und Bob sitzen in einem Raum und surfen bei StudiVZ. Jeder von beiden ist mit seinem eigenen Account auf seinem eigenen Rechner eingeloggt. Wenn Alice auf eine Link klickt ruft sie die URL durch den Raum Bob zu, der sie bei sich eingibt. Nun kann Bob sogar die Seiten sehen, auf denen Alice gerade in diesem Moment surft, nicht nur die, auf denen sie früher mal war. Außer natürlich die Seiten, auf die er keinen Zugriff hat, dann bekommt er ein “Du bist nicht berechtigt, dieses Fotoalbum zu sehen”. Eine katastrophale Sicherheitslücke, die StudiVZ unbedingt beheben muss. Oder Moment Mal… das ist die selbe “Lücke” und das ganz ohne Browser Cache oder Session Cookies.
Und für die Allerschlausten: keiner der Links von denen hier die Rede war übergibt eine SID per GET. Also nicht dass mir nochmal einer mit Sessions kommt. Das Problem hat mit Sessions null zu tun!
ich bin fassungslos.
@ember #170
Ob GET oder POST ist vollkommen egal. Klar ist es leichter in einem URL mal schnell ein paar Key-Value-Pairs zu tauschen, als einen Socket zu öffnen. Aber in letzter Konsequenz macht es keinen Unterschied(für einen geübten Programmierer sind das evtl. 1 Minute).
Ob man POST oder GET nimmt sollte nur eine Frage des “was will ich machen” sein(Fileupload, viel Text bewegen) niemals ein Sicherheitsgedanke. Denn da macht es _keinen_ Unterschied.
@alex: “Ich werd mir jetzt nicht die Mühe machen zu erklären was genau es mit dieser Sicherheitslücke auf sich hat”
Warum tust Du es dann, und dann auch noch flasch?
@alex #174
>..Das Problem hat mit Sessions null zu tun!
Aber sicher doch. Wo, wenn nicht in einer Session, wird denn sonst die Authentifizierung/Autorisierung gespeichert/weitergegeben?
Das die nicht in der URL auftaucht, liegt wahrscheinlich daran, das session.use_cookies in der php.ini auf 1 steht. Habs nicht getestet, aber kann ja mal jemand versuchen mit deaktivierten Keksen im SVZ zu agieren. Dann dürfte(Fallback) die SID in der URL stehen.
falls wir uns misverstanden haben.
Das Alice Bob Beispiel beweist dass das Session Copokie keine Rolle spielen kann, das mit GET ist eine Ergänzung, um den gedanken auch gleich auszuschließen. Sucht euch eine Alice oder einen Bob und probiert es aus, aber redet nicht von Dingen, die oihr offensichtlich nicht versteht.
Haben die jetzt das Problem gefixed, oder besteht es noch, wie in den letzten Posts geschildert?
@176/SteBu:
O.k. Das kam falsch an – natürlich bietet POST keine tatsächliche Sicherheit, aber Parameter in URLs laden auch den weniger Begabten Sicherheits-Analysten zum Herumspielen ein.
Hat bestimmt schon wer geschrieben, aber ich mag nicht alles lesen, die technische Unkenntnis da oben reicht mir, um hier mal ein bisschen was klarstellen zu müssen.
Wie schon richtig angemerkt wurde, ist das nichts, was man StudiVZ anhängen kann. Dass man einige Daten per URL übergibt, ist gängige Praxis. Selbst wenn alles in Formulare als versteckte Felder gepackt werden würde, wäre der Effekt der gleiche, man müsste nur immer mit OK bestätigen, dass man die Formulardaten noch mal senden möchte. Das ist genau das, was mit der letzten Gruschel-Aktion von Susi passiert, also das, was im Beispiel als erstes kommt (nach erstem Mal Zurück-Button).
Mit der SessionID hat das nichts zu tun. Nachdem sich Susi ausgeloggt hat, ist ihre SessionID als ungültig markiert. Aus diesem Grund würde man dann auch immer auf die Startseite kommen, wenn man sich nicht neu eingeloggt hat und irgendeine StudiVZ-URL aufruft. Nun ist es im Beispiel aber so, dass man sich mit seinen eigenen Nutzerdaten einloggt. Damit wird eine neue gültige SessionID vergeben, die zu dem dann eingeloggten Nutzer gehört. Aufgrund der History-Funktion des Browsers kann man zurück gehen. Alle Aktionen, die Susi ausgeführt hat, werden dann als der Nutzer ausgeführt, als der man eingeloggt ist. Und weil eben jede Seite eindeutig durch die URL und die evtl. per Formular an diese URL geschickten Daten identifiziert ist, kommt man auch auf jede Seite, auf der Susi war. Aber eben nicht auf solche, auf die man keinen Zugriff hat, weil die aktuelle SessionID mit dem eigenen Profil verknüpft ist.
Mir ist keine Möglichkeit bekannt, wie man das einfach verhindern könnte. Bestimmt geht es irgendwie, aber ist mit Sicherheit mit enormem Aufwand verbunden. Eine erste Idee war, die SessionID mit in die URL zu packen und nicht per Cookie zu übergeben. Das würde das einfache Benutzen des Zurück-Buttons verhindern. Aber wirklich sicherer ist das auch nicht, weil ja in der URL einfach die SessionID durch die eigene gültige ersetzt werden kann. Eine weitere Möglichkeit wäre, den Referer zu überprüfen, aber auch das ist nichts, was nicht umgangen werden könnte.
Wie auch schon weiter oben angemerkt wurde, könnte man auch herausfinden, dass Susi bei Google nach irgendwelchen Bildchen gesucht hat oder was auch immer. Durch die Browser-History lässt sich natürlich ihr gesamtes Verhalten zurückverfolgen. Dagegen hilft, die Browser-History zu löschen, wenn man fertig ist.
Den einzigen Tipp, den ich StudiVZ geben würde, wäre einen Hinweis nach dem Ausloggen anzuzeigen, dass man die History löschen sollte, wenn man sich an einem öffentlichen Computer befindet.
Gruß,
Alex
183 ist von einem anderen Alex, als die andere Kommentare. Nur falls es Verwunderung gibt. Und er hat Recht, die “Sicherheitslücke” hat nichts im Sessions zu tun.
Man braucht keine History löschen o.ä.
Ich sehe das Problem mit den nicht vollständig zurück gesetzten Sessions eher hier:
Man wird ironischerweise selbst als Absender für die Mail von Susi sichtbar, erkennt aber, an wen die Mailvon Susi ging
Klar ist man in seinem Account am Mail schreiben, jedoch sieht man den letzten Empfänger, den Susi anmailte. Und das ist falsch. Das wird also in einer Session transportiert(nehme ich an) und nicht vollständig resettet.
>…den Referer zu überprüfen
Lustig, was soll das denn? Der ist leichter zu fälschen als alles andere. Oder wird komplett unterdrückt(NIS macht das z.B.).
Alex/Alex: So wie ihr es schildert konnte ich es heute Mittag auch nachvollziehen. Bzw. nur noch.
Was bleibt ist das Verhalten des serverseitigen Caches, das aber evtl. kurz nach dem Erscheinen des Artikels hier an der Blogbar geändert wurde. Zumindest soweit, wie/wenn sich die Informationen hier im Thread sinnvoll zusammenbringen lassen.
Natürlich könnte man auch eine Session auf die User-IP binden. Wenn sich die IP ändert -> Session nicht annehmen.
@185/SteBu:
So wie es mir nach nochmaligem Nachdenken scheint, hat Alex recht – die Session ist dabei nicht von Bedeutung, der Empfänger steht in der URL (das halte ich allerdings für unklug, auch wenn StudiVZ nicht das einzige Portal ist, dass es so macht).
Eine Alternative wäre, mit ein bisschen Javascript den angewählten Empfänger, zusätzlich zum Anzeigefeld, in einem versteckten Div-Block zu speichern und die Nachricht per AJAX an den Server zu schicken. Allerdings muss ich Alex recht geben: Die Frage ist, ob das tatsächlich notwendig ist (schick’ fänd ich’s auf jeden Fall ;)) – ein Hinweis beim Ausloggen wäre allerdings wirklich gut.
@Alex: das glaubt uns kein Mensch…
@185 SteBu:
Schau dir bitte den Screen genau an bevor du den Mund auf machst. In der URL(!) steht [to_user_ids]=”geschwärzte ids here” um das zu rekonstruieren braucht man definitiv keine Sessions.
@190 Alex: Na es wird doch langsam, ein paar haben Einsicht. :) Ich habe jetzt doch alles gelesen, bei manchen Kommentaren musste ich fast weinen. Den Browser anweisen, nichts zu cachen … hm … oder SSL verwenden, dann gibt’s kein Problem. Hm … Und bei GMail geht’s nicht, weil die SSL verwenden. Seeehr interessante Theorie. Gegen Ende hin ist es glücklicherweise deutlich besser geworden.
@189 ember: Vollkommen richtig, was Du schreibst. Und weil GMail massiv mit AJAX-mäßigen Methoden arbeitet, geht’s bei GMail auch nicht so einfach. Nachteil an so was ist dann aber auch, dass auch der berechtigte Nutzer selbst mit dem Zurück-Button nicht mehr so viel anfangen kann. Es gibt AJAX-Anwendungen, die einem beim Klick auf “Zurück” auch freundlich darauf hinweisen, dass man den Knopf besser nicht benutzen sollte.
Eine sichere Methode wäre, alle Parameter, egal ob POST oder GET, verschlüsselt zu übertragen. Dazu könnte man ein Public-Key-Verfahren einsetzen, bei dem der Server beim Login eine Schlüsselpaar generiert und dieses an die SessionID bindet. Der Client bekommt die SessionID und den Public Key und verschlüsselt damit alle Parameter, lediglich die SessionID wird unverschlüsselt übertragen. Mittels der SessionID kann dann der Server den passenden Private Key raussuchen und damit die Parameter entschlüsseln. Beim Login werden die SessionID und das Schlüsselpaar gelöscht. Damit wären URLs nach dem Logout garantiert unbrauchbar und auch nicht mehr herausfinden, was mit dieser URL aufgerufen wurde, weil dazu die Kenntnis des Private Keys nötig ist.
Also wie ich schon geschrieben habe — machbar ist (fast) alles. Aber der Aufwand lohnt sich in meinen Augen in diesem Fall überhaupt nicht. Denn alles, was der Benutzer tun muss, ist die verdammte History zu löschen.
Gruß,
Alex
Ich vermute einfach, die Situation für Don ist auch inzwischen etwas ins Ungünstige gekippt. Nachdem er anfangs (m.E. ganz legitim) Sicherheitslücken im System und diverse Fehlverhalten der StudiVZ-Gründer angeprangert hat, wartet jetzt quasi jeder auf den vernichtenden Stoß.
Der kommt aber wahrscheinlich so gar nicht, es sei denn größere Presseorgane nehmen sich der Sache noch einmal an. Fakt ist: Die Leute, die hier regelmäßig mitlesen, stehen SocialNetworks sowieso meist schon kritisch gegenüber und tragen sich nicht unbedingt unter ihrem richtigen Namen bei den Anal-Penetrierern ein – diejenigen aber, die StudiVZ mögen und sich dort regelmäßig tummeln (laut Aussage eines Freundes, der dort angemeldet ist, hauptsächlich jüngere Semester), kümmert es einfach nicht besonders, ob nun Sicherheitslücken da sind oder nicht. Sie werden weiter die Geschichte vom bösen Raubritter Don, der das arme StudiVZ hackt, glauben und fleißig ihre Daten eingeben.
@193: Ich kann das mit den jüngeren Semestern nicht bestätigen. Die Uni-Gruppe, die ich tutoriere, sind im 7. bis 9. Semester und da Stammkunden…auch in diesen Semestern ist Datenschutz “out”.
@70 das wäre genau richtig.
@194 / Nachdenkender:
Ich glaube, er ist spätestens seit BigBrother nie wirklich “in” gewesen. Was sich ja auch an der recht “zahnlosen” Position der Datenschutz-Beauftragten in unserem Staat zeigt. Das Bewusstsein, mit dem Internet einen öffentlichen Raum zu betreten hat sich bei vielen einfach noch nicht manifestiert.
Die studiVZ Chroniken
Dies soll ein Versuch sein, die Geschehnisse um das StudiVZ nochmal chronologisch zusammenzufassen. So etwas wurde schon von Michael hier und von Karsten hier (auf englisch) getan. Ich versuche das aber noch etwas ausfÃhrlicher (und auf deutsch) zu sc…
@ember: Nun, dann lobe ich mir, “Freak” zu sein. Wenigstens haben bei mir Personaler, Versicherungen und Polizei noch klassische Arbeit zu verrichten und können nicht einfach googlen. Eine aussterbende Rasse…
Also, für die funktionalen Analphabeten, die keine Kommentare lesen können oder wollen: Nach gut 3 Stunden und einer Hilfeleistung hat StudiVZ soweit rumgeschraubt, dass es nicht mehr ging. Anders gesagt: Da hat jemand ein Problem begriffen, was manchem Textablaicher mit falscher Email und Scheinnamen hier nicht klar ist.
Was den “finalen Stoss” angeht: Das Wirtschaftsleben ist langsamer. Und bei Startups funktioniert das nicht so, wie bei normalen Firmen, die auf Umsatz und Gewinn gleiten. StudiVZ verbrennt Geld. Durch die Geschichte sind sie 2 Monate hinter Plan, kostenmässig erheblich über der Erwartung, und PR-mässig auf dem Niveau des Fussabstreifers. Ja, sie haben Nutzer. Aber das sind momantan nur Kosten. Und es wird eine Weile dauern, bis sie tragfähige Erlösquellen haben, wenn sich nicht Holtzbrinck weiterhin den Ruf ruinieren will und indirekt was reinsteckt, indem sie über Zeitungen querfinanzieren. Mit dem Ruf ist es sicher kein Spass, Kunden für Werbung zu finden – ausgenommen Pr0n-Heftchen, NS-Faksimile und Hackerbaukästen. Frisches Venture Capital wird mit den Leuten eher schwer zu bekommen sein. Lustigerweise habe ich die letzten Tage mit ein paar Leuten aus dem Umfeld des OpenBC-Börsengangs gesprochen, die machen die negative Presse zum Thema Social Software mitverantwortlich für den miesen Start von OpenBC.
@ Two famous Alex: “Und jetzt genug für heute, schönen Abend noch!”
Hoffe, das heisst, es kommt jetzt keine Nebelkerze mehr von “Euch”.
Der “Nachtrag” offenbart die Intention. Die schärfsten Kritiker der Elche… “ihr” wisst hoffentlich das Ende des Satzes. Wie man mit so vielen Buchstaben offenbaren kann, dass man nichts, garnix von den Artikeln und der innewohnenden Thematik hier verstanden hat, ist schon erstaunlich.
Irgendein Hansel behauptet, er wäre der Ober-Personaler, und “ihr” nehmt seine Pseudo-Argumentation auf, um euren Kleinkrieg gegen den Blogautor weiterzuführen. Dann heult ihr auf, wenn’s mal ‘n bisschen härter zugeht, als “ihr” das beim Gruscheln gewohnt seid. Dann verwechselt “ihr” Bloggen mit käuflicher journalistischen Arbeit. Als nächstes kommen 125 Absätze gegen Session-IDs, um die anderen Kommentatoren hier zu diffamieren…
Liebe Kiddies, wenn ihr meint, dass das alles nicht so schlimm ist, wie Don es darstellt, dann nennt bitte den Personalen, der das ebenso als unwichtig empfindet, beim Namen. Dann erklärt bitte, warum die Erklärung von StudiVZ, alle privaten Daten seien *sicher* gegen Missbrauch, so stehenbleiben kann. Dann erklärt aber auch den anderen StudiVZ-Usern, warum x Mios VC nur dazu dienen sollen, ein kleines Studentenprojekt im Netz aus reiner Nächstenliebe am Leben zu erhalten.
Und erklärt ihnen vielleicht, dass Cool-Sein und Paaarty keine Charaktereigenschaften sind, die soziale *Kompetenz* bedeuten. Sagt euch ein ehemaliger Manager mit Personalverantwortung.
@197/Nachdenkender:
Dann solltest Du Dir besser schnell ein passendes Weibchen suchen – ist ja quasi eine Frage der Arterhaltung ;)
“die machen die negative Presse zum Thema Social Software mitverantwortlich für den miesen Start von OpenBC.”
Freut mich zu lesen;-))
@197/Don:
Ich lasse mich gern eines besseren belehren, aber nach mehrmaligem Betrachten des ganzen sehe ich nicht mehr, wo Sessions im Spiel wären. Das schließt ja nicht aus, das trotzdem etwas gegen diese Möglichkeit, Benutzer auszuspähen unternommen wurde.
Nochmal zum Thema “finaler Stoß”: Mittelfristig hast Du sicher recht – abgesehen vom Verkauf der Benutzerdaten fiele mir auch nichts Sinnvolles ein, was man mit StudiVZ anstellen könnte. Allerdings erweckten bei mir die Kommentare einiger Teilnehmer in den letzten Tagen den Verdacht, es würde eher erwartet, dass Du das StudiVZ mit einem Blattschuss zur Strecke bringst und zwar noch vor Jahresende.
@Admin: Kannst du bitte anhand der IP verifizieren, dass “Alex_2” und ich wirklich zwei verschiedene Personen sind?
@198 Porschekiller:
Ich weiß nicht wie das bei “Alex_2” ist, bei mir gehts nicht “gruschlig” zu, und ich hab auch niemanden diffamiert. Ich hab auch keine Ahnung, warum StudiVZ tut, was es tut.
Ist auch völlig wurscht wie ich dem StudiVZ gegenüber stehe, was hier von sich gegeben wurde war vom technischen Standpunkt her absoluter Schwachsinn. Offensichtlich verstehst du nicht genug von der Materie, um dich auf einer sachlichen Ebene an der Diskussion zu beteiligen, oder wie darf ich deine persönlichen Anfeindungen deuten?
Ich verifiziere Alex. Bei Alex_2 taucht der Krempel von einem alten “Hans”-Troll auf. Browserproblem, was? ;)
Alex, glaub mir, ich kenne Porschekiller schon ziemlich lang, und ich weiss, dass der sich auskennt. Du weisst dagegen nicht, mit wem Du da sprichst.
Naja, immerhin sind die Spammer inzwischen klüger geworden: Immer noch gefälschte Mails, aber teilweise explizit Namen anderer Diskutanten, nicht mehr nur die Uni-IPs, und dann der Anfang “früher war das hier noch irgendwo gerechtfertigt aber inzwischen ist das hier BILD” statt nur “BILD” wie früher. Aber nicht mal die Beiträge lesen, sondern es wird einfach darauf los behauptet, und sich am Ende wundern sie sich, warum sie zusammen mit Potenzpillen beim Spam Karma landen.
@196 dito.
Völlig unerheblich, wie man sich hier die Dinge an den Kopf knallt: Es ist ein Problem des Betreibers und der Betreiber hat dafür zu sorgen, dass sowas nicht vorkommt! Den “Log out” Button klickt jeder, wenn ein anderer am selben Rechner sich einloggen will. Ein simples ausloggen auf die nicht SSL Seite und löschen eines “Session”-Cookies (only secure connection) beheben den Browser-Back auf die https Seite.
In dem Moment wo ein Betreiber mit persönlichen Daten seiner Benutzer arbeitet, hat dieser die verdammte Pflicht alles dafür zu tun, dass diese Daten nicht zugänglich sind. Und das ist wirklich nicht schwer. Der Aufwand ist marginal, wenn man auf Profis zurückgreifen kann – und zwar vom PM bis hin zum Prakti. Bei solchen Portalen spielen viele Disziplinen mit.
s**** wo ist mein cite hin?
Hier geht nur blockquote, sorry. Ich trage das nach.
Don:
Es mag sein, das porschekiller sich mit Datenschutz oder Human Ressources Management oder beidem und noch vielem mehr auskennt. Definitiv aber hat das Problem was Du in diesem Eintrag beschreibst nichts mit einer nicht gelöschten Session zu tun. Da du das immer noch zu glauben scheinst würde ich dich echt bitten, das mal mit einem Fachmann durchzugehen. Wenn der mich widerlegt solls auch gut sein.
Und egal wer Porschekiller ist, er muss mir nichts unterstellen, erst recht nicht wenn er das was ich sage anscheinend nicht sachlich beurteilen kann.
Gut. Nochmal in aller Ruhe: Oben ist ein gar nicht seltenes Szenario beschrieben. Ist beim Uniradio zigmal täglich möglich. Das geht zu Beginn des heutigen Tages auch mit Löschung des Cache, die Inhalte kommen dann eben wieder von StudiVZ. Das ist eine kinderleichte Methode, um an Daten ranzukommen.
Dann publiziert einer einen Vorschlag, wie man das ändern könnte. StudiVZ baut einen derartigen Programmschnipsel ein.
Wie das jetzt ein Softwaremensch sieht, ist mir ehrlich gesagt – egal. Es ging, es war möglich, andere führen vor, wie man es effektiv verhindert. Da gibt es also nachweislich Unterschiede, wie man dafür sorgt, dass ein normaler User aka Problem vor dem Bildschirm aka der um den es letztlich geht aka Nichtsoftwareprofi mit einem Knopfdruck sicher – oder unsicher – ist.
Gut? Gut.
Nun mal langsam. Was du in deinem Beitrag beschreibst wird auch jetzt noch funktionieren, das können die so ohne weiteres gar nicht geändert haben.
Log dich mit einem beliebigen Account ein und geh auf http://www.studivz.net/message.php?data%5Brefer%5D=profile&data%5Bto_user_ids%5D=BRV&data%5Bmode%5D=new
und schon schreibst du Ehssan eine nachricht mit dir als Absender. Und weil du den Link von mir hast weißt du dass ich ihm auch schonmal eine Nachricht geschieben hab.
Und wenn du den Link jetzt stattdessen in deiner Browser History gefunden hättest, dann wüsstest du dass jemand mit deinem Rechner an Ehssan geschrieben hat und wenn du weißt wer an deinem rechner war… lassen wir das, aber wenn die das Serverseitig ändern wollen wirds sicher mehr als nen Nachmittag brauchen.
@Alex:
Naja – was eventuell relativ einfach ginge (so als Idee), wäre die Parameterwerte mit der SessionsID als Stromchiffre zu verschlüsseln, sprich einfach XOR-en. Das wäre schnell und wenn man die Parameter jeweils mit einer entsprechenden Funktion ausliest (was ja eventuell sowieso schon geschah), ist das in ein paar Stunden machbar.
ember: das macht es höchstens schwerer.
Wenn Susi online ist, schaut sie sehr wahrscheinlich auf ihre eigene Seite. Dann geh ich einfach auf ihre seite, XOR den parameter mit meiner eigenen SID und hab den Klartext. Dann XORE ich ihren Parameter mit dem Klartext und habe ihre (abgelaufene!) SID. Damit xore ich dann alles was sie angestellt hat, und habe dessen Klartext. Den verschlüssel ich wieder mit meiner eigenen SID. Viola
@Alex:
Natürlich ist das nicht sicher – aber es wäre eine einfache Möglichkeit das System gegenüber unbedarfteren/weniger böswilligen Nutzern an öffentlichen PCs zu schützen. Ansonsten muss ich echte Verschlüsselung benutzen und das kostet mehr Rechenleistung, was bei dem ohnehin schon nicht übermäßig toll skalierenden StudiVZ vermutlich tödlich sein dürfte.
Also, ohne Fachchinesisch: Ab da ging es nicht mehr.
Ich muss dich enttäuschen, es geht immer noch.
Link klicken, ehssan schreiben, ausloggen, “back”, error, “forward”, einloggen, back, ehessan schreiben.
2 Stunden, das muss man dann auch mal respektieren, dass die gelernt haben!
Ist die Rechnung schon unterwegs?
@porschekiller: sicherlich sind session-ids im Spiel, eine vom Loadbalancer namens BIGipServerwww_studivz_net, der wohl dafür sorgt das Du nicht beim nächsten Aufruf auf einen anderen der knapp 100(? wurde hier irgendwo gesagt) Backendserver landet, der wiederum nichts von der zweiten Session-Id PHPSESSID weiss. anders kriegt man nur den Redirect auf die Startseite.
Jeder der angemeldet hat, hat diese beien Cookies.
Ich finde die Darstellung von Alex (oder wars Alex? ;-) schlüssig. Der Fehler vom VZ ist, das sie alles per GET machen, und damit Gruppen, Empfänger, Profile für jeden der die URLs abgreifen kann (ob nun per Session-History, Sniffing oder Proxy-Logfile) nachvollziehbar machen.
Das ist auch nachdem die VZler nun überall no-cache eingebaut haben nicht besser geworden. wenn ich also http://www.studivz.net/group.php?ids=5cBSY irgendwo herausfische, bekomme ich immer heraus um was es sich da handelt, und wenn ich http://www.studivz.net/message.php?data%5Bto_user_ids%5D=w8V&data%5Bmode%5D=new&… finde kann ich herausfinden was die Kommunikation war. Allerdings kriege ich immer nur das zu sehen, was mit meinen aktuellen Zugriffsrechten erlaubt ist.
zugegeben: das über ‘Back’-drücken zu machen, ist ne einfache Methode, aber wirklich nicht so sensationell. Wie alles bei StudiVZ ist es viel zu einfach Dinge herauszubekommen, bei denen der unbedarfte Benutzer denkt, es wäre sicher und nicht von jedem hergelaufenen herauszubekommen. Alles ist ungeschützt (kein ssl, keine Verschleierung der Zugriffe, keine Einschränkung der Sessionids auf Zeiten oder abrufende IPs, eben alles was alle anderen seit Erfindung von CGI teilweise unter Schmerzen gelernt haben, wird hier nochmals genüsslich durchlitten.)
Tipps zur Abhilfe (aufpassen StudiVZ): *erm* neee, habter nicht verdient.
Sach’ ma, Alex, bitte… Was ist so schwer daran, zu begreifen, dass es *hier explizit* um was Anderes geht, als auf SIDs rumzuhacken? Wenn es Dir den Bauch pinselt – ja, toll, da haben ‘n paar User sich auf Dein Spezialgebiet versteift und Du hast denen jetzt Kontra gepeilt. Toll.
Aber was ändert das am Original-Artikel? Was ist Deiner Meinung nach verwerflich an der Intention, den gemeinen StudiVZ-User mal drastisch aufzuklären, was so alles möglich ist/war trotz der Versicherung seitens StudiVZ, alles wäre sicher?
Parameter-Ãœbergabe per URL ist Müll, wenn man über Sicherheit diskutiert. Die ganze Struktur der StudiVZ-Site ist Müll, wenn man über Sicherheit diskutiert. StudiVZ diskutiert mit seinen Usern über Sicherheit und belügt diese im gleichen Moment. StudiVZ belügt seine Mitglieder, indem es behauptet, nach 5 Downtime-Tagen wäre alles wieder Tutti. Und Du willst mich anpissen, wenn es um Kompetenz geht? Geht’s noch?
Hab jetzt auch nochmal den ganzen Thread gelesen – mitsamt der letztlich wohl doch überzeugenden Hinweise der 2 Alexe:
Fasse zusammen: Das Verwenden des Zurück-Buttons hat im obigen Beispiel keinen anderen Effekt als wenn ein beliebiger User an irgendeinem PC unter seinem eigenen Account alle von Susi besuchten URLs nacheinander in die Adresszeile eingibt (oder halt entsprechende Links anklickt).
Da dadurch (z.B.) eine URL aufgerufen wird, die die Personenkennung einer anzumailenden Person enthält, kommt er dadurch (z.B.) logischerweise auf eine Mail-Edit-Seite, in der das Adressatenfeld entsprechend vorausgefüllt ist (und der Absender mit seiner eigenen Adresse).
Das sind unmittelbare Funktionalitäten; keine Bugs. Ein daran anknüpfendes Ausnutzen der der Browser-History zu ‘Spionage-Zwecken’ ließe sich effektiv nur durch eine Verschlüsselung der (per GET oder POST) übergebenen Parameter verhindern. Dieser Aufwand steht jedoch in keinem Verhältnis zum simplen Löschen der History, die in den meisten Browsern am effektivsten durch das Schließen des Browsers zu erreichen ist.
Das Einblenden eines entsprechenden Hinweises nach dem Log out wird empfohlen.
Außerdem wird angeraten, die geistigen und maschinellen Spam-Filter differenzierter handzuhaben.
Alex und Alex – zum letzten Aspekt: Ich kann die hier durchgezogene (zuletzt dann wohl auch bei mir zu große) Indifferenz gegenüber dem Argument ‘Die-User-sind-doch-absolut-selbst-schuld’ schon sehr gut verstehen; das war von Anfang an eins der Hauptargumente der Gegenseite; man konnte dass einfach nicht mehr hören; es hatte – vom heutigen Fall wohl abgesehen – einfach kein wirkliches Gewicht.
Und wenn ich es richtig verfolgt habe, hatte aber selbst dieser Thread hier noch den begrüßenswerten Effekt, dass das studiVZ jetzt no-cache-Header sendet ;)
@foobar:
Das ginge im hier beschriebenen Szenario (also dann, wenn der Browser offen bleibt) auch bei POST möglich – die gesendeten Daten liegen ja noch im Speicher. Sobald allerdings der Browser wenigstens geschlossen wird, ist die POST-Lösung bereits im Vorteil.
Im Endeffekt kann man StudiVZ wohl zumindest vorwerfen, dass es bei ihren wohl doch überwiegend technisch unbedarften Benutzern sinnvoll wäre, wenn man darauf hinwiese, dass der Nutzer auf öffentlichen Computern besser den Verlauf löscht. Und SSL wäre ebenfalls sehr erstrebenswert.
Porschekiller:
Ich weiß nicht warum du mit Gewalt unhöflich sein musst. Und nochmal: Was hab ich mit der Informationspolitik vom StudiVZ zu tun. Ich hab niemandem erzählt alles sei supi.
Tatsache ist es ändert am Orginal-Artikel natürlich rein gar nichts. Das ist doch genau der Punkt. Das Datenschutz-Problem was im Artikel geäußert wird hat in erster Line etwas zu tun mit der Tatsache, dass Dritte an Susis Links kommen. Das ist für Susi selbst dann ein Problem, wenn sie gar nicht auf StudiVZ unterwegs ist. Es ist, entgegen Dons Aussage nicht vom StudiVZ behoben worden und im allgemeinen Fall kann StudiVZ das auch nicht beheben. Selbst wenn StudiVZ die URLs verschlüsselt, kommt der Dritte auf dem selben Weg immer noch an all die anderen schweinischen Seiten, die Susi so gerne besucht.
Wenn das Ziel wirklich ist, wie du sagst aufzuklären, dann muss über dieses allgemeine Problem diskutiert werden, ob der Dritte jetzt über History oder über “Voice over Air” wie in meinem Beispiel an Susi respektive Alice Links kommt.
Das als StudiVZ spezifische Baustelle darzustellen, ist bei allem Respekt unseriös und sachlich nicht haltbar.
@kladde:
So langsam hab ich das Gefühl, dass hier mehr Drogen im Spiel sind als bei Real oder Barca…
“Fasse zusammen: Das Verwenden des Zurück-Buttons hat im obigen Beispiel keinen anderen Effekt als wenn ein beliebiger User an irgendeinem PC unter seinem eigenen Account alle von Susi besuchten URLs nacheinander in die Adresszeile eingibt (oder halt entsprechende Links anklickt).
Da dadurch (z.B.) eine URL aufgerufen wird, die die Personenkennung einer anzumailenden Person enthält, kommt er dadurch (z.B.) logischerweise auf eine Mail-Edit-Seite, in der das Adressatenfeld entsprechend vorausgefüllt ist (und der Absender mit seiner eigenen Adresse).”
Was ist denn daran bitte “logischerweise”? Warum kommt Jemand ohne weiteres mit einer einfachen URL auf eine Mail-Edit-Seite in ach-so-geschützten Verzeichnissen???? Weil die Struktur und das Coding der Site das erlaubt, aber nicht weil Dein Browser Schei..e ist!
Hört doch bitte auf, diesen DAU-GAU auch noch rechtfertigen zu wollen. Es war genug Kohle da, um ein schlüssiges Konzept zur Sicherung der Community im Vorfeld umzusetzen. Es gibt genügend OpenSource-Beispiele, die man genauso hätte kopieren können wie diesen Müll.
@Alexen: “Das als StudiVZ spezifische Baustelle darzustellen, ist bei allem Respekt unseriös und sachlich nicht haltbar.”
Wer bei aller Information über offene, unsichere Systeme im Web so eine Site mit *dieser* unsicheren Struktur ins Netz stellt, dafür VC-Kohle bekommt und *dann*, nach allen Hinweisen auf die Löchrigkeit des Systems immer noch behauptet, es wäre alles Tutti, *der* ist unseriös und als Dienstanbieter sachlich nicht haltbar.
@porschekiller
Naja, du hast neben der URL zwar noch ein paar andere Möglichkeiten, dem Server irgendetwas mitzuteilen; aber dieses ‘Mitteilen’ als solches muss schon irgendwie stattfinden. Wenn du stattdessen mit AJAX arbeitest, dann bringt das über denn ‘Zwang’ zur Verwendung von Javascript wieder neue Sicherheitsprobleme mit sich.
Was obigen Fall betrifft – so befindet er sich eben nicht mehr in einem ‘geschützten Verzeichnis’, sondern ist einfach als er selbst eingeloggt und gibt über die URL an den Server die Anweisung, dass er (_er_) eine E-Mail an die Person mit der Kennung XXXXX senden möchte.
Als Ergebnis sendet der Server die gewünschte E-Mail-Edit Seite.
Porschekiller:
Ich glaube ich habe gerade das Problem eingesehen.
Ich wollte über Datenschutz diskutieren. Datenschutz muss sowohl auf der Server als auf der Clientseite stattfinden. Selbst wenn der Server versucht Unwissenheit des Clients auszubügeln, wird die Information die der Client als Minimum unverschlüsselzt übermitteln muss, egal wo er surft, immer noch ein Problem darstellen. Nur der Client kann das lösen und es wäre unglaublich hilfreich und sinnvoll ihm das zu erklären.
Du dagegen wolltest darüber diskutieren ob StudiVZ ein seriöser Dienst ist. Das dies nicht der Fall ist, das wäre auch ohne diesen Blog eintrag um den es hier geht klar gewesen.
Wie konnte ich so naiv sein zu vermuten, dass es Leuten, die immer wieder, und zu Recht betonen, dass man nicht vom Client verlangen kann bestimmte Sachen “von sich aus” zu wissen, tatsächlich um den Client geht?
Stopp kurz mal – um mich selbst zu zitieren:
Nicht ganz richtig: keine E-Mail sondern eine ‘Nachricht’.
Ich selbst sende solche Nachrichten nicht – sondern ausschließlich ‘richtige E-Mails’. Den Sinn dieses ganzen merkwürdigen studiVZ-internen Nachrichte-Versende-Systems kann man allerding sehr wohl infrage stellen.
@Alex
Wen ich das, was du da, glaube ich, gesagt hast, so verstehe, wie ich glaube, dass ich es verstehe, dann hast du damit wohl irgendwas gesagt, glaube ich…
Ich dachte wirklich, dass Schluss ist, aber jetzt wo das auch noch so persönlich wird, möchte ich doch wenigstens noch die Chance haben mich zu rechtfertigen.
1. Ich bin wirklich ein anderer Alex als der andere. Dass ich von Don zu einem “Hans”-Troll gemacht werde, verstehe ich nicht so recht. Klar, da sind noch Cookies im Browser. Von den letzten zwei Kommentaren nämlich, die ich mal geschrieben hatte. Die E-Mail-Adresse ist valide und eine von denen, die alle halbe Jahre ausgetauscht werden. Aus der Adresse selbst sollte das auch eindeutig hervorgehen. Hey Don, schick mir doch mal was!
2. Meine Kommentare über die technischen Hintergünde des aktuellen StudiVZ-Problems haben /nicht/ das im Nachtrag genannte als Motivation. Stattdessen habe ich hier vielfach Vermutungen gelesen, die einfach nicht richtig sind. Da wollte ich ein bisschen Klarheit reinbringen. Wie man das nun bewertet, ist eine ganz andere Geschichte.
Ich finde, dass man dieses Vorgehen StudiVZ nicht Vorwerfen kann, zumindest nicht in der Form, wie es hier geschieht. Einen Hinweis darauf, dass man die History löschen sollte, finde ich allerdings auch angebracht.
3. Im Nachtrag wollte ich meine Meinung zu der Entwicklung äußern, nicht mehr. Ich bin ganz sicher kein StudiVZ-Sympathisant, Fälle wie das Tolerieren und sogar Mitmachen-Wollen in der Stalker-Gruppe finde ich auch absolut inakzeptabel, genauso die Lügen über die IDs, die so sicher seien wie PIN/TAN bei jeder Bank. Keine Frage, da hat StudiVZ ganz großen Mist gebaut. Auch glaube ich, dass da bestimmt noch mehr kommen wird. Nur im Moment wirkt es auf mich so, als würde man hier versuchen mit Gewalt immer noch was zu finden, auch wenn es eigentlich gar nichts so tolles neues gibt, was man berichten könnte.
4. Ja, kann schon sein, dass der Typ mit Einblicken in Personaler-Praxis gar keine Einblicke hatte und das nur so geschrieben hat. Ich fand es allerdings sehr plausibel, weil das auch meine Erfahrungen widerspiegelt. Den entsprechenden Artikel dazu von Don fand ich etwas übertrieben und habe dazu meine Meinung geäußert, mehr nicht. Auch scheint es in der Diskussion immer nurz schwarz und weiß zu geben, dabei ist die Wahrheit doch meist ein Grauton. Ich stimme zu, “Cool-Sein und Paaarty [sind] keine Charaktereigenschaften […], die soziale *Kompetenz* bedeuten.” /So/ hab ich das auch gar nicht gemeint, sondern eher, dass zumindest ich der Auffassung bin, dass man keine Angst haben muss, einen Job nicht zu bekommen, weil es irgendwo im Netz ein Bild von einem gibt, dass einen etwas unvorteilhaft zeigt. Klar muss man nicht zweimal überlegen, ob man einen einstellen will, der mehrfach pro Woche nach Hause getragen werden muss, weil er es selbst nicht mehr findet. So was meinte ich aber auch gar nicht. Und wer so was macht, dem ist auch nicht geholfen, wenn es keine Dokumente davon im Internet gibt. So ein Typ ist spätestens nach dem Bewerbungsgespräch raus, wenn er nicht schon zu viele Fehler im Lebenslauf hat.
Warum mir dann von porschekiller vorgeworfen wird, ich würde einen Kleinkrieg gegen den Blogautor führen, ist mir unbegreiflich. Ich habe ganz sicher kein Problem mit dem Blogautor und will erst reicht keinen Kleinkrieg gegen ihn führen. Ich bin lediglich über die Entwicklung in den letzten Wochen enttäuscht und davon überzeugt, dass das auch besser gegangen wäre.
In der Hoffnung, für etwas Verständnis gesorgt zu haben,
Alex
Schlimm, dass mir nach ein bisschen sachlicher Kritik hier der Mund verboten werden soll.
Ich werde mich in Zukunft von der Kommentarfunktion fernhalten, ist ok. Aber bitte lass wenigstens den vorherigen Kommentar von mir stehen, sonst wirkt alles wirklich nicht richtig.
Danke und Gruß,
Alex
@Alexen: “Wie konnte ich so naiv sein zu vermuten, dass es Leuten, die immer wieder, und zu Recht betonen, dass man nicht vom Client verlangen kann bestimmte Sachen von sich aus zu wissen, tatsächlich um den Client geht?”
Aaah, das gute alte Client-Server-Dilemma. Musste ja kommen. Alex(e), weisst Du eigentlich, dass klassische Client-Server-Applikationen nach einem völlig anderen Prinzip funzen, als im/durchs Web propagiert? TCP/IP ist da eher hinderlich; AS400 rules (leider) immer noch häufig.
Das Web gaukelt Dir eine Art Terminal-Emulation vor, die aber in Wirklichkeit ein 100%er Server-Prozess ist, auch wenn Du meinst, der Browser wäre total unabhängig vom Server. Alle Browser-Funktionen (inkl. Cache und History) sind ohne entsprechende Server-Funktionen nutzlos. Ein Terminal unter PC/Mac/Linux-Aspekten ist da viel unabhängiger, wenn man z.B. X11 betrachtet.
@axr (aka Alex_2): Ok, Peace;-)
Willst du ernsthaft behaupten, wenn StudiVZ dass jetzt ändert, ist es kein Problem mehr, wenn der Client seine History nicht löscht? Ist nicht allein der Eintrag analsex.com in der History genauso aufschlussreich wie die entsprechende Gruppe?
Browser speichern die History im allgemeinen im Klartext und selbst dann, wenn hinter der eingegeben URL noch nicht mal ein Server steckt. Und das ist vom Server abhängig? Ja sicher.
@ (ich denke mal positiv: andere(r) Alex):
Jung, Terminals haben keine eigene “Intelligenz”, um solche Sachen lokal zu speichern. Entweder man ist on und greift auf Serverdaten zu, oder man ist off und kann nix (intelligentes) machen. Dass PCs Daten aus den On-Sessions fürs Off speichern, ist eine Reminiszens an den unbedarften Home-User, um ihm die Mühe zu ersparen, gewisse Session-Daten wie z.B. längere URLs wieder manuell einzugeben.
Die dagegen-stehende “Intelligenz” von PCs im Net wird im Netz “benutzt”, um Last zu verteilen und dem User einfache Möglichkeiten an die Hand zu geben, seine Anforderungen an eine simple Benutzung umzusetzen. Die entscheidende Komponente ist aber immer noch der Server/Host, der entscheidet, ob die simple Anforderung ausgeführt wird oder nicht. Und da ist der Entwickler gefragt, der Host-Applikationen derart gestaltet, dass sicherheits-relevante Anforderungen umgesetzt werden oder auch nicht, wenn Sicherheit keine Rolle spielt.
Ich finde es erstaunlich, wie man aus dem einen Bug eine so lange Story schreiben kann. Das ganze hätte man locker in zwei Sätzen erklären können.
Übrigens: Ich hasse es, wie herablassend du über Menschen redest, die eine andere Meinung als du vertreten. Das hier auch Leute Kommentare schreiben, die eine andere Einstellung haben, liegt in der Natur der Sache, mit Spam hat das nichts zu tun.
Falls du dir diese Meinung nicht anhören willst, dann schreib gefälligst kein Blog.
Selbst wenn es sich bei einer Sicherheitslücke (in)direkt um ein Browserproblem handelt, so ist es dennoch möglich damit entsprechend umzugehen.
Es ist hinlänglich bekannt und gehört meiner Meinung nach zum Basiswissen eines jeden Webworkers wie die einzelnen Browser arbeiten.
Ein System DAU*-sicher zu gestalten heißt imho nicht nur es von einem DAU bedienbar, sondern es auch für den DAU sicher zu machen.
Jede konstruierbare Situation kann (theoretisch) eintreten. Der “Einfallsreichtum” der DAU ist grenzenlos.
Grüße
Mo
*DAU: dümmster anzunehmender User
Ich lese ja schon ein ganzes Weilchen hier mit und habe die Kampagne gegen das StudiVZ immer ein kleines bisschen belächelt. Es sind halt nicht alle Programmierfehler direkt “Privacy-GAUs”, da wird argumentativ ein bisschen nachgeholfen. Und die Naivität der Klientel beim Einstellen ihrer Daten ist kein Fehler vom StudiVZ direkt. Aber so manche Geschichte, unter anderem diese hier, lässt mich echt nur noch mit dem Kopf schütteln. Ganz schlimm ist das Phänomen wohl auszunutzen bei Tabbed-Browsern, da kann man ja dann sogar noch auf die Daten zurückgreifen, selbst wenn der Tab geschlossen wurde…
Falls Du das hier nicht magst, geh einfach und komm nie wieder, ich kann auf solche Einlassungen wirklich verzichten, und wenn sie mir nicht passen, haue ich sie raus. Und das sage ich ganz locker, weil Du ein Off Topic Textablaicher bist, der stört und für eine banale IP und eine Email jeder Hass eine Verschwendung wäre – Herablassung ist dagegen ein probates Mittel. Jaja, Hass, Schmass, geh einfach, tschüss, ciao. :-)
So sollte eine Community nicht funktionieren
Dieser Blogeintrag wird eine ungeordnete Zusammenstellung aller möglichen Links, die ich rund um die Probleme bei StudiVZ finde:
Was war. Was wird (1)
Was war. Was wird (2)
Was war. Was wird (3)
(Heise) Datenleck beim StudiVZ?
(Heise) Weiter Wi…
Die studivz-Menschen haben uns gestern Abend unseren Testserver geklaut *buuhuuhuuuu* *schnief* *schluchz* :-(
Firefox 2.0 User:
Bei GMX.de besteht dieses Sicherheitsleck anscheinend auch. Per Zurück-Button kann man sich – nach einem LOGOUT – zumindest ansehen, was die betreffende Person zuvor mit ihrem GMX-Account gemacht hat. Man kann aber nicht z.B. den Posteingang erneut öffnen.
Bei Freemail von Web.de funktioniert das definitiv nicht! Nach dem Logout betätigte Zurück-Buttons führen wieder zur Passwortabfrage.
Nur weil bei GMX ähnliche Sicherheitslöcher bestehen, heißt das nicht, dass Studivz das auch darf. Das Leck besteht und muss gestopft werden. Is doch eigentlich selbstverständlich. Weiter so, Don!
Geht es bei einer Diskussion nicht um versch. Meinungen?
Ach, so eine studiVZ ‘Diskussion’ ist doch was tolles! Erst die Qualität mancher Beiträge.
Was bedeutet Diskussion denn eigentlich? Wikipedia hilft:
Eine Diskussion […] ist ein Gespräch zwischen zwei oder mehreren Disk…
@me, 239
Ja, Web.de beispielsweise arbeitet wenigstens mit (zusätzlichen) Sitzungs-bezogenen URL-Parametern, durch die der von dir beschriebene Effekt erreicht wird.
Wenn man sich bei der grundsätzlichen Konzeption des Session-Systems ein paar Gedanken über das Problem macht, dann kommt man eigentlich durchaus auch auf Ideen, die sich mit geringerem Aufwand realisieren lassen als die gestern hier angesprochenen aufwändigen Verschlüsselungsverfahren.
Jedenfalls muss eine Web-Anwendung, die von einer Nutzeranzahl im 6-7-stelligen Bereich verwendet wird, die Kompetenz des DAU, für den diese Anwendung ohne Sicherheitsrisiko verwendbar sein soll, sehr sehr tief ansetzen.
(Es wird z.B. eine Menge User geben, die nicht auf Anhieb wissen, wie man die auch nach dem Schließen des Browsers noch übrigbleibenden Reste der Browser-History – ‘Chronik’ im FF, ‘Verlauf’ im IE – löscht.)
Man sollte studiVZ und anderen Dienstleistern nicht vorwerfen, wenn der Client etwas speichert, was er nicht sollte. Wenn der Server entsprechende Direktiven setzt, die der Browserclient dann nicht umsetzt, ist das nicht das Problem der Serverapplikation. Speziell die Implementierung des Zurück-Buttons in Firefox >1.5 und in neueren Opera-Versionen könnte problematisch sein, da sie die letzten Seiten komplett gerendert im Speicher hält (damit sie dem User ohne Verzögerung angezeigt werden können).
Um nochmal zu verdeutlichen, dass Dons ursprünglicher Beitrag
weder mit Sessions noch mit Caching zu tun hatte, möchte ich noch aus meinem Kommentar bei Elias zitieren:
http://verspult.com/index.php?/archives/16-Mal-wieder-Privacy-bei-StudiVZ-Ein-Blick-hinter-die-Kulissen.html
Ich würde daher ein Update dieses Artikels begrüßen, damit Missverständnisse vermieden werden.
Kleines Beispiel anhand des Nachtrags:
“- und dann zu den internen Mails kommt”
Falsch. Man kommt nicht zu den internen Mails von Susi. Die URL besagt schon durch die Parameter, dass ein neues Nachrichtenformular mit Susi als Empfänger geöffnet werden soll und nichts anderes tut der Browser auch. Man “erfährt” also nichts, was nicht schon direkt in der URL (die aus der History des Browsers stammt) steht.
“Man wird ironischerweise selbst als Absender für die Mail von Susi sichtbar, erkennt aber, an wen die Mail von Susi ging. Der Text ist glücklicherweise nicht sichtbar.”
Man wird nicht ironischerweise sondern logischerweise als Absender sichtbar, da über den Absender nichts in der URL steht und dieser dann vom PHP-Skript immer auf den aktuell eingeloggten User gesetzt wird. Der Nachrichtentext ist natürlich nicht sichtbar, da der dargestellte Sachverhalt bzw. die Wirkung weder Folge von unerwünschtem Caching noch einer Sicherheitslücke ist.
Sorry für den langen Beitrag und danke fürs Lesen. :-)
Sorry, DonAlphonso, aber mit deinen Beleidigungen einigen Kommentierenden gegenüber disqualifizierst du dich selbst.
[Edit: Sorry werauchimmer, ich kicke hier Spammer so raus, wie ich es für richtig halte, und wem es nicht past – mei. Für mich sind Kommentatoren nur eine IP und eine oft falsche Email, die hier irgendwas ablaichen. Nicht alle, aber doch so einige. Don]
Noch ein kleiner Optimierungs-Tipp für die studiVZ-Jungs: :-)
Beim Logout würde es sich übrigens empfehlen, per “Location:”-Header (http://de.php.net/header) eine “frische” Seite (die dann ohne History ist) aufzurufen; dann dürfte der Zurück-Button nämlich ausgegraut sein, und die User kommen gar nicht darauf, nach dem Logout (und evtl. Neu-Login wie bei Don) wild mit dem Zurück-Button zurückzuspringen.
@Spooky, 242 und 244
Ein ‘Update’ des Artikels hat gestern im Rahmen der Kommentare imho in wirklich ausreichender Form stattgefunden.
Herauskristallisiert hat sich dabei,
– dass das von studiVZ angewandte Verfahren zwar in sich logisch ist und es sich in diesem Fall nicht um ein Riesen-Datenleck handelt;
– dass es aber dennoch Methoden gibt, die einzelnen Schritte des Benutzers (_zumindest_ vor einem technisch unbedarften Nutzer, dem die verwendeten Requestdaten – per Browser-History/-Verlauf/-Cache – zugänglich sind), zu verbergen (Beispiele freemail.web.de, google mail, etc.).
Und: das das Anwenden solcher Methoden bei Nutzerzahlen in (angestrebter/erreichter) Millionenhöhe eine Selbstverständlichkeit sein sollte.
@Kladde: Ich stimme dir voll und ganz zu.
Nur dachte ich, dass vielleicht nicht jeder alle Kommentare liest und Don vielleicht auch daran gelegen sein könnte, seine zumindest irreführende Darstellung im Artikel zu korrigieren.
Bei studiVZ wurden auch schon so manche Blogeinträge in den User-Kommentaren “korrigiert”. Und wenn man von studiVZ eine Korrektur von Fehlern bzw. Falschdarstellungen fordert, sollte man IMHO auch selbst bereit dazu sein.
Spooky: Das ist nicht mein Blog hier (btw: isch ‘abe gar keine Blog), aber wenn es meins wäre: Hier ist nicht heise.de, hier ist meins, meins, meins. Da bleibt stehen, was ich stehen lassen will. Wer sich permanent mokiert, soll sein Eigenes aufmachen. Punkt.
Don hat etwas beschrieben, was zum Zeitpunkt der Artikelerstellung definitiv ging. Er hat es IMHO geschrieben, damit die StudiVZ-User lesen, was *auch noch* – neben den schon geschilderten Lecks – so geht in ihrem Gruschelreich. Es hat es IMHO geschrieben, um auch klarzumachen, dass es keine pipapo-Klitzerchen sind, die bei StudiVZ schieflaufen, sondern dass es ein *strukturelles* Problem ist, welches die nicht in den Griff kriegen!
(Don möge mich korrigieren)
Spooky, da oben stand schon immer klar und durchaus einschränkend unter dem letzten Bild:
Ich weiss nicht, ob Du das überlesen hast, aber das da oben sind Fakten, an denen ist nichts zu beanstanden. Dass Du technisch ganz dolle Dinge sagen kannst, glaube ich Dir. Aber ich sage es so, wie ich es sehe, und nicht anders. Zumindest, solange es stimmt. Für andere Meinungen jenseits von Unsinn, Spam und Unhöflichkeiten gegenüber dem Betreiber gibt es die Kommentare.
@Spooky
Sieh den ‘Artikel’ (Artikel != Blog-Posting) einfach als Thesenpapier.
‘Irreführung’ ist ein sehr weitgefasster Begriff.
Folgender Aussage ist beispielsweise genauso irreführend:
‘Es hat nichts mit Sessions zu tun.’
Man kann/muss die datentechnische Umsetzung einer ‘Session’ durchaus so gestalten, dass sie DAU-abfedernd wirkt. (Und das geht über – die durchaus sinnvollen – cache-control-Header und das Markieren einer Session als ‘beendet’ hinaus.)
Lieber Don A.
ich bin Dir für Deine Artikel od. auch Blogs sehr dankbar. Ich bin zu StudiVZ eingeladen worden und habe es anfangs unbedarft zur Vernetzung mit Freunden und alten Bekanntschaften genutzt. Erst vor wenigen Wochen habe ich von Problemen auf dieser Plattform gehört und bin durch verschiedene Nachrichten schließlich hier gelandet.
Und man wird hier wirklich sehr gut informiert. Ich bekomme langsam immer mehr die Lust.. oder sagen wir die Neugier wird immer größer (ist es wirklich sooo einfach?). Auch wenn die Hälfte der Nutzer die Probleme kennen gibt es immer noch Hunderttausende Dussel, die von all dem hier nichts wissen.
Dank der genauen Beschreibungen werde ich mal einige dieser Tricks.. äh Lecks ausprobieren und nach einigen schicken Fotos von schicken Frauen suchen -die ich ja nicht sehen sollte…
Ich finde es auch gut, dass eine (auch noch so genaue) Anleitung nicht als Aufruf gewertet werden kann.
Du kannst ja weiter Dein Ego mit Enthüllungen aufwerten, ich geh dann mal auf die Jagd *zwinker zwinker . DANKE!
Dein Mario M.
Achso: http://de.wikipedia.org/wiki/Stalking
@’Mario M.’ (17:39)
Selten solche Dummdreistigkeitsklopper gehört wie deinen.
Die Dunkelmänner treten zutage.
Ich finde dass die ganzen Argumentationen “das würde doch nie passieren weil man sich vorher z.B. im Rechnerraum ausloggt” hinken. Nei uns in der Vorlesung haben viele Notebooks und auch ich habe mein Notebook im Prinzip jedes mal jemandem geliehen der es “mal kurz” benötigt hat. Und dabei jedes mal in meinem Browser “alle privaten Daten” löschen, Browser zu, Browser auf..? Im Zweifelsfall: ja. In der Realität passiert das doch nicht. Da denkt man eher: bei dem freundlichen Komilitonen der oft neben mir sitzt ist das sicher nicht notwendig.
Was da bei man-in-the-middle so gehen kann ist enorm. Jede Sicherheitslücke, und sei sie noch so klein und schwer zu nutzen, wächst mit ein paar anderen kleinen solchen Lücken so einem größeren Hack. Da merkt man dann gleich, wenn in der Uni wireless vorhanden ist, wie gut die Uni die Infrastrukur stellt. Bei uns kann man z.B. nur per VPN raus, also kein m-i-m möglich. Kann mir aber kaum vorstellen dass das an allen Unis so sicher geregelt ist.
Dass andere Portale gegen solche Lücken gefeit sind, zeigt, dass man sowas verhindern kann.
Eine “soziale Anwendung” wie dieses Studentenportal muss auch ohne vorausgesetzte Sachkenntnis der User auf eine sichere Art und Weise nutzbar sein. Dazu muss die Software halt so defensiv aufgebaut sein dass man auch unter speziellen Umständen nicht hinter die Kulissen blicken kann.
Das ist zwar nichts neues und wird auch bei anderen Webseiten/Portalen und irgendwelchen Diensten die wir alle kennen falsch gemacht (man erinnere sich nur an die Zeit wo es hotmail.com ähnlich nass reinging), im Kontext von sozialer Software bekommt das aber eine ganz besondere Bedeutung. Die User müssen teilweise auch aktiv beschützt werden, sonst ist das Ding gefährlich! Bei den Banken wird man ja teilweise auch proaktiv über Fishing aller Art aufgeklärt.
@DonAlphonso
Das Verhalten der Verlaufs-/History-Funktion des Browsers mag manchen Nutzern nicht bewußt seien, jedoch ist es so, oder so ähnlich gewollt. Der HTTP-Standard schriebt eigentlich sogar explizit vor, daß beim der Benutzung der Zurück-Funktion die vorangegangenen Seiten genau so dargestellt werden, wie sie zuvor zu sehen waren. (RFC 2616, Kap. 13.13) Schliesslich soll die Historie angezeigt werden. Bei korrekt arbeiteten Browsern hat StudiVZ also keine Möglichkeit dies zu unterbinden. Das andere Web-Dienstleister dies mit Tricks teilweise erreichen, ist strenggenommen eine Fehlfunktion des Browsers.
Es bleibt nur die Nutzer aufzuklären, die Verlaufsfunktion abzuschalten, bzw. keine Fremden an den Browser zu lassen.
Eigentlich finde ich den Verlauf ganz praktisch. Man muß sich nur im Klaren darüber seien, daß man damit seinen Weg durch das Internet nachvollziehen kann.
Oder anders argumentiert: Wenn alle Web-Seiten-Betreiber den Verlauf sabotieren würden, wäre die Funktion sinnlos. Ich finde es so, wie es ist, ganz gut. So hat der Nutzer die Wahl, ob er den Verlauf benutzen möchte, oder nicht, weil es für ihn ein Risiko darstellt. Es betrifft ja nicht nur Seiten, die ein Login erfordern. Auch der Besuch »normaler« Web-Seiten kann kompromentierend seien. Ob, oder ob nicht kann aber der Nutzer am besten selbst beurteilen.
Ergänzung zu 19:10
In dem von Dir geschilderten Fall hat sich Susi vom StudiVZ abgemeldet, nicht jedoch von ihrem Rechner, bzw. Browser. Der Browser hat den Benutzerwechsel also überhaupt nicht mitbekommen, und somit auch keine Veranlassung sensitive Informationen vor dir zu verbergen. Deshalb zeigt er dir bereitwillig Susies Verlauf an. In dem Moment, in dem der Browser Daten vom StudiVZ lädt, bekommst du deine Version der Seite zu sehen. Für StudiVZ hat es ja einen Benutzerwechsel gegeben, und sie beachten dies auch korrekt. Wenn Susi ohne sich am Rechner auszuloggen, jemand anders daran läßt, halte ich es für erwartungsgemäß, daß diesem dann alle Computer/Programmfunktionen zur Verfügung stehen, die auch Susi zur Verfügung stehen, einschließlich des Browser-Verlaufes. Ebenso die Datei mit ihren Liebesbrief, den sie eben noch in Word getippt hat und sonst alles auf dem Rechner.
Ähm, mal ne Frage, wer ist denn so blöd, dass er z.B. in der Unibibliothek den Browser anlässt und sich nicht abmeldet (vom Unirechner), wenn man den Rechner verlässt? Unsere Unirechner machen dazu auch noch jeden Idioten darauf aufmerksam, sich mit seinem Uniaccount abzumelden (bzw welche Uni hat denn Rechner, die ohne einen Account vom Rechenzentrum funktionieren?
Klar, das Problem muss StudiVZ lösen, keine Frage. Aber ich halte den geschilderten Fall für sehr unwahscheinlich. Zumindest müsste diese Susi ziemlich blöd sein, wenn ihr das passiert.
hmmm, habs gerade mit meinem gmx-account ausprobiert, da gibts auch diese “sicherheitslücke”…
@Don: Den von dir zitierten Punkt habe ich weder überlesen noch bestritten, ich wollte lediglich erklären, warum das genau so sein muss und keinerlei Sicherheitslücke darstellt. Als “falsch” habe ich den ersten Punkt in meinem Beispiel bezeichnet, aber auf den bist du ja leider nicht eingegangen.
@Kladde:
Dann erklär mir doch mal bitte, welcher der von Don beobachteten “Effekte” mit Sessions zu tun hat.
Ãœbrigens gehen Dons Beispiele ja nach wie vor, ist auch kein Wunder.
Ich mache jetzt auch mal ein kleines Beispielszenario wie Don. :-)
Also, ich komme nach Susi an den Rechner mit dem noch geöffneten Browser und klicke fröhlich immer auf den Zurück-Button. Ein paar Google-Suchseiten erscheinen. Aha, sie hat nach “falsche E-Mail-Adresse” und “IP fälschen” gesucht, interessant. Ein paar Seiten weiter zurück komme ich zum Forum “Scriptkiddies”; praktischerweise steht der Username “CrackerSusi” (aus nem Cookie) im Loginformular und das Passwort hat der Browser sich gemerkt und eingetragen. Prima, ich logge mich als Susi ein und surfe in einem neuen Tab ein wenig in Susis Forenprofil und in ihren Beiträgen herum. Ganz schön interessant (und vor allem strafrechtlich relevant), welche Seiten Susi zusammen mit den anderen lahmlegen wollte und in welche Systeme sie schon eingedrungen ist (so prahlt sie zumindest). Aber ich setze besser meine Reise mit dem Zurück-Button fort, vielleicht finde ich ja noch mehr. Aha, ein paar ebay-Auktionen erscheinen, dabei sticht mir der Username “Susilein” ins Auge, das muss sie sein. Ich klicke auf den Usernamen und schaue mir ihr öffentliches Feedbackprofil an, so kann ich alle ihr Käufe und Verkäufe der letzten 3 Monate unter die Lupe nehmen. Sehr aufschlussreich! Ein paar Seiten weiter zurück mit dem Zurück-Button und um einige Erkenntnisse reicher bin ich dann am Anfang der Browser-History angelangt. Aber was ist denn das? Das ist doch …. genau, dieser blogbar-Artikel hier, und im Kommentar-Formular steht sogar noch Susis Name und ne E-Mail-Adresse (aus nem Cookie). Is ja doll! Da schreibe ich doch gleich mal als Susi einen Kommentar, in dem ich ihre ganze Verbrechenshistorie darlege. Für Don sieht das jetzt so aus, als hätte Susi nochmal einen Kommentar geschrieben; doch er kommt aus dem Staunen nicht mehr heraus, was sie darin alles beichtet.
Und jetzt? War das nicht ein Privacy-GAU in Serie?
Wie hätte man das aber verhindern können?
Müssen jetzt die ganzen Webseiten von Google über ebay bis blogbar.de umgeschrieben werden, so dass sie weder GET-Parameter in der URL noch Cookies benutzen, nur weil ich mir mit Susi einen Browser geteilt habe?
Oder hätte man Susi besser beibringen sollen, dass sie nach ihrer Surfsession History, Verlauf und gespeicherte Kennwörter löschen und den Browser beenden sollte?
Hmm :-)
Wenn Dir schreiben hilft, mach weiter, es ist Deine Lebenszeit. Da oben bleibt alles, wie es ist. Wenn ich auf jeden dahergelaufenen Besserwisser und seine diversen Ausnahmeideen hören würde, müsste ich mit dem Bloggen erst gar nicht anfangen.
@Spooky: “Ich mache jetzt auch mal ein kleines Beispielszenario wie Don. :-)”
Du heisst aber nicht Don Alphonso, siehst nicht so aus, riechst noch nicht mal danach und schreibst Zeuch, welches sich Keiner durchliest. Glaubst Du ernsthaft daran, dass Deine Nummer zum 5-Minute-Famous-Status reichen wird? Ernsthaft? Zukünftig?
@ody: “@porsche das Niveau ist mal wieder im Keller”
Soll’n wir Dich da jetzt besuchen oder kommst Du auch ohne uns klar?
@Spooky, 257
Die Diskussion dreht sich im Kreise, Spooky – ein letztes kurzes Gegenbeispielszenario von mir:
Ich logge mich bei studiVZ ein, tue dort dies und das, logge mich wieder aus. Mein Kumpel loggt sich ein und bedient dann mehrfach den Zurück-Button. Er bekommt eine Menge zu sehen – (einschließlich vor-ausgefüllter Adressatenfelder).
Ich logge mich bei einem sicherheitstechnisch ‘up to date’ programmierten Web-Dienst ein (Beispiele wurden genannt), tue dort dies und das, logge mich wieder aus. Mein Kumpel loggt sich ein und bedient dann mehrfach den Zurück-Button. Er bekommt immer nur Hinweise angezeigt wie: ‘Diese Seite ist nicht mehr aktuell.’
Letzterer ‘Effekt’ kann über bestimmte Prüfverfahren realisiert werden, in denen bestimmte Session-Variablen und bestimmte Request-Variablen eine Rolle spielen.
(Groschen gefallen?)
Ich habs eben mal ausprobiert – bei sicherheitsrelevanten Webdiensten, die (hoffentlich) up-to-date produziert sind. Mein Browser ist Opera 9, also offenbar einer von den bösen, die den Verlauf so speichern, wie er war:
Web.de: Benimmt sich ein wenig zickig (versucht, eine Fehlermeldungsseite zu laden). Mit einem beherzten Doppelklick kann ich da aber auch nach dem Logout noch meine Nachrichten lesen.
comdirect: Ãœberweisungen, Umsätze – alles auch nach dem LogOut per Zurück-Knopf frei erreichbar. Völlig problemlos.
Mir kommen da also auch Zweifel ob der Verantwortlichkeit von StudiVZ…
Letzter Nachtrag.
Eine von einigen Fachleuten hier angemerkte Diskussionswürdigkeit sowohl obigen Szenarios von mir als auch des Artikels von Don liegt darin begründet, dass beide sich zur Veranschaulichung der (bei etlichen Browsern _nicht_ streng RFC-gemäß implementierten) History-Funktion bedienen.
Es gibt für Benutzer-Interaktionen wie ‘Log in’ und ‘Log out’ letztlich so viele Implementierungsmöglichkeiten wie Wege nach Rom. Fakt ist, dass die Benutzer-Interaktion ‘Log out’ so implementiert werden kann, dass ein anschließender Abruf einer Funktion über dieselben Abrufparameter wie zuvor nicht möglich ist. Diese Art der Implementierung ist für sicherheits-sensible Bereiche wie social networks die zu bevorzugende.
Und – ja – dies gilt auch dann, wenn es keinen Effekt auf die Browser-History-Funktion haben sollte (wie beispielsweise im Opera-Browser).
Während die History, verstanden als Verfügbarkeit der ‘Rückwärts’-/’Vorwärts’-Funktion, durch das Schließen des Browsers noch relativ leicht gelöscht werden kann, gibt es ja trotzdem auch danach noch weitere History-Spuren (‘Verlauf’ bzw. ‘Chronik’). Und das Löschen dieser Spuren setzt mehr Wissen voraus, als bei social networks mit nicht klar eingrenzbarer Benutzerzahl vorausgesetzt werden sollte.
Dons Blog-Post hat sich die Freiheit genommen, über die Art, wie die History-Funktion in den von ihm (und vielen anderen) verwendeten Browsern implementiert ist, einen bestimmten Sachverhalt zu veranschaulichen. Nenne es meinetwegen ‘Feldversuch an einer real existierenden Web-Anwendung unter Zuhilfenahme real existierender Browser’.
In sicherheitstechnischer Hinsicht ist der Maßstab nun einmal die Wirklichkeit – und nicht die HTTP-Spezifikation (so wünschenswert das vielleicht auch wäre).
@Spooky, 264
Dass diese beiden Fragen – insbesondere in Zeiten stark steigender DAU-Zahlen unter den Nutzern (Web 2.0) – keine Argumente dafür sind, die schlechtere der Implementierungen zu wählen, ist seltsamerweise manchmal schwer zu vermitteln.
Aber ich vertraue einfach mal darauf, dass es ausreichend Leute gibt, bei denen die offenstehende Möglichkeit, etwas besser zu implementieren, einen kleinen Pawlow-Reflex auslöst :)
(Und du hast völlig recht: _Das_ ist ein über studiVZ weit hinausgehender Punkt.)
StudiVZ-Rundgang bei YouTube
http://blog.jensbreitbarth.de/?p=51
Seit 8.12.2006 gibt eine Domainanmeldung (aus China) für studivzz.net.
Ist schon aktiv, lt Google Search für die IP scheint diese einem “Spammer” zu gehören.
Es wird eine, an Google angelehnte Seite, angezeigt und Werbefenster mit wechselnder Werbung.
Hat wahrscheinlich nichts zu bedeuten, reiner Zufall.
Oder ist das der Ausgangspunkt für mehr?
also dieses problem sehe ich auch nicht sooo tragisch. aber tatsache ist es lässt sich innerhalb von 5min bei der login page fixen. aber das müssen die jungs im ostblock nun erstmal rausfinden hehe
@Anson: “Schon bitter wie verzweifelt hier nach Möglichkeiten gesucht wird,”
Hatte erst gedacht, es wär was Lesbares. Aber der Mangel an Satzzeichen ward Dir dann doch noch stärker benebelnd als Deine Scheinargumente. Not so nice try…
Kann es sein, daß das diesmal keine Sicherheitslücke von studivz ist, sondern Du einfach die besuchten Seiten von Susi im Browser-Cache anschaust?
Das Problem dürfte jede Webseite haben, wenn man den Browser-Cache nicht anschließend leert.
Das Beispiel hier müsste eigentlich auch funktionieren, ohne daß man sich nach Susi ausloggen neu anmelden muss.
Gruß,
Marcel.
Die Frage ist, ob er dann nicht auch die Rechte von Susi erwirbt. Oder ob er nur die Seiten, die sie besucht hat anschauen kann, ohne Aenderungen vorzunehmen.
Aber Anscheinend kann man nur sehen, was sie gemacht hat.
Marcel. wie oben beschrieben: Es ging auch mit gelehrtem Cache.
Gehackt!
Jaja, das musste ja kommen. Nach dem Entdecken einer SicherheitslÃcke bei StudiVZ und der Erkenntnis, daà sie zwei Wochen spÃter immer noch funktionierte, ist jetzt einer meiner Server auch Opfer eines Angriffs gewesen. Weil ich ja ein netter Mensch bi
weiss auch jemand wie man bei Studivz
[edit: hmpf. Sowas nicht hier. Don]
Mittlerweile gibt es die Möglichkeit, eine SSL verschlüsselte Verbindung mit dem StudiVZ-Server aufzubauen. Jedoch wird dies keineswegs von StudiVZ umworben. Über https://www.studivz.net lässt sich eine RSA-verschlüsselte Socket-Layer Verbindung aufbauen. Ich weiss nicht ob die ein zu hohes Traffic-Akfkommen befürchten oder so, aber mir ist schon rätselhaft warum SSL seitens StudiVZ unterstützt und gleichzeitig quasi geheimgehalten wird.
MfG
Fabio
[…] Kaum ist StudiVZ wieder online, werden Sicherheitslücken aufgedeckt. Nachzulesen wie fast immer in der Blogbar. Ich bin kein Programmierer, aber bei GMX funktioniert die Vorgehensweise ebenfalls. Scheint also nicht nur StudiVZ zu betreffen. […]
[…] Edit: Uuuund weiter gehts… kaum ist das Ding wieder on… aber lest selbst… […]
[…] Es will mir einfach nicht einfallen. […]
Lieber Don,
kannst Du nur die Seiten von Susi angucken, die der Feuerfuchs noch vorrätig hält? Da könnte dann nämlich StudiVZ nach meinem dafürhalten wenig dafür, das wäre eher ein Problem des browsers. Oder kannst Du wirklich teile von Susis account Nutzen?
Auf alle Fälle eine Interessante Entdeckung!
Gruß Philipp
hallo, wie kann ich denn das käffchen beenden????hier geht ja nix mehr….bitte um hilfe…
DEINE MUTTER