Http-statuscodes tonen of bezoeker bij webdiensten is ingelogd

Met het gebruik van javascript en http-statuscodes, die websites retourneren als content wordt opgevraagd, kan worden achterhaald of een persoon op die site is ingelogd. Alle huidige browsers blijken kwetsbaar voor een vorm van de aanval.

Webdeveloper Mike Cardwell doet op zijn weblog twee varianten van het lek uit de doeken. De eerste variant werkt met Gmail, waar Cardwell een foto voor zijn profiel heeft geüpload en voor iedere Gmail-gebruiker toegankelijk heeft gemaakt. Niet-ingelogde gebruikers kunnen de foto niet bekijken en worden doorverwezen naar de inlogpagina. Door de foto op een andere website te embedden, kan met behulp van de javascript-events onload en onerror worden achterhaald of de sitebezoeker op Gmail is ingelogd. De beide javascript-events worden geactiveerd als content respectievelijk wel of niet succesvol is gedownload.

De tweede variant werkt door het als javascript laden van een pagina waarvan bekend is of de gebruiker hiervoor ingelogd moet zijn. Deze variant werkt echter alleen bij Firefox, Safari en Chrome. Concurrenten Internet Explorer en Opera lijken kieskeuriger te zijn in het accepteren van Javascript en daarmee in het afvuren van het onload-event.

Het privacylek lijkt op de mogelijkheid om met behulp van css en javascript te achterhalen op welke websites een gebruiker is geweest. Dit lek was al jaren bekend en was aanwezig in de meeste gangbare browsers, omdat het voortkomt uit de eisen die in de standaarden worden gesteld. De 'css history bug' werd pas in 2010 door diverse browsermakers opgelost en bleek ook actief te worden misbruikt.

Reacties (76)

[Tsurany]

Maar het enige wat ze weten is of je wel of niet ingelogd bent, niet welke account je gebruikt of wat je wachtwoord is. Ze weten dus enkel een IP adres te koppelen aan het wel of niet bezitten van een account. Dat is toch niet zo'n gigantisch probleem? Qua privacy is het natuurlijk niet gewenst maar echt een aanval zou ik het toch niet willen noemen.

Als Tweakers het in deze pagina zou doen dan zouden ze weten of ik wel of niet gebruik maak van die diensten aangezien ze mij als ingelogde gebruiker herkennen, maar hoe interessant is dat voor hun om te weten als ze niet weten onder welke naam ik opereer? Ja dat kunnen ze uitzoeken via mijn accountinformatie (naam, nickname, e-mail adres) maar dan kunnen ze evengoed willekeurig gaan zoeken op die profiel sites. Enig verschil is dat ze nu weten welke sites ze in ieder geval op moeten zoeken willen ze een profiel over mij kunnen vinden omdat ik daar op ingelogd ben.

Maar als een site dus niet weet wie ik ben maar enkel wat mijn IP adres is (en wat browser en OS informatie) is het toch niet heel interessant?

[Reactie gewijzigd door Tsurany op 23 juli 2024 05:40]

[Verwijderd]

Maar het enige wat ze weten is of je wel of niet ingelogd bent, niet welke account je gebruikt of wat je wachtwoord is.

Ideaal dus voor een phishing site.
Een phishing site kan voortaan achterhalen bij welke site jij bent ingelogd en je dan een pagina voorschotelen van die site waarin je om account en wachtwoordgegevens wordt gevraagd.
Dat geeft veel meer kans op success omdat je sowie al weet dat iemand op die site een account heeft en bovendien zal de gebruiker omdat deze ook actief is op die site een onverwachte oppoppende pagina van die site minder snel als verdacht beschouwen.

Daarnaast zijn er nog theoretische mogelijkheden voor een man-in-the-middle aanval bijvoorbeeld als je bij een bank ingelogd bent en een willkeurige site dat kan constateren.

Ten derde is er mogelijk nog een uitbreiding van het Cross-Scripting risico. Normaal is het eigenlijk ondoenlijk om een XSS aanval te doen op pagina's die achter logins zitten en richten aanvallen zich meer op veel onbeschermde pagina's. Maar als je kan zien dat iemand is ingelogd worden dergelijk pagina's ook eerder doelwitten.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 05:40]

[Tsurany]

