Google Web Accelerator gevolgen voor sitebeveiliging

Nadat eerder deze week de bètaversie van Google Web Accelerator online ging, is er een stroom van klachten binnengekomen over de functionaliteit van de dienst, aldus eWeek. Gebruikers van verschillende fora hebben gemeld dat ze webpagina's uit het cache ophaalden die de gebruikersnaam van een ander bevatte. Dit is een serieus beveiligingslek, omdat op deze manier gegevens die een ander ingevoerd heeft door een gebruiker van Web Accelerator kan worden opgevraagd. Een woordvoerder legde uit dat dit echter minder erg is dan dat het lijkt. Hoewel de informatie van de gebruiker beschikbaar is, kan niet als die gebruiker gehandeld worden, omdat het hier alleen gaat om een webpagina en niet om een sessie of cookie met authenticatie-gegevens.

Een tweede probleem komt onder andere voor bij de producten van 37Signals LLC. Door op een link te klikken kunnen klanten functies uitvoeren als het verwijderen van records en accounts. Het bedrijf heeft verschillende klachten binnengekregen van gebruikers die onbedoeld hun account hebben gesloten omdat Web Accelerator dacht dat ze van plan waren om op die link te klikken en dat alvast voor hen deed. Google verdedigde zichzelf met de mededeling dat dit komt omdat de producten zich niet aan de webstandaard houden en dat daardoor zijn plugin onbedoeld deze actie uitvoerde. Desalniettemin belooft het bedrijf in overleg te gaan met de bedrijven over hoe Web Accelerator verbeterd kan worden in combinatie met hun websites. Tot die tijd kunnen ervaringen op ons forum worden gedeeld.

Reacties (72)

[SED]

Het is natuurlijk ook niet voor niets een beta. Mensen die betasoftware downloaden en installeren moet zich toch eens verdiepen in de gebruiksvoorwaarden en de mogelijke gevolgen in ee productieomgeving.
Beta software is ok zaken uit te testen en te optimaliseren. Volgens mij doet Google dat nu prima en kunnen ze een hoop nu vorkomende problemen straks voorkomen in het uiteindelijke product.
Dat google hier commerciele belangen bij heeft mag ook niet echt als nieuws gelden.

[k7of9]

Mensen die betasoftware downloaden en installeren moet zich toch eens verdiepen in de gebruiksvoorwaarden en de mogelijke gevolgen in ee productieomgeving.

Dat kan je wel zo zeggen, en zolang het risico van betasoftware beperkt blijft tot degene die het installeert heb je ook volkomen gelijk, maar:

Dit is een serieus beveiligingslek, omdat op deze manier gegevens die een ander ingevoerd heeft door een gebruiker van Web Accelerator kan worden opgevraagd.

Kortom, als ik het goed begrijp kan ik of iemand anders die deze software niet gebruikt het slachtoffer van worden. En dat vind ik het een compleet ander verhaal.

Google kan wel zeggen:

Een woordvoerder legde uit dat dit echter minder erg is dan dat het lijkt. Hoewel de informatie van de gebruiker beschikbaar is, kan niet als die gebruiker gehandeld worden, omdat het hier alleen gaat om een webpagina en niet om een sessie of cookie met authenticatie-gegevens.

Maar ik vind het toch geen prettig idee. En als Google deze kwestie blijkbaar niet had kunnen voorzien, kunnen ze wellicht andere ernstigere zaken momenteel wel over het hoofd zien.

Het nut zie ik in dit tijdperk van breed beschikbaar breedband internet ook niet echt in. So what als je een paar minuten winst kan behalen. Hebben we dan zo'n ontzettende haast allemaal?

[Anoniem: 61096]

Kortom, als ik het goed begrijp kan ik of iemand anders die deze software niet gebruikt het slachtoffer van worden. En dat vind ik het een compleet ander verhaal.

Google cached de request van de gebruikers en levert gebruiker A de resultaten van gebruiker B. Als iemand echter google web accelerator niet gebruikt kan google het ook niet cachen. Oftewel, beide mensen moeten de webaccelerator gebruiken. De gebruiker die de gegevens ziet is niet het slachtoffer maar degene wiens gegevens zomaar gepubliseerd worden. Mensen die hier geen gebruik van maken kunnen hier dan ook geen last van ondervinden.

