XSS-exploit door Microsoft betiteld als 'by design'

Eind vorige maand werd Tweakers.net-ontwikkelaar Tino Zijdel door een bezoeker op een bug in Internet Explorer 6 en 7 gewezen die het mogelijk maakt een cross site scripting-exploit uit te voeren. Het lek situeert zich in de mimetype-detectie van de browser.

Zijdel lichtte Microsoft op 29 april in, waarbij hij twee concepten van mogelijk misbruik demonstreerde aan de softwareontwikkelaar. Het eerste voorbeeld maakte gebruik van een geldig gif-bestand, maar dan geserveerd als 'image/jpeg'-mimetype. In voorkomend geval dat de extensie niet aansluit bij het geserveerde mimetype, probeert Internet Explorer dit type zelf te bepalen, maar daarbij negeert de browser de gif-signature van het bestand. In plaats van als afbeelding, wordt het bestand daardoor behandeld als html-code, met als gevolg dat de javascriptcode in het bestand uitgevoerd wordt. Doordat het hierbij wel om een geldige gif-afbeelding gaat, kunnen heel wat sites waar afbeeldingen geüpload kunnen worden, misbruikt worden als zij op basis van de extensie bepalen dat een 'image/jpeg'-mimetype meegestuurd moet worden.

In een tweede proof of concept, wordt een png-bestand met een text-extensieblok geserveerd. In dit blok wordt een stukje javascript-code als commentaar geplaatst. Het meegeleverde mimetype is correct en wanneer de afbeelding in een img-tag geplaatst wordt, is er dan ook niets aan de hand. Bij toegang via een rechtstreekse link, wordt de html en het script in het png-bestand echter uitgevoerd. Volgens Zijdel illustreren beide voorbeelden een schending van RFC2616 met betrekking tot HTTP/1.1. Daarin wordt namelijk bepaald dat een browser alleen mag proberen het mimetype te raden als er geen Content-Type-veld meegestuurd wordt door de server.

Opvallend genoeg verklaarde Microsoft tegenover Zijdel dat het gedrag van Internet Explorer als dusdanig bedoeld is en dat het bedrijf dan ook niet van plan is hier een patch voor te schrijven. Wel zal er bij een volgende IE-versie aandacht aan het probleem besteed worden. Volgens een medewerker van het Microsoft Security Response Center, is het niet aangewezen om het gedrag van Internet Explorer op dit moment te wijzigen, omdat siteontwikkelaars wellicht gebruikmaken van de functionaliteit die de browser met zijn mimetypedetectie biedt. Aan het xss-exploit-gedeelte wordt daarbij echter volledig voorbijgegaan. Ook tegenover de redactie van Tweakers.net verklaarde het Internet Explorer-team dat de handelingen van de browser 'by design' zijn.

Een eerste argument van de ontwikkelaars is dat het de bedoeling is dat Internet Explorer scripts hoort uit te voeren als het om een bestand gaat dat zowel een afbeelding als een script is. Daartegen kan ingebracht worden dat een bestand ofwel een afbeelding ofwel een script is, maar het tweede argument is nog gemakkelijker te weerleggen. Microsoft beargumenteert namelijk dat het zo gemakkelijker is om bestanden zonder, of met een incorrect mimetype, te behandelen. In het png-voorbeeld wordt echter een correct mimetype meegestuurd, en bij het foute mimetype van het gif-voorbeeld zijn er enkele redenen om de content toch niet als html te behandelen:

• Het opgegeven mimetype impliceert binaire data
• Het bestand is een geldige gif-afbeelding, inclusief de bijhorende signature
• Het bestand bevat, naast wat als html gezien kan worden, ook binaire data. Daaruit kan door het content-sniffing-mechanisme afgeleid worden dat de content niet fatsoenlijk als tekst of html getoond kan worden.

Tot slot schuift Microsoft de verantwoordelijkheid af op site-uitbaters, door hen aan te raden gegevens te filteren op basis van de inhoud van bestanden. Concreet betekent dit echter dat websites binaire data moeten gaan weren omdat de gegevens mogelijk pas 'kwaadaardig' worden op het moment dat de browser op een foute manier met de mimetypes omgaat. Het is overigens wel mogelijk de mimetype-sniffing-engine uit te zetten, maar aangezien deze op zowel Windows XP als Windows 2003 en op systemen met Internet Explorer 7 standaard aan staat, lijkt het veilig te veronderstellen dat de meerderheid van de systemen kwetsbaar is.