Daar heb je een goed punt, het zou phishing een stuk geloofwaardiger maken doordat je nu enkel correcte pagina's voorschotelt en op de gebruiker kan inspelen door te melden dat je ziet dat ze al ingelogd zijn en hun gegevens kunnen koppelen voor een betere samenwerking. Echter daadwerkelijk misbruiken zal niet lukken, je moet dus alsnog hopen dat de gebruiker zo stom is, je kan hem enkel geloofwaardiger voor de gek houden.

Met een bank denk ik niet dat dit zou lukken simpelweg omdat die geen content serveren die met anderen gedeeld wordt als ze ingelogd zijn. Er zijn geen plaatjes of andere zaken die je met medegebruikers kunt delen waardoor zo'n check ook niet gebruikt kan worden.

[Reactie gewijzigd door Tsurany op 23 juli 2024 05:40]

[coptician]

Er zijn maar twee dingen oneindig: het universum en menselijke domheid. Over die eerste wordt nog getwijfeld.

[ajakkes]

Is dat wel zo?
Er is vast wel een element die alleen is op te vragen op het moment dat iemand ingelogd is. Een bank die door middel van javascript iets ophaalt en terugstuurt naar de pagina die het vraagt en iets anders terugstuurt als de gebruiker niet is ingelogd.

Plaatjes zullen zelden zijn afgeschermd voor niet ingelogde gebruikers. Maar misschien wel een bepaald gegeven, adres van de dichtstbijzijnde bank o.i.d. dat door middel van javascript wordt opgehaald.

[Verwijderd]

Dat is ook mijn eerste reactie.... leuk dat ze dit nu berichten maar het is een variant op xss waarbij data slechts wordt ontvangen... ik zie even niet hoe dit echt gebruikt/misbruikt kan worden. Heeft iemand een idee?

edit:
als je invloed zou hebben op de embeded image zou je er wat mee kunnen maar google neemt de data van je image over. Het terugsturen van data wordt daarmee onmogelijk.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 05:40]

[PV85]

Je kan een pagina maken die dit op verschillende sites tegelijk toepast en je hebt zo duidelijk een beeld van welke websites de gebruiker allemaal gebruikt. Privacy issues dus.

[Verwijderd]

Het werkt op zeer specifieke sites (zoals google). Behalve dat het erg veel werk is om dit voor elke site te bouwen en te testen heb je alleen de info dat een ip wel eens inlogd op een zeer veel gebruikte site.

Elk privacyissue moet bekeken worden. Absoluut waar. Maar ik zie niet in dat dit issue echt schadelijk (of nieuwswaardig) is.

[ajakkes]

Je kan zien of de de browser op dat moment ingelogd is op dat account.
--Nadeel:
Als de gebruiker is uitgelogd, vaak is browser sluiten genoeg, zie je niet meer of er een account is.
Je zal moeten weten welk plaatje zichtbaar is voor gebruikers die ingelogd zijn en niet als ze uitgelogd zijn, (eenvoudig door deze content zelf aan te maken).

--Voordeel:
Je zou kunnen testen of de gebruiker de gewoonte heeft uit te loggen op andere sites of niet, bij herhaaldelijk bezoek van jou site.
Je zou kunnen testen of de gebruiker toegang heeft tot bepaalde hyves elementen die alleen te zien zijn door vrienden. Is de bezoeker een vriend van Rutte of Wilders. Je zal dan echter wel moeten weten welke content is afgeschermd.


Ik vraag me af of je ook dergelijke content weer zou kunnen uploaden naar jou server door middel van javascript. Je hebt dan de URL nodig van iets dat je niet mag zien. Soms lastig te krijgen maar soms eenvoudig. Je laad de foto op je canvas en stuurt het canvas terug naar de server.

[Japs]

Volgens mij werkt het zo dat als tweakers dit zou misbruiken, ze kunnen zien of jij op dit moment bij een andere website (uit het voorbeeld Gmail, maar in principe zou dit met veel meer sites kunnen) bent ingelogd.
Vervolgens zou tweakers (in theorie) met allerlei crossbrowser ellende, en mogelijk bekende lekken in Gmail (in dit voorbeeld) vanuit tweakers van alles in je gmail account kunnen doen (je weet immers zeker dat de gebruiker op dit moment daar is ingelogd).

Ik weet er absoluut niet genoeg van om het daadwerkelijke risico hierop in te schatten, maar helemaal fijn klinkt het toch niet.