Wat de gevolgen zijn van dat anderen bij mijn/jou gegevens kunnen is allemaal bijzaak. Gegevens die geheim zouden moeten blijven, worden openbaar gemaakt. En dat is ernstig. Maar dit is tegelijkertijd zoals SED aangeeft een bekend risico van het gebruik van een Beta. Als zoiets in een afgerond product optreed is het een andere zaak. Maar in een Beta? Mwa, lossen we wel op in de volgende beta versie Het hoort er ook een beetje bij.

[Anoniem: 82855]

Ik weet nog dat zoveel mensen zich druk maakte toen er voor Firefox een soort 'Tweak' kwam, om sneller te surfen, waardoor je eigenlijk meerdere verbindingen naar een server maakte en vervolgens 'iets' sneller data kon downloaden van de server, dit kon leidde tot overbelasting van servers.

En nu heeft Google zo'n Web Accelerator die gewoon veel links inlaad die je waarschijnlijk niet zal aanklikken, wat dus ook leid tot onnodige (ergere) belasting van de server. En als je 't aanklikt maakt dat slechts een paar seconden in performance uit. maarja dit boeit de meeste mensen niet zolang ze maar snel kunnen surfen en gelijk hebben ze

Bovendien vind ik het jammer dat Google de Web Accelerator niet heeft uitgebracht voor Linux, Ze vinden Firefox toch goed (Open Source & werkt op meerdere OS'en).

O ja, nu ik 't toch over Firefox & Google heb, aan het begin van dit jaar stond er op de Tweakers Frontpage dat er 2 Firefox ontwikkelaars en ik dacht ook '1 gast van IE'?! (weet 't niet zeker dus quote me daar niet op) en er waren toen ook geruchten dat Google een browser zou maken gebaseerd op de Mozilla Engine. Kennelijk ging 't gewoon om Google Web Accelerator

[thegve]

Hij is voor Firefox. (lees bericht van gisteren maar)

[Anoniem: 134763]

en Internet Explorer want daar heb ik hem ook in draaien

ik geloof vanaf versie 5.5 maar kan ook vanaf versie 6 zijn

[praseodymium]

Ik denk dat het eerder een positief effect heeft voor de servers aangezien er met de Web Accelerator ook een deel van de data van Google's servers komt. Dat houdt dus in dat er uiteindelijk misschien zelfs minder requests naar de server worden gedaan (hoe meer mensen Google's Web Accelerator gebruiken, hoe groter het effect).

[mosymuis]

Dat is zeker zo voor de grootsten der websites, maar de beginnende gaat er niet op vooruit. De kans dat er meerdere mensen al surfende op een kleine website Web Accelerator gebruiken in dezelfde periode is klein, waardoor het voordeel van Google's gecachete pagina's wegvalt. Het onzichtbaar ophalen van pagina's gaat dan wel gewoon door, wat uiteindelijk tot meer dataverkeer leidt naar de originele webserver.

[three2five]

De tweaks in beide gevallen verschillen als ik je post zo lees aanzienlijk. Ik ga nu volledig af op jouw post, aangezien ik zo gauw niks kan vinden over de genoemde tweak neem ik maar een aantal dingen aan.

De techniek verschilt in deze mate dat google links opent waarvan die mogelijk kan denken dat die binnenkort geopend kunnen worden waarbij de tweak die jij noemt gebruikt maakt van meerdere verbindingen met de server. De tweak die jij noemt zal geen beveiligingsproblemen veroorzaken (want de bandwith issue is nog vrijwel niet genoemd, daar gaat het nu ook helemaal niet om), hoogstens nutteloos dataverkeer veroorzaken.

Je vergelijking gaat voor zover ik het kan zien mank wat dat betreft en is een off-topic.

[hiostu]

Google verdedigde zichzelf met de mededeling dat dit komt omdat de producten zich niet aan de webstandaard houden en dat daardoor zijn plugin onbedoeld deze actie uitvoerde.

Met dit soort uitspraken maakt google zich niet populair bij mij. Het kan wel zijn omdat een site zich niet aan een standaard houdt, maar dan hoeft het nog niet te betekenen dat jouw product dat maar op deze manier moet afstraffen.

De laatste tijd heeft google een aantal producten op de markt gebracht waar ik serieuze bedenkingen bij heb. Ik zal ook niet snel dit soort dingen installeren.

Een applicatie die voor mij links op gaat vragen, omdat het DENKT dat ik daar op ga klikken. Nou laat maar, dit hoeft voor mij niet. Ik bepaal zelf wel waar ik op ga klikken.