Vanaf SP2 voor Windows XP is het mogelijk mimetype-sniffing uit te schakelen.

Reacties (110)

[elmuerte]

Er is redelijk wat web software die niet altijd de correcte mime mee stuurt, bijvoorbeeld per definitie de image/gif ook al is het een jpg of png.
De type is nog altijd image en geen text, alleen de subtype is verkeerd. En zoals MIME opgezet is zal de user agent niks anders mogen proberen dan het als image te hanteren. text/html of text/javascript is dan way off.
De regel in de HTTP/1.1 RFC heeft alleen betrekken op het volledig ontbreken van de Content-Type header, wat bijna nooit voorkomt. Het zegt niks over het correct afhandelen van de subtype van de MIME. Dus het excuus van MS gaat niet op.

[Anoniem: 26362]

Nu in Jip en Janneke taal graag

[Wilke]

Goed, in Jip en Janneke taal:

Een website bestaat doorgaans uit verschillende soorten onderdelen, bv. een HTML pagina, een CSS pagina en verschillende plaatjes. De webserver geeft aan de browser door van welk type elk geladen onderdeel van een website is. Dit heet het MIME-type.

Dit wordt dus *niet* bepaald door wat er toevallig aan het eind van de URL staat, zoal bijvoorbeeld .html of .jpg.

Helaas denkt IE echter slim te moeten zijn, en override het door de webserver meegegeven type als het denkt het beter te weten, bij mijn weten zowel aan de hand van waar de URL toevallig op eindigt als aan de inhoud (!) van de geserveerde content. Dit gevoegd bij een HTML-parser die zo tolerant mogelijk is (dus alles wat hij niet begrijpt maar gewoon overslaat en probeer er nog maar het beste van te maken), levert een wereld aan mogelijkheden voor exploits op.

Zo kun je bijvoorbeeld bij veel websites plaatjes (bv. icon, avatar) uploaden, en ondanks dat de site aan de browser vertelt "dit is een plaatje" ziet IE dat er toevallig HTML of javascript tags in staan, en override het type naar wat het denkt dat het moet zijn. En zo zou een willekeurige gebruiker dus via een user-icon zoals op bv. het forum alhier IE zo ver kunnen krijgen dat het vreemde (bv. javascript) code gaat uitvoeren.

MS ziet zowel het automatisch aanpassen van MIME-types als het tolerant parsen als "feature" omdat verkeerd geconfigureerde webservers wel eens het verkeerde MIME-type opgeven en dit zo automagisch gecorrigeerd wordt. Idem voor "brakke" HTML-tags. Of andersom gezegd, omdat IE de meest gebruikte browser is, checkten vroeger veel websitebeheerders niet of hun server de MIME-types wel goed zette, want "in IE werkt het toch wel". Idem voor HTML-validatie.

Als ze het nu dus "fixen", werken sommige (brakke) sites mogelijk niet meer in IE. Als ze het niet "fixen", is IE exploitable. Wat je noemt een lose-lose situatie. Ze hebben de kuil echter voor zichzelf gegraven..

[Dreamvoid]

Zonder hier heel erg de MS advocate te worden (incorrecte type detectie lijkt me gewoon een bug, ook al gebruik je het nuttig en 'by design'), maar: het feit dat scripts uitgevoerd kunnen worden is toch geen probleem? Dat kan via elke normale webpagina immers ook. Het is pas een probleem als die scripts schadelijke dingen kunnen doen, en dat moet elke browser afvangen, IE of niet. Of zie ik hier iets over het hoofd?

Daarin wordt namelijk bepaald dat een browser alleen mag proberen het mimetype te raden als er geen Content-Type-veld meegestuurd wordt door de server.
Oftwel, volgens deze RFC moet een browser dus, als je een plaatje met script linkt zonder content-type, ineens wel die scripts uitvoeren? Het probleem zit zich hier dan niet in het feit dat IE de RFC niet volgt, maar in het feit dat die RFC gewoon niet deugt en dat de browser veel 'strenger' dan de RFC moet zijn.