[Reactie gewijzigd door Japs op 23 juli 2024 05:40]

[Patriot]

Als er bekende lekken zijn in bepaalde software/websites, dan maakt het je natuurlijk geen reet uit of iemand is ingelogd of niet. Je probeert het gewoon en als ze niet zijn ingelogd dan is er geen resultaat.

[Verwijderd]

Je probeert het gewoon

Het kan je succesrate potentieel enorm ophogen als je een gerichte aanval klan plegen omdat je weer dat iemand ergens is ingelogd.
Bovendien kun je site inrichten om juist geen aanval te plegen als de bezoeker niet op een site is ingelogd. Daardoor zal je site veel moeilijker gedetecteerd worden door malware bestrijders en dus minder snel verschijnen in bijvoorbeeld een browserfilter.

[humbug]

Als je ingelogd bent en content voor ingelogde gebruikers kan opvragen, kunnen ze vast ook wel even via Ajax je mail opvragen gok ik zo....

[mddd]

Ik vraag me af in hoeverre je dit nu een aanval of een bug kunt noemen. De enige manier om dit te voorkomen is door te zorgen dat de client niet weet of het inladen van een bestand is gelukt. Dat is iets wat zo veel voorkomt en zo belangrijk is voor de werking van websites, ik zou niet weten hoe je dat zou kunnen omzeilen. Maargoed, browsermakers zijn slimmer dan ik dus misschien valt er wel wat te bedenken.

[Kalief]

Als je plaatjes alleen mogen worden egtoond binnen de eigen website is het probleem al opgelost. Oftewel hotlinken tegengaan. In dit Gmail-voorbeeld is hotlinken niet verboden voor ingelogden, kijk maar: https://mail.google.com/m...JzlAWxu7-jaBPbDXAjVL8YGpI

[mddd]

Nee, want er zijn veel meer dingen dan plaatjes. Als je een Javascript van een andere site gebruikt kan dat óók verschillend zijn. Denk bijvoorbeeld aan een Facebook 'like' button of iets dergelijks. Maar ook allerlei analytics-achtige dingen. Of puur voor load sharing, de plaatjes op Tweakers komen bijvoorbeeld ook van een ander domein dan tweakers.net zelf.

[Kalief]

Alleen hotlinken verbieden is inderdaad niet voldoende.

Dit artikel nodigt wel uit tot het zoeken van meer voorbeelden.
Welke plaatjes van een site kun je alleen zien als je bent ingelogd op die site?

Mislukt eerste probeelsel: de uitlog button van Mijn ING kun je ook zien als je al uitgelogd bet en is dus geen geschikt plaatje.

https://mijn.ing.nl/internetbankieren/gfx/knop_uitloggen.gif

[Archiebald]

Dat is een oplossing, maar veel grote websites gebruiken Content Delivery Networks, die vrijwel nooit binnen hetzelfde domein als het hoofddomein vallen. Dat heeft ook weer zo z'n reden. Als je statische content laad vanaf een ander domein, dan wordt er geen cookie geraadpleegd, wat weer laadtijd voor de gebruiker scheelt.

[PV85]

Het kan vast wel. Als je een foto laad vanaf een ander domein, dan gmail.com, zou je het altijd kunnen blokkeren bijvoorbeeld.

[mddd]

Ja, maar dan is het middel dus erger dan de kwaal. Er zijn immers tal van toepassingen waarbij het nuttig is om materiaal van andere domeinen te linken. Als ik op dit moment kijk naar de elementen op deze Tweakers pagina, zie ik ook verschillende domeinen de revue passeren.. dat zou dan dus allemaal niet meer kunnen.

[Olaf van der Spek]

Er zijn immers tal van toepassingen waarbij het nuttig is om materiaal van andere domeinen te linken.

Maar over het algemeen is het dan niet nodig op dat andere domein ingelogd te zijn.

Dit is een vorm van Cross Site Request Forgery. Misschien zouden browsers cookies alleen moeten gebruiken voor het domein van de pagina zelf en niet voor third-party domeinen. Ik denk dat we dan van een hoop problemen verlost zouden zijn.

[Reactie gewijzigd door Olaf van der Spek op 23 juli 2024 05:40]

[mddd]

Goed punt. Als je de cookies niet meestuurt naar andere domeinen dan los je dat probleem op, elke request is dan "niet ingelogd".