Stel je voor dat ik op deze manier kinderporno binnenkrijgt omdat de webaccelerator doorklikt op een site waar ik niet naar toe wilde. Dan zou ik daar straks voor aangeklaagd kunnen worden (zie 2 veroordelingen in artikelen over Tonino).

[Blokker_1999]

tweede probleem : welke site is 100% compatibel met alle standaarden? Dat zijn er weinig. Ik vind het dan ook enorm spijtig dat google zich achter zulk excuus verschuilt.

[Reinstein]

idd, dat zijn er heel weinig, en het mooiste is nog dat hun eigen site ook niet voldoet aan de standaard

http://validator.w3.org/check?verbose=1&uri=http%3A//www.google.nl/

[TD-er]

Of nog leuker. Op de site van Demon staat bij Mijn DSL-express de link "opzeggen Demon DSL" vlak in de buurt van "Status van aanvraag" en nog wat andere nuttige links.
Als in een keer een hoop mensen Demon op gaan zeggen om wat voor reden dan ook en ik wil kijken hoe mijn aanvraag staat genoteerd, dan besluit die web-acc. software ineens dat ik mijn verbinding op zou willen zeggen?

Lijkt me een duidelijk voorbeeld van een functie die je niet wilt, terwijl de site toch wel aan de standaarden voldoet.
Mijn voorbeeld van Demon geeft niet aan dat er ineens veel mensen het willen opzeggen, maar meer een onlogische pagina-indeling die hiermee heel erg vervelende gevolgen kan hebben.

[jochemd]

Als Demon dat een link "opzeggen Demon DSL" op haar site heeft staan en het volgen daarvan leidt tot het opzeggen van de ADSL aansluiting dan voldoet de Demon website in tegenstelling tot wat jij zegt niet aan de standaarden. RFC 2616 zegt specifiek:

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".

Google heeft absoluut gelijk dat ze zich aan de standaarden houden. Webdevelopers moeten gewoon eens van hun luie reet afkomen en zich aan standaarden gaan houden.

* 786562 Yoshi

[TD-er]

Dat is een heel interesant punt wat je nu aandraagt en IMHO onterecht op "Overbodig" gemod.
Ikzelf heb nog nooit op die link geklikt, dus ik zou niet precies weten wat er op volgt. Mijn gezonde verstand zegt dat je een bevestiging moet aanklikken of een mailtje moet replyen, maar dat is niet iets wat je met 100% zekerheid zou kunnen voorspellen.
Stel dat je het wel kunt opzeggen door een series van links klikken, dan is het dus niet ondenkbaar dat een product als deze accellerator dat voor je kan doen, wanneer dat een zeer populaire combinatie is op dat moment.

Iets anders, als iets in een RFC- staat dan wil dat toch nog niet zeggen dat het een standaard is? RFC staat toch voor Request for Comment.

[Anoniem: 35352]

Lees http://www.ietf.org/rfc/rfc2119.txt

4. SHOULD NOT
This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

Komt er dus op neer dat zowel Google als die sites een zeker verantwoordelijkheid hebben hierin.

[berend_engelbrecht]

"the convention has been established" betekent niet dat dat een ijzeren standaard is. sowieso houdt een tool die ongevraagd links volgt zich niet aan de conventions die have been established voor web browsers

[Olaf van der Spek]

Iets anders, als iets in een RFC- staat dan wil dat toch nog niet zeggen dat het een standaard is? RFC staat toch voor Request for Comment.

Ach, wat is precies een 'standaard' dan?
Ook bij browser history is het zo dat GET safe is om te rerequesten en POST niet.

dan is het dus niet ondenkbaar dat een product als deze accellerator dat voor je kan doen

Klopt. Maar dat is toch de fout van de site waarop dat mogelijk is?

[Little Penguin]

Met dit soort uitspraken maakt google zich niet populair bij mij. Het kan wel zijn omdat een site zich niet aan een standaard houdt, maar dan hoeft het nog niet te betekenen dat jouw product dat maar op deze manier moet afstraffen.

Het staat buiten kijf dat Google er voor moet zorgen dat hun producten ook werken op site die niet aan de standaarden voldoen. Waarom hebben we anders een HTTP/1.1 standaard, het probleem is dat er heden ten dage veel te veel ontwikkelaars zijn die via trial-and-error aan ontiwkkeling doen.

...maar aan de andere kant legt Google hier wel een probleem van het huidige internet bloot: Omdat de sites niet aan de standaarden voldoen kan men hier dus ook niet onbeperkt gebruik van maken.