[Wilke]

Het is pas een probleem als die scripts schadelijke dingen kunnen doen, en dat moet elke browser afvangen, IE of niet. Of zie ik hier iets over het hoofd?

Ja en nee. Hier zijn twee problemen mee, een daarvan is specifiek voor IE, het andere kan in principe bij alle browsers gebeuren, al maakt IE het in sommige opzichten makkelijker voor crackers.

Het algemene probleem is dat in alle browsers de vraag of iets wat een script probeert te doen "schadelijk" is afhangt van de context. Bijvoorbeeld, als ik navigeer op de site tweakers.net mag een script op deze site natuurlijk het cookie van tweakers.net opvragen (dat is het hele idee van cookies, tenslotte). Echter, mocht ik mij bevinden op tw34kz0r.net dan mag een script op deze site zeker niet het cookie (dus session_id, react_id...) van tweakers.net op kunnen vragen. Of een actie van een script schadelijk is, hangt dus af van de context waarin het wordt uitgevoerd.

Het hele idee van XSS (cross site scripting) is dat je een browser laat denken dat je op een bepaalde site bent (en dat het opvragen van bv. een cookie daarvan dus OK is), terwijl dit feitelijk niet het geval is. Problemen daarmee komen vrij regelmatig in verschillende browsers voor, IE maakt het in sommige opzichten echter wel makkelijker dan gewoonlijk doordat allerlei "autocorrigerende" features het makkelijker maken om dingen voorbij de security checks te loodsen.

Een ander probleem, dat in ieder geval in deze vorm specifiek voor IE is, is het gebruik van security zones om te bepalen wat wel en niet mag. Als een script bv. in de lokale security zone uitgevoerd wordt, mag het heel veel. Een ander veel voorkomend soort exploit is erop gebaseerd dat ze de browser laten denken dat een script in de lokale security zone moet draaien (en dus praktisch alles mag), terwijl het toch echt van een remote (en dus onveilige) locatie komt.


Kort samengevat: het tricky deel zit 'm voor de browser in het bepalen van wat schadelijk is en wat niet, want dat hangt af van allerlei omstandigheden. Als je het beslissingsproces van de browser voor de gek kunt houden door gunstige omstandigheden te "faken", kun je dus toch dingen doen die niet mogen.

[Anoniem: 199920]

MM, hoe vaak word er wel niet naar plaatjes gelinkt buiten het eigen domein? Op dat moment heb je dus een script draaien binnen je eigen domein terwijl je er niks van af weet.

Misschien duidelijker.
Je hebt admin gedeelte in je cms, in dat admin gedeelte na vigeer je door middel van gif buttons. De buttons heb je van een site gedownload. Dus nu je in gelogd bent, kan het script in die buttons dus gevoelige informatie doorsturen naar een 3e.

Het blijft dus zeker een probleem.

[YaPP]

het feit dat scripts uitgevoerd kunnen worden is toch geen probleem? Dat kan via elke normale webpagina immers ook. (...) Of zie ik hier iets over het hoofd?

Je ziet inderdaad iets over het hoofd.

Als voorbeeld:
- je hebt een site met foto upload (bijvoorbeeld hyves)
- je hebt controles toegevoegd zodat bezoekers geen JavaScript code of PHP kunnen uploaden

Stappenplan:
1. upload een foto met JavaScript op de server. Deze komt door de controles heen omdat het een geldige afbeelding is.
2. Wacht net zolang totdat een bezoeker of admin de foto met MSIE download.
3. Laat de JavaScript code de sessie cookie opsturen.
4. Gebruik de sessie cookie om nu zelf in te loggen op de site.
5. Gebruik de evt. admin sessie om de site vanuit het beheer paneel te hacken. Bijvoorbeeld omdat je daar wel willekeurige files kan uploaden.
6. hack de server nu compleet vanuit de geuploade PHP code.

[Gyske]

Je hebt in principe gelijk. Maar het gaat er hier om dat de scripts verborgen zitten in een plaatje niet in een HTML-document. En wanneer IE dit plaatje probeert weer te geven wordt deze code wordt uitgevoerd. Klik maar eens op dit linkje (met IE): plaatje met code Dit is hetzelfde Opera-plaatje dat in de bovenstaande tekst staat, maar dan direct gelinkt.
Je zult merken dat je een popup met de tekst: 'toedelidokie' krijgt. Met een andere browser dan IE krijg je dit (waarschijnlijk) niet.