Aan de andere kant denk ik dat je dan ook weer een hoop truuks krijgt om dit "op te lossen". Bijvoorbeeld: is iets wat in een iframe geladen wordt een pagina op zichzelf? Of telt die inhoud als onderdeel van de omliggende pagina?

En natuurlijk zullen dan ook 'handige diensten' zoals sociale plugins (like buttons, etc) niet meer op dezelfde manier kunnen werken. Maargoed, misschien is dat alleen maar goed.

[Olaf van der Spek]

Of telt die inhoud als onderdeel van de omliggende pagina?

Volgens mij zijn daar al goede regels voor.

En natuurlijk zullen dan ook 'handige diensten' zoals sociale plugins (like buttons, etc) niet meer op dezelfde manier kunnen werken

Misschien is naast httponly een cross-site optie voor cookie handig. Of die buttons moeten zich gedragen als links, zodat het wel weer werkt, maar iets anders.

[M0N0]

Lijkt me inderdaad iets dat gmail etc moet oplossen als ze vrezen voor misbruik, niet de browsers. Webservers kunnen als iets opgevraagd wordt vanaf een ander domein ofwel telkens weigeren, ofwel telkens slagen met iets (cf. anti-hotlink image), maar uit dat iets mag niet af te leiden vallen of de gebruiker ingelogd was, anders is het hele concept weer ondermijnd.

[Tom-ass]

Dat zou betekenen dat elke vorm van hotlinking niet meer mag. Zie ik niet snel gebeuren want dat zou veel sites slopen. Want behalve plaatjes zullen ook veel scripts niet meer werken. Denk aan JSONP.

[Verwijderd]

Als je de broncode bekijkt dan zie je dat in het geval van Gmail bijvoorbeeld de foto gewoon binnen het gmail.com domein gehost wordt en aangezien jij ingelogd bent wordt het verzoek gehonoreerd, immers... jij bent doordat je ingelogd bent als het ware aanwezig binnen het gmail.com domein. Dat het verzoek via een script vanaf een ander domein via/van jouw computer komt of door jouw eigen klik... daar zou wat aan gedaan moeten/kunnen worden. In browser maar ook aan de kant van de site.

[? ?]

Een goede manier om dit te blokkeren (+ alle andere soorten tracking) is het NIET toelaten van verkeer behalve dat van het domein waar je op zit.

Dat wil ik wel eens in een browser/add-on zien. Gedaan met de troep. Zit je op tweakers.net, dan laadt enkel content van tweakers.net, dus geen dingen van google-analytics.com of andere rommel van andere domeinen. Tracking probleem opgelost en dit 'probleem' opgelost.

[B-Man]

Success, dan zou tweakers.net niet meer werken; Immers, tweakers.net laadt een groot deel van alle javascript en plaatjes via een separaat domein (tweakimg.net).

[? ?]

Dat is een foute aanpak. Dat ze een subdomein gebruiken zoals img.tweakers.net !
Websites hebben geen reden om iets buiten hun domein te gaan zoeken !

[crisp]

Het nadeel van een subdomein is dat dan met elke request ook de cookies van *.tweakers.net worden meegestuurd, wat dus nutteloze overhead is. Daarom is gekozen voor een andern (cookie-less) domein.

[MSalters]

Dat is natuurlijk op te lossen door de cookies op *.dynamisch.tweakers.net nivo te zetten, en daar alle cookie-afhankelijke content te hosten.

[crisp]

Bijna alle pagina's zijn cookie-afhankelijk (je sessie wordt met een cookie bijgehouden onder andere en moet dus zowel op tweakers.net als op gathering.tweakers.net beschikbaar zijn), dus dat is simpelweg geen mogelijkheid...

[? ?]

In situaties waar het echt niet anders kan, kan het opgelost worden door een knopje te voorzien om andere domeinen toe te laten. Lijstje 1 keer saven en gedaan.

[B-Man]

Het zorgt er juist voor dat tweakers.net zo snel op je scherm staat als nu het geval is! Het is wel zo dat nieuwe(re) browsers dit soort optimalisaties niet meer nodig hebben ivm meer dan 2 threads per domein, maar het gros van de actuele browsers zit nog wel met die limiet.