Een applicatie die voor mij links op gaat vragen, omdat het DENKT dat ik daar op ga klikken. Nou laat maar, dit hoeft voor mij niet. Ik bepaal zelf wel waar ik op ga klikken.

Hoe zou men anders de surfbeleving moeten versnellen? Als je dit soort gedrag niet wilt dan moet je dit soort applicaties gewoon niet installeren.

Het enige alternatief is dat de website-bouwers zelf via links die link pre-fetching triggeren (zoals in Firefox ingebouwd zit) de gebruiker tegemoet komt.

Edit: Beetje aangepast qua inhoud...

[Anoniem: 35352]

Hoe zou men anders de surfbeleving moeten versnellen? Als je dit soort gedrag niet wilt dan moet je dit soort applicaties gewoon niet installeren.

De simpelste manier om de "surfbeleving" te versnellen zijn server-side optimalisaties en/of meer bandbreedte. En correcte caching-headers zijn uiteraard ook belangrijk.

Het enige alternatief is dat de website-bouwers zelf via links die link pre-fetching triggeren (zoals in Firefox ingebouwd zit) de gebruiker tegemoet komt.

Dat lijkt me een veel betere oplossing voor het "probleem" dat Google probeert op te lossen.

[Theadalus]

Een woordvoerder legde uit dat dit echter minder erg is dan dat het lijkt. Hoewel de informatie van de gebruiker beschikbaar is, kan niet als die gebruiker gehandeld worden, omdat het hier alleen gaat om een webpagina en niet om een sessie of cookie met authenticatie-gegevens.

Ik neem aan dat bv een email-adres, waarvan je hebt aangevinkt dat deze niet getoond mag worden aan derden, op deze manier dus wel beschikbaar is

Ik vind dit nogal een redelijke groffe fout, en vervolgens loopt die woordvoerder dat een beetje te bagataliseren

[Roland684]

Wat een storm in een glas water zeg...
Die sites die nu de mist in gaan zullen vast al wel eerder problemen gehad hebben. Heel vroeger hadden we al internet-accelerators (Netsonic, Copernicus, etc.) die vrolijk alvast de links in een pagina ophalen (soms zelfs compleet met alle plaatjes), voor het geval je ze wil gaan klikken. De Mozilla suite ondersteund dat ook.

In principe mag elke GET alvast gedaan worden. En ook proxies mogen die request cachen en/of preloaden.
Sja, als je dan links maakt die belangrijke acties uitvoeren, dan heb je zelf een probleem gecreeerd. Dat hoor je middels POST requests te doen.

[praseodymium]

Dat is ook wat google bedoelt met hun standaarden.

En Mozilla doet iets anders, zie http://www.mozilla.org/projects/netlib/Link_Prefetching_FAQ.html - de webmaster moet zelf opgeven wat er geprefeched mag worden (Google's Web Accelerator ondersteund trouwens ook mozilla's prefetch-idee).

[three2five]

Dit is al door meerdere gebruikers door een vrij simpele analyse voorspelt en door een aantal andere gebruikers (op deze site alleen al!) bevestigt, door een simpele test. Waarom kon Google dit dan niet voorzien?

[un1ty]

Het valt wel te voorspellen.
maar bij mij heeft het nu al
10.7 minuts
gescheeld
op 1 uur internetten.
das toch redelijk netjes, wel jammer van die lek.
maar dat word vast wel gefixed,
als ze nou alleen de html (xhtml, en andere _veilige_) pagina's zouden laden?
en dan SSL en Login secured PHP enz. met rust laten.

@riffey:
nee heb tests gedaan.
paar sites met laadtijd eronder.
getest met en zonder google site accelerator.
met ging ongeveer 0.013 seconde sneller, op een alleen PHP based site.
met plaatjes erbij ongeveer 0.3 seconde sneller.
dus ja scheelt wel
en dat kan makkelijk
1/3e gaat telkens sneller
zou je op 1 uur toch op 20 minuten moeten komen.
maargoed, sommige site hebben nou eenmaal meer/minder plaatjes
dus kom je uiteindelijk op 10 op de 60 minuten sneller

(wel telkens cache en cookies geleegd tussendoor natuurlijk.)