[Dreamvoid]

1. upload een foto met JavaScript op de server. Deze komt door de controles heen omdat het een geldige afbeelding is.

Dit moet de controle natuurlijk checken! Wat voor zin heeft een scriptfilter nou als het geen embedded text meeneemt? Zo komen (om maar iets te noemen) mp3's met in de tag embedded scripts ook gewoon door je checks heen.

Want als ik die RFC zoals die hierboven staat goed lees moet een nette standard-compliant browser ook gewoon dat script draaien als er geen mime type gepecificeerd is (de bug in IE zoals hier gemeld is dat het ook doet als een verkeerd mime type gespecificeerd is).

[Cybergamer]

@ Gyske:

Idd! Zojuist getest met Firefox en dan krijg ik het plaatje. En als ik Hetzelfde plaatje open met IE7 dan zie ik die popup.

Grappig eigenlijk dat dat zomaar mogelijk is!

[DDemolition]

Door javascript aan de headers te hangen kun je javascript uit laten voeren en dus bijvoorbeeld een cookie jatten.
Als je naar de broncode van het png bestandje kijkt zie je alert() staan

[Janoz]

Een voorbeeld van een mogelijke exploit:

In het kort komt het er op neer dat je bijvoorbeeld op flickr, hyves of het tweakers fotoalbum een speciaal gemaakt plaatje kunt uploaden en vervolgens de inlogsessie van alle gebruikers die het plaatje oproepen kunt achterhalen en dan onder hun naam in kunt loggen.

[aequitas]

MS: Meneer deze auto kunt u met uw mobieltje openen.

Klant: Stuurt mijn mobieltje dan een geheime code of zo.

MS: Ja dat doet hij, maar daar doet de auto verder niets mee. Anders zou je een nieuwe auto moeten kopen als je een nieuw mobieltje krijgt. Hij controleert gewoon op de aanwezigheid van GSM straling.

[Randal]

--

[Randal]

Echt onbegrijpelijk dat de vraag van Markiedam als overbodig wordt weggemod. Ik kan helemaal inkomen dat er aardig wat lezers zijn die er niks van begrijpen.

Als je een post beoordeelt, doe dit dan obv de bijdrage en niet enkel obv je eigen kennis of mening.

[theXE]

Het is mij wel helder, vind alleen de opmerking reactie van Microsoft opmerkelijk. Voorlopig hebben hack-/crackers dus even vrij spel tot sowieso IE8?

[YaPP]

Voorlopig hebben hack-/crackers dus even vrij spel tot sowieso IE8?

Dat hebben ze toch al.

Als je een forum programmeert, heb je bijvoorbeeld de volgende extra controles nodig voor Internet Explorer. Anders zijn je bezoekers (en daarmee je site) kwetsbaar voor XSS aanvallen.

Wat voorbeelden voor forum software:
- Bij [img=url] moet je extra controles toevoegen
MSIE accepteert <img src="javascript:"> als feature.
- Bij [color=blue] moet je oppassen
MSIE accepteert <span style="color: expression(javascript)"> als feature.
- Bij controles op "javascript:" ben je niet veilig.
MSIE accepteert "java<enter>script:" als feature (of bug)
Door deze fout is MySpace gehacked.
- En nu moet je dus bij binaries oppassen.
MSIE accepteerd een <script> daarin als feature.

Wat ik aan Microsoft's reactie zo storend vind is dat iedereen er maar achteraan moet hobbelen. Op alle niveau's van het Internet wordt rekening houden met Microsoft. [1] Ik zie liever dat ze meer gaan kijken naar de ontwikkelaars/community die websites bouwen, dan dat iedereen maar "volgeling" moet zijn. Voor het programmeren van sommige functies kost het mij significant meer uren als het ook in MSIE moet werken. Het wordt tijd voor wat concurrentie die hun wakkerschud.

[1]: en daarmee bedoel ik: de apache configuratie, afhandeling van https, je html code, css2 code, ingewikkelde JavaScript code, headers vanuit php uitgelezen of verstuurd, en meer input validaties.