Daarnaast zullen grote sites (formaat facebook e.d.) vermoedelijk altijd met CDNs blijven werken, en die zullen altijd vanaf een eigen domein content de wereld in sturen.

[Bosmonster]

Precies. Een afbeelding kun je bekijken of niet. Als je dit "oplost" stort het halve internet in elkaar. Zeker met de focus op embedden, sharing en social media vandaag de dag.

[Reactie gewijzigd door Bosmonster op 23 juli 2024 05:40]

[ReenL]

De site makers kunnen dit zelf oplossen, gewoon een http 200 geven met een "default" plaatje als iemand niet ingelogd is.

Over een jaar hebben we het over hetzelfde probleem, maar dan op basis van de response tijd in plaats van de http-code.

Zie ook:
http://en.wikipedia.org/wiki/Cross-site_request_forgery

[Verwijderd]

Nee, jouw http200 plaatje weergeven gaat niet lukken.

Wat ik mijn script dan gewoon laat doen is kijken of er wel/geen plaatje geladen wordt...

Nu denk je misschien "He, hoe dan?"

simpel; ik zet EERST de javacode die de pagina laat zien (of het http200 plaatje), en daarna een active link detectie met een urlletje naar dat plaatje.

Dus ja, je kan het nog wel omzeilen, door een plaatje met een random gegenereerde naam te laten zien... maar waarom?

Iedereen mag weten dat ik een gmail account heb. Zeker zolang ze niet weten welke, zie ik hier geen grote bedreiging in.

[ReenL]

Zoals MSalters zegt.

Artikel:
"Niet-ingelogde gebruikers kunnen de foto niet bekijken en worden doorverwezen naar de inlogpagina"
Ik:
"gewoon een http 200 geven met een "default" plaatje als iemand niet ingelogd is."

[CyBeR]

Zoals MSalters zegt.

Artikel:
"Niet-ingelogde gebruikers kunnen de foto niet bekijken en worden doorverwezen naar de inlogpagina"
Ik:
"gewoon een http 200 geven met een "default" plaatje als iemand niet ingelogd is."

Dan moet de javascript het plaatje vergelijken ipv de statuscode. Schiet nog altijd niet op.

[azerty]

In hoeveel gevallen worden zo'n afbeeldingen niet dynamisch geladen? Als ze dynamisch geladen worden (image.php?uid=mdkfmsfkemljm) weet je nog altijd niet of er wel of niet een echte foto geladen wordt...

[ReenL]

Externe plaatjes in een canvas (of op een andere manier pixels uitlezen) zou je wel kunnen (en moeten) blocken vanuit een browser. Net als dat je met javascript de content van een extern iframe niet mag uitlezen.

Anders een plaatje met random kleuren in plaats van 1 default. (Prerenderen zodat je execution time niet verschilt met die van een ander plaatje). Of gewoon een oude browser pakken die geen html 5 ondersteund .

[MSalters]

Lukt dus wel. In het ene geval krijg je een HTTP 200 code voor www.gmail.com/example/plaatje.jpg, en in het tweede geval OOK. Het verschil zit 'm uitsluitend erin dat je niet dezelfde pixels terug krijgt. Maar via de Javascript "onload" handler kun je dat niet zien.

[Mellow Jack]

Hmm met een kleine PHP script kan ik kijken of een afbeelding bestaat en alleen laten zien als ik denk dat hij bestaat. Dit zal dus alleen gelden voor publieke pagina's de server en niet de client kijkt dan of hij bestaat In mijn voorbeeldje kan je dus geen eens afbeeldingen uploaden waar een inlog voor nodig is.

Maar toch wel grappig gevonden deze "bug" denk dat heel weinig sites hier rekening mee houden (en de browsers blijkbaar totaal niet )

Toch vraag ik me af of dit nou schadelijk is. Ik kan me dit alleen voorstellen bij site waar de inlog procedure niet goed wordt gedaan (bijv wachtwoorden niet versleuteld versturen oid) maar verder zie ik hier geen echt probleem. Ze kunnen alleen zien dat ik bijv ingelogd ben in Facebook... Nou nou big deal

[Reactie gewijzigd door Mellow Jack op 23 juli 2024 05:40]

[killercow]

Lees het artikel nog eens.

Als jij met je php scriptje gaat pollen of de afbeelding bestaat heb je mijn cookies voor dat domain niet, ben jij dus niet als mij ingelogd, en kunt je dus niet aftasten of ik wel ingelogd ben.