[riffey#4]

Heb je dat gemeten of geloof je wat de webaccelerator zegt?
In een aantal minuten "zwaar surfen" (van alles aanklikken, gewoon om veel traffic te genereren) had ik ook een kwartier "bespaard" terwijl ik de indruk had dat het allemaal net wat trager ging.

Jij bent zo iemand die een product VAN! 1,99 VOOR! 1.49 ziet gelooft dat ie 50 cent bespaart, terwijl het product normaal maar 1,29 kost, en je dus voor 20 cent genaaid wordt

[Olaf van der Spek]

zou je op 1 uur toch op 20 minuten moeten komen.

Load jij elke seconde een nieuwe pagina dan?

En dat de plaatjes wat later zichtbaar zijn betekent niet dat de site tot dat moment niet bruikbaar is.

[un1ty]

ehh, ik weet niet of je het weet,
maar hij meet alleen voor elke klik. (lees: elke keer dat hij moet laden)
hij meet alleen dè laadtijden.

en 1 uur is dan dus laadtijd

[maurad3r]

als ze nou alleen de html (xhtml, en andere _veilige_) pagina's zouden laden?

Je kunt als client helemaal niet weten of een pagina statishc dan wel dynamisch is, je kunt apache ook instellen zodat hij html-paginas als php parsed en anderzom.

En meestal zijn de pagians met een login ed de paginas die het zwaarste laden

[mosymuis]

als ze nou alleen de html (xhtml, en andere _veilige_) pagina's zouden laden?
en dan SSL en Login secured PHP enz. met rust laten.

Heb je enig idee hoeveel dynamische pagina's toch de extensie .html dragen? Dit is ook al aan Google te danken, die in zijn zoekalgoritmes meer waarde hecht aan statische informatie (hoewel het dat vaak niet eens zo is).

[J.J.J. Bokma]

Denk je dat Google dit niet had voorzien? Natuurlijk wel. Men moet zich gewoon schikken naar Google, en als dat te veel klachten oplevert, wellicht dat het dan iets aangepast gaat worden. Wellicht met een uitbreiding zoals: rel="noaccelerate"

[trogdor]

Als php denkt dat je geen cookies ondersteund krijg je van die lange bagger session id's in je urls als work around.
Worden die ook gecashed dan, en krijg je dan ook de urls van iemand anders?
Want dan neem je dus wel degelijk iemands sessie over, ongeacht wat google beweert.
Slechte zaak lijkt me.

[mosymuis]

Ik denk/hoop dat de Web Accelerator adressen met ?PHPSID= en soortgelijke parameters wel herkent en de nek omdraait, maar bij websites met alternatieve SID namen kan dit wel tot problemen leiden, ja. Zelfs Hotmail had ooit een dergelijk lek, waarbij het GET URL enkel al genoeg was om in te loggen.

[Darude1234]

Ik denk dat Google met deze tool flink de mist in gaat en zou als ik hun was, die tool ook maar snel weer van de website halen, voordat ze weer allerhande aan rechtzaken en schadeclaims krijgen. Het is op zich een goed bedoelde en slimme tool, maar er moet nog wel flink aan geknutselt worden.
Kunnen ze er niet iets in bouwen, dat de sessie aan het ip-adres koppelt, net zoals bij Tweakers.net?

/off-topic aan de sessions bij tweakers moet ook nog wat geknutseld worden. Ik zit nu in een sessie van: 07-05-2006 19:17

[DLGandalf]

er is geen perfecte manier om iemand op het internet uniek te identificeren, veel mensen die met AOL internetten hebben dezelfde ip(ivm proxy enzo), dus een ip tabel bijhouden heb weinig nut

[DLGandalf]

naar mijn mening is phpMyAdmin een goeie app.. toch zou de googlecache geval al een hoop schade aan kunnen richten

[mosymuis]

Een erg raar voorbeeld, juist omdat phpMyAdmin heel netjes om bevestiging vraagt bij elke GET actie.

[Gomez12]

Juist ja een bevestiging. Sommige zijn javascript die gewoon genegeerd worden door google cache en sommige zijn page-based ( als je een table probeert te verwijderen etc. ) Dus je kan geen tabellen verwijderen, maar wel gewoon een serie losse records...

[mosymuis]

Dat zie je toch verkeerd. phpMyAdmin vraagt voor élke actie een bevestiging, automatisch in JS, of bij een directe GET een POST bevestiging. Ik heb dit gecontroleerd in v2.6.0-rc1.

[Upsilon]

Die web-accellerator lijkt me totaal niet nuttig als je toch al bijna geen laadtijd nodig hebt. Ik heb momenteel een 8MBit lijn en wachttijd heb ik bijna niet. Vraag me af wat de Web Accelerator mij nog kan bieden.

Het komt me trouwens aardig bekend voor, dat beveiligingslek. Had Desktop Search ook geen last van een soortgelijk lek?