@PolarBear: Bij IE is het echter zo dat er meer varianten van input gevaarlijke output geven; zie het lijstje hierboven. Je moet je site extra aanpassen om veilig te blijven.

[PolarBear]

Ja dus? Zelfs zonder IE moet je alle userinput tot uit den treure controleren. Nooit uitgaan van een ander, altijd zelf controleren!

[XplodingForce]

Natuurlijk moet je altijd user-input controlleren, maar MS maakt het met IE dus nog veel moeilijker omdat ze zich niet aan de standaarden houden. Het is niet fijn natuurlijk dat je daardoor nog meer werk hebt.

[Anoniem: 133254]

`even'? Als MS het OK vindt, dan blijft het nog wel een jaartje in IE7 --- is nog erg nieuw, naar IE-standaarden --- en heeft dus de komende 5jaar zo'n 30% van de pc's dit draaien. [Ik maak op uit de tekst dat het ook voor oudere versies als IE6 opgaat, vandaar mijn natte-vinger-cijfer.]

[de Rochebrune]

MS wil geen patch uitbrengen. Lekker dan zeg.

Het is overigens wel mogelijk de mimetype-sniffing-engine uit te zetten <...>

Ik zou graag willen weten hoe ik dat kan doen. Weet iemand dat toevallig?
(Lijkt me ook handig om in het artikel te vermelden hoe dat moet!)

edit:
Stond inderdaad in de kleine lettertjes...sorry, overheen gekeken.
Bedankt alledrie. En mieJas, bedankt om het te posten hier.

[elmuerte]

Als je even kijkt naar de beschrijving van het onderste plaatje zie je als het goed is een link.

[RobIII]

Even verder kijken dan je neus lang is (hint: onder het plaatje)

[Anoniem: 20531]

Ook leuk om te vermelden wie die bug nou heeft gevonden. Eer Wie Eer Toekomt !

Verder natuurlijk niets nieuws onder de zon...

[mieJas]

Internetopties - tabblad Beveiliging.
Klik bij Internet op Aangepast niveau.
Onder Diversen, zie je als eerste optie "Bestanden openen gebaseerd op inhoud, niet op extensie". Als je dat op Uitschakelen zet, zie je gewoon de Opera afbeelding.

sloebers ook ^^

[soulrider]

dus maw: voor elk systeem dat hierdoor wordt geinfecteerd, kan/mag de rekening naar microsoft gestuurd worden?
omdat zij weet hebben van deze security error en verzaken er iets aan te doen ?
omdat zij express een fout in hun design inbouwen en aanwezig laten....

ik hoop ergens dat er snel wat russen ofzo opduiken om hiermee redelijk wat systemen mee te infecteren, zodat ze bij microsoft ook snel bijdraaien - de kiekens...


//edit na test thuis op een pc met IE 6 op Win XP - SP1
(ja dat lees je goed )

Vreemd genoeg krijg ik hier thuis de rechtstreeks link naar de png ook netjes zichtbaar in mijn IE, en dus geen rare tekens en een javascript pop-up.

en dit zonder de vermelde 'oplossing' te gebruiken.

Net voordat de png zichtbaar komt krijg ik namelijk quicktime die even laad en dus dienst gaat doen als png-toner:

goeie manier van microsoft om reclame te maken voor de software van de concurrentie

met andere woorden: wil je veiliger zijn met de IE op je systeem: zie dat quicktime player op je systeem staat en tijdelijk geassocieerd wordt aan png-files
(en zet dat nadien terug op je standaard programma)
ben je voortaan ook veilig voor zulke exploits
(tot ze dat gaan combineren natuurlijk)

//edit2: schijnbaar werkt deze laatste truc enkel na een download en het te saven als 'all files' en dan .png
ipv het standaard voorgestelde 'html-file' en extensie .png
dan werkt de png wel correct local (ook via locale webserver)

de png hier in het artikel geeft nog steeds een pop-up
dju en ik dacht van handig opgelost

[timonb]

Nee de rekening mag je zelf houden. MS geeft toe dat het een fout is, maar dat de fout wordt veroorzaakt zonder dat MS daar zelf direct de oorzaak van is.

Hetzelfde zou zijn als je in je Ferrari 230 km/u over de A1 raced. Je wordt geflitst en dat je Ferrari de boete toestuurt. Omdat jij vindt dat ze geen auto mogen maken die harder mag rijden dan de maximaal toegestane snelheid.

[Janoz]

Absoluut niet. Hier is eerder sprake van een slotenmaker waarbij blijkt dat je deze met een simpele loper ook gewoon open kunt krijgen. Normale actie zou zijn om een sloten update uit te rollen (dat gaat met software een stuk makkelijker), maar de slotenmaker roept dat ze dat niet gaan doen omdat het zo bedoeld is en dat de schoenmakers maar gewoon moeten zorgen dat ze niet perongeluk een loper verkopen.

[timonb]

Er is absoluut geen sprake van een slotenmaker. IE is een programma dat bedoelt is om code uit te voeren, wel te verstaan HTML code of code volgens een MIME standaard. Dat de gebruiker niet een plaatje maar een text bestand toont is toch niet iets waar MS iets aan kan doen.

Dan zou MS ook moeten voorkomen dat gebruikers geen toegang tot internet heeft, geen USB sticks, cd's en dvd's gebruikt want die kunnen immers ook virussen bevatten.

Het is een beetje meten met twee maten wat iedereen hier doet.

[thegve]

Nog even een verduidelijking.
In het MIME type staat wat voor inhoud een bepaald bestand heeft. Een html bestand heeft bijvoorbeeld text/html, en een javascript bestand text/javascript. Wat internet explorer nu doet is als jij javascript zet in een bestand met mimetype image/jpeg, hij gaat herkennen dat het hier niet om een plaatje gaat, maar om javascript, en het dan vrolijk gaat zitten uitvoeren.
Volgens MS is dit 'by design'. Volgens mij (en de meeste anderen) is dit een bug. De door jou genoemde media(usb sticks/cd's/dvd's) zijn bestemd om bestanden op te plaatsen. Als jij hamer en beitel pakt en je dvd's met de hand gaat graveren, word het besturingssysteem niet geacht dit uit te lezen. Als jij een bestand hebt en je verteld de browser dat dat een plaatje is, maar je zet er vervolgens script in, dan zou de browser een error, de tekst van het script(zonder uit te voeren) of iets dergelijks moeten laten zien.

[Janoz]

@timonb

IE is een programma dat bedoelt is om code uit te voeren, wel te verstaan HTML code of code volgens een MIME standaard.

Inderdaad. IE is bedoeld om html code uit te voeren. Ga nu nog eens naar boven scrollen en kijk wat de bu gnu precies inhoud. De server stuurt helemaal geen html code, maar een afbeelding. Een afbeelding hoor je te tonen, en niet uit te voeren. Het hoofdgroepdeel van het mime-type is zelfs image, en nog gaat IE het uitvoeren. Daarnaast gaat het zelfs bij een juist mimetype fout. Kijk maar naar het voledig geldige png plaatje van opera.

Dat de gebruiker niet een plaatje maar een text bestand toont is toch niet iets waar MS iets aan kan doen.

Dat doet de gebruiker niet, IE doet dat. Die krijgt een plaatje en toont het als text bestand.

Het is een beetje meten met twee maten wat iedereen hier doet.

Ik denk eerder dat iedereen ietsje beter het artikel leest.

[soulrider]

dan kies er ik zelf voor om te snel te rijden, niet mijn wagen (hoop ik toch)

nu krijg je deze keuze niet echt - in sommige bedrijven moet IE gebruikt worden omwille van interne pagina's.

Maar nu staat daar dus een wagenwijde deur in open.
wat je ook als security verder hebt: 1 externe pagina die zo'n .png in een iframe gebruikt en voila: prijs....

(waar je andere exploits kunt blocken met een goeie firewall, ids'en enzo .... moet je hier al verder gaan kijken....)

test met een pagina met enkel een 0x0 iframe met daarin enkel een png die een alert geeft en een redirect naar tweakers:
www.soulrider.be/tweak/exploit.htm
de png op zich is www.soulrider.be/tweak/test.png :
een 256x256 witte png

(edit: door mijn geprul en inserting is de .png schijnbaar niet meer geldig.. maar dit is ook maar kladwerk ook eh)

als dit al lukt dan zijn er mensen die wel meer kunnen doen op zulke wijze met IE gebruikers ...
(en dit is ook maar gekeken met ultraedit naar de hier in het artikel gegeven .png en nagemaakt in een lege png)

[Marcelloz]

Hij doettet niet...

ownee, ik zit in firefox

[OkkE]

Microsoft moet eens ophouden met het argument "anders breken website die op dit [foute] gedrag vertrouwen".

Jammer dan als sommige website - die toch al niet geheel goed waren - niet meer (volledig) werken. XSS exploits kunnen voor veel meer problemen zorgen.

[aequitas]

Erger nog:

Om die 1% webmaster die op deze foute manier hun plaatjes serveren tegoemoed te komen laten we 99% van de webmaster verplichten hun websites aan te passen

[Anoniem: 61293]

Wat mij verbaast is de schijnbare eenvoud van het uitvoeren van deze exploit. Veel exploits van de afgelopen tijd zitten ingewikkeld in elkaar, maar ik denk dat elke web developer zonder veel moeite hier gebruik van zou kunnen maken. Des te vreemder dat MS dit probleem geen prioriteit geeft.

Ben trouwens benieuwd wat het Opera-logo met het artikel te maken heeft.

[Thyraon]

Het is erger dan dat: niet alleen webdevelopers maar ook gewone gebruikers kunnen deze exploit misbruiken. Zoals in het nieuwsbericht al aangegeven wordt: een "geïnfecteerd" GIF- of PNG-plaatje uploaden op Flickr of T.net kan genoeg zijn.
IE-gebruikers hoeven alleen het plaatje maar te bekijken in hun browser om de malafide code uit te laten voeren...

[Anoniem: 20531]

Logo van Opera is een subtiele hint. Als ze ook het logo van Firefox plaatste zou het niet meer subtiel zijn

[Yoeri]

Opera is niet kwetsbaar

Beetje ironisch doen door een dergelijk png-plaatje met 'exploitcode' van een Opera-logo te voorzien

[stekkel]

DIt was al bekend. Een workaround voor dit probleem is een content-type http header meesturen.
In php:
header ("Content-Type: application/force-download; name="blah.jpg")

Wanneer het bestand blah.jpg html bevat wordt het niet uitgevoerd vanwege de application/force-download header.

[Kees]

Dat is geen oplossing, en ook geen workaround. Dan moet namelijk de server het juiste type forceren. Het is een stuk beter te voorkomen dat er 'illegale' plaatjes op je server komt dan te proberen IE zover te krijgen dat hij niets parsed.

[stekkel]

Hangt er vanaf hoe je het bekijkt. Natuurlijk ben ik het met je eens dat je het probleem bij de bron moet aanpakken maar in gevallen dat dat niet kan is die force-download best handig.

Ik werd door Martijn Brinkers maanden geleden geattendeerd op deze vulnarability in een webmail programma. Aangezien je daar geen controle hebt over de attachments bij een mail en omdat er een mogelijk moet zijn om een attachment te downloaden is tot eerder genoemde workaround gekozen. Zonder die header zou er i.p.v. een download een plaatje in een IE venster geopend worden omdat IE op basis van extensie de betreffende viewer opent. Zo was het mogelijk html met javascript in bijvoorbeeld een .jpg bestand te smokkelen.

Beter is het om zelf de binary te inspecteren maar dat is wat omslachtig in PHP en door de extra http header niet nodig.

[Anoniem: 47200]

hulde voor Crisp/Tino wat mij betreft, en dit toont mijns inziens weer aan dat Microsoft helemaal niet zo standard compliant wil zijn dan ze zeggen. Zie hetzelfde met bijv. CSS, ik ben benieuwd hoe sterk IE8 zich aan de standaarden gaat houden want ook van die zeggen ze dat hij zich meer aan de standaarden gaat huoden.

[Zyppora]

Tot slot schuift Microsoft de verantwoordelijkheid af op site-uitbaters, door hen aan te raden gegevens te filteren op basis van de inhoud van bestanden.

"Lieve meneer hacker,

Zou u er alstublieft zorg voor willen dragen dat de feature die wij in IE ingebouwd hebben, betrekking hebbend op het uitvoeren van clientside code in de browser, niet toe te passen voor criminele doeleinden?

Bij voorbaat dank,
Het IE Development Team."