[Mellow Jack]

En heb je het dus onmogelijk gemaakt om aan de hand van een afbeelding te zien of iemand ergens is ingelogd omdat ze heel die afbeeldingen niet kunnen posten op de website

Fijn dat je het artikel wel leest maar mijn post niet begrijpt (Zeg niet dat mijn post nou zo logisch was hoor, maar het was de bedoeling om een voorbeeld te geven wat dit onmogelijk/lastiger maakt)

[Reactie gewijzigd door Mellow Jack op 23 juli 2024 05:40]

[dikkechill]

Een bug wordt gebruikt voor een aanval. In dit geval is het een 'feature' c.q. 'bug' die kan worden gebruikt voor een 'aanval' om meer over iemand te weten te komen.

[i-chat]

dat is dan ook geen aanval maar meer een ongwenst privacy lek... leuk voor bedrijven als google om een nog beter beeld te krijgen van je condoom-maat, of de geaardheid van je 8 jarige dochtertje (om er maar eens 2 tataal onwenselijke voorbeelden bij te halen) maar verder dan dat niet wereldschokkend.

De technisch gemakkelijkste oplossing ligt wat mij betreft bij de gebruiker, doee niet op internet wat je privé wilt houden, en als je het dan toch doet, doe het dan via een 'private browser sessie en/of Tor....

[Tsurany]

Hoe wilt Google nu achter je condoommaat komen of de geaardheid van je 8 jarige dochter? Dan moet Google in zijn eigen pagina's afbeeldingen gaan embedden die enkel op te vragen zijn als jij ingelogd bent op www.condoomsvoorkleinemannen.nl of www.mijndochterislesbisch.nl, meer kunnen ze namelijk achterhalen omdat ze geen idee hebben wat jij op een site doet of naar welke producten je kijkt, enkel dat je een account hebt op zo'n site. Dus tenzij de sitenaam enorm veel prijsgeeft over jou gedrag (zoals in mijn voorbeeld) zullen mensen daar niet snel achterkomen. Als ze enkel zien dat jij op www.viva.nl of www.forum.fok.nl zit om je problemen te bespreken dan komen ze er niet achter wat jij bespreekt.

Trouwens alsof Google überhaupt die moeite zal gaan doen, die hebben al genoeg ads op de condoomwinkels staan om precies te weten naar welke maten jij zoekt
Dit is meer voor sites zoals 4Chan om te kijken wie van hun leden naar www.sexmetdieren.nl gaat of www.facesitting.nl door te kijken of leden wel of niet ingelogd zijn op die sites.

[Reactie gewijzigd door Tsurany op 23 juli 2024 05:40]

[Roland684]

Als een site wat google banners heeft, ziet google wel degelijk welke pagina's jij bezoekt, daar hoeven ze echt geen afbeelding voor te embedden.

[terror538]

nee, de manier om dit te voorkomen is door de client niet te laten rapporteren aan een ander domein dan het domein waar de foto vandaan komt of deze succesvol geladen is of niet

[TheNephilim]

Naar mijn mening inderdaad geen bug. Je moet van tevoren bedenken voor welke site je wil zien of iemand daar ingelogd is. Nogal nutteloos dus.
Het kan me ook een worst wezen of iemand weet of ik wel of niet ingelogd ben bij Gmail trouwens, maar dat ter zijde.

[Flowmo]

Ik vraag me af of dit nu echt een lek is. Je checkt alleen met javascript of het laden van een bepaalde externe bron op een een pagina succesvol is of niet. Meer informatie kan je daar niet uithalen.

Meer informatie haalt de auteur van dit script er niet uit lijkt me. Hij kan alleen weten dat X ip-adres (of user als die is ingelogd op zijn site) op y site is ingelogd. Spannend hoor.

[humbug]

Juist wel. Als je een plaatje kan ophalen van een site die met login sessies werkt betekent dit dat je van alles kan doen in die openstaande sessies. Oftewel mail lezen, een overboeking via paypal, foto's van je prive hyves pagina afhalen noem maar op. Alles wat jij zelf kan doen, kan de externe website dus ook....

[Verwijderd]

Zou het helpen om gewoon niet standaard ingelogd te zijn in bijv google? Of als je de Track-me-not addon installeert?

Ik sluit zelf eigenlijk altijd mijn sessies af voordat ik een pagina verlaat en al helemaal als het om webmail gaat. (misschien met uitzondering van Tweakers.net en GoT )

[Reactie gewijzigd door Verwijderd op 23 juli 2024 05:40]

[Patriot]

Lol, is dit nieuws? Ik heb drie jaar terug al iets gemaakt wat van die 'functionaliteit' gebruik maakte. Dat was overigens voor mezelf, maar ik ben er nooit op gekomen dat het gezien kan worden als een soort bug..

[i-chat]

lol jij gebruikt het daadwerkelijk om te zien op welke sites je nog ingelogd was,

post 's een blog (of forum post ) erover zou ik zeggen, lijkt me best leeswaardig.

[Patriot]

Ik heb het inderdaad gebruikt om te kijken of ik op een bepaalde website was ingelogd, hoewel ik geen gebruik maakte van AJAX. Het is niet echt een spannend verhaal hoor. Ik speelde mee op zo'n text-based spelletje, en daar bleef je maar een bepaalde tijd ingelogd (kon de lengte van de cookies niet wijzigen, was op de server geregeld). Eén plaatje in je 'controlepaneel' op die website was een gegenereerd grafiekje, die gaf een 403 forbidden-header als je niet was ingelogd. Ik maakte zelf een PHP-scriptje dat een groen bolletje gaf als het plaatje doorkwam en een rood bolletje als hij een 403 tegenkwam. Automatische refresh van 10 seconden erop en zo kon ik altijd zien of ik nog was ingelogd.

[jbemmel]

Als je een pagina zou bouwen die een voldoende groot aantal sites checkt op accounts, dan kun je in theorie gebruikers uniek identificeren. De combinatie van alle sites waarop een gegeven internet gebruiker een account heeft is vaak uniek, vooral als je in de check sites zou meenemen met relatief weinig gebruikers.

Zie iedere account check als een bit, en maak een bitstring van alle checks. Dit levert een unieke code, een digitale 'fingerprint'. Zo'n code zou dan wel veranderen als de gebruiker nieuwe accounts aanmaakt of oude opzegt, maar ook daar kun je wat aan doen door 'fuzzy' te vergelijken, i.e. codes te beschouwen als identiek als er slechts een paar bits verschillend zijn.

[Reactie gewijzigd door jbemmel op 23 juli 2024 05:40]

[johnwoo]

Dan zou je wel veel sites moeten gebruiken, om zoveel miljoenen gebruikers uit elkaar te houden... En behalve bekende sites (waar "iedereen" wel lid van is) ook veel regionale sites moeten gebruiken. Ga je dan ook nog fuzzy vergelijken (wat wel moet, i.v.m. inloggen/uitloggen van mensen), dan denk ik dat je heel veel overlap krijgt en het lastig wordt om individuele gebruikers te tracken. Misschien als je het ook nog combineert met user agent...

[humbug]

Niet helemaal. De gebruiker moet namelijk niet alleen een account hebben maar ook zijn ingelogd. Nu is het op sites als tweakers erg makkelijk om altijd ingelogd te zijn, maar bij bijvoorbeeld gmail dwing ik mijzelf om altijd een wachtwoord in te tikken. Bij de hele trits andere websites waar ik een account heb log ik soms in, soms niet. De digitale vingerprint van mij zou dus elke dag anders zijn. Dat is niet zo eenvoudig te vinden

[jbemmel]

Het zou op z'n minst te gebruiken zijn om een user te tracken over meerdere web sites, zonder cookies te gebruiken. Zolang je tussendoor niet in/uitlogt blijft je ID hetzelfde.

Dit geldt natuurlijk ook voor je IP adres, maar dat werkt niet als de gebruiker achter een proxy zit

[Reactie gewijzigd door jbemmel op 23 juli 2024 05:40]

[naarden 4ever]

Dit is toch geen nieuws? Met een simpel PHP script kun je ook de IP's achterhalen an de bezoekers op je website. Wel waar is dat hier iets aan gedaan moet worden.

[Marathir]

Dit gaat ook niet om de situatie dat gmail wil weten of je op gmail bent ingelogd, maar dat ik wil weten of jij op gmail bent ingelogd.

Een soort light versie van een man in the middle attack dus, gezien er verder niets mee bekend wordt.

[Jaccoh]

..

Boeiend?

Ik zie niet direct de problemen hiervan in.

[killercow]

Het probleem niet zien als je geen kennis van zaken hebt, en toch menen dat het geen kwaad kan is de kern van het probleem.

Websites bouwen zonder alle mogelijke gevaren te kennen maakt het mogelijk voor criminelen om creatief met "gelekte" informatie om te gaan en hier wellicht misbruik van te maken.

[Jaccoh]

zo jij durft

Geen kennis van zaken? lol

Maar goed. Ik vind het persoonlijk niet boeien of ik bij gmail ben ingelogd of niet.

[MSalters]

Je, je hebt duidelijk geen kennis van zaken als je denkt dat het niet boeiend is. Dat blijkt ook weer uit deze post. Het gaat er niet om of jij weet dat de bij Gmail bent ingelogd. Het gaat erom of J.Random Hacker kan weten of jij bij de Rabobank bent ingelogd.

[Jaccoh]

Ik zal me niet laten uitlokken tot kinderachtige discussies over kennis van zaken of niet. Kinderachtig vind ik daarin nog een misselijke understatement.

Ik geef hier slecht een mening dat ik het niet erg vind. Mag toch?

Meneer de hacker kan namelijk op zat andere manieren aan dezelfde informatie komen en aan nog veel meer informatie.

Geef mij eens een voorbeeld waarbij het nuttig is om te weten of jij op site X bent ingelogd? En dan heb ik het niet over justituele kwesties (foute sites). Ik durf te stellen dat die kennis of niet heel erg interessant is of makkelijk te verkrijgen is op andere manieren.

[killercow]

Vindt je het niet ontzettend naief om te denken dat jij dit hele probleem voor iedereen in elke situatie kunt overzien?

Genoeg mensen die liever niet aan allerlei websites vertellen op welke sites ze nog meer aangemeld zijn.

Denk alleen maar aan phishing.
Stel, jij bent ingelogd op gmail.

Mijn server ziet dat (want tjah, foutje bij gmail waardoor ik dat kan aflezen),
Jij laat mijn pagina even open staan, en na een minuutje ofzo van geen muis activiteit (je bent op een ander tabje bezig), forward ik mijn pagina naar een site die lijkt op gmail waar ik je login gegevens vraag. 90% van de mensen kijkt niet naar de adresbalk, en die mensen die dat wel doen, doen dat vaak terwijl ze het password intypen (maar die kun je dan ook al uitlezen met javascript)

Je drukt op submit, ik stuur je door naar de echte gmail.com pagina waar je nog ingelogd was en voila jij denkt dat t alleen maar een tijdelijke login reset was die gmail wel vaker heeft.

Zonder informatie over waar jij ingelogd bent is dit een stuk lastiger te raden.

Als ik eenmaal je email en password heb kan ik daarmee natuurlijk al die andere sites waarvan ik kan zien dat je ingelogd bent ook meteen proberen. ontzettend veel mensen gebruiken overal t zelfde email adres en password.

Naief denken dat t allemaal wel goed komt qua security is gewoon ontzettend dom.

[Prototype666]

oke, dus een derde kan achterhalen of je bent ingelogd (bijvoorbeeld sessie koekjes hebt) bij een andere webdienst. nou en?

[jbemmel]

Een web site kan dus checken of jij een Tweaker bent of niet. Zo ja, dan ben je waarschijnlijk man, 20-36 jaar die houdt van gadgets, etc.. Vervolgens kunnen advertenties daarop aangepast worden.

Ook een handige tool voor de politie: installeer een check voor logins op sites die bekend staan als ontmoetingsplaats voor (bijvoorbeeld) kinderpornoverzamelaars op hyves.nl, en vraag vervolgens de profielen op van alle bezoekers die ingelogd waren

[Blackbird-ce]

Is dit niet een enigszins verkapte vorm van cross-site request forgery (CSRF)?

[crisp]

Niet helemaal in die zin dat CSRF meestal tot doel heeft om manipulerende acties uit te voeren op een bepaalde website terwijl deze vorm juist informatie oplevert over een gebruiker van een bepaalde website. Bij CSRF wordt simpelweg een request gedaan en wordt niets gedaan met het resultaat daarvan, hier is juist het resultaat van belang aangezien die de benodigde informatie verschaft.