"blijkbaar niet"
Duidelijk niet. Maar anders zet ik morgen je desktop even vol met programma's, om 't uur of zo. Is tenslotte alleen maar 'lastig' en je kan ze zo weer verwijderen, toch?
10 van de 27 niet gepatcht. OH NOES.
Even het lijstje langs.
1.
"Internet Explorer "Print Table of Links" Cross-Zone Scripting"
Pagina moet de gebruiker zo ver krijgen om de pagina te printen en dan ook nog eens "print table of links" (standaard uit) aan te zetten. Niet onmogelijk, maar de kansen zijn toch aardig gering.
2.
"Internet Explorer "DisableCachingOfSSLPages" Weakness"
Een ge-encrypte pagina wordt lokaal opgeslagen. Kan je, tenzij iemand je al toegang hebt tot de machine van de gebruiker, niets aan. En als je al wel toegang hebt, dan heeft die gebruiker wel grotere problemen.
3.
"Internet Explorer HTTP Request Smuggling/Splitting Vulnerabilities"
Kan een aanvaller op hetzelfde domein als een vertrouwde source je cookie (bijvoorbeeld) van die vertrouwde source inlezen door een bestaande socket te hergebruiken. Wel moet die aanvaller dan ook op de vertrouwde source al de bron hebben aangepast. Als in je cookie je gebruikersnaam/wachtwoord staat is dat lastig. Bad cookie.
4.
"Microsoft Internet Explorer FTP Credentials Exposure"
Als je een FTP pagina opslaat kan je gebruikersnaam/wachtwoord erin staan. Als je deze dan deelt met iemand anders... etc.
5.
"Microsoft Internet Explorer 7 HTTP Basic Authentication IDN Spoofing"
Als je op een site komt waar bijvoorbeeld een plaatje staat die achter een HTTP auth zit, dan krijg je een standaard login box. Is al verdacht, maar goed; vervolgens staat in de titelbalk de domeinnaam van origine. ALS de aanvaller dan dezelfde hostnaam als van de site waarop je zit te browsen visueel weet te spoofen, bijvoorbeeld door een cyrillisch alfabet, dan kan jij niet 1-2-3 zien dat het niet dezelfde site is.
Lekker toch, die internationale domeinnamen?
6.
"Internet Explorer Page Loading Race Condition and URL Spoofing"
Door een tricky zootje javascript kan je ervoor zorgen dat Site A lees/uitvoer (script) rechten heeft op Site B. Alleen heeft ie dan geen lees/uitvoer rechten meer op Site A. Dus Site A kan de tekst van Site B inlezen maar kan er verder niets meer mee.
En de adres balk kan worden gespoofed - dat vind ik zelf altijd wat minder leuk.
7.
"Internet Explorer Charset Inheritance Cross-Site Scripting Vulnerability"
De gebruikelijke CSS (niet de style sheet) boel. Stel je maakt een lokale pagina met heel veel rechten (custom level) en je zet daarin een iframe die een pagina op het internet uitleest en deze pagina wordt gecomprimeerd, dan kan die iframe dezelfde rechten behalen als de hoofdpagina. Niet doen, dus.
8.
"Multiple Browsers Window Injection Vulnerability Test"
In het kort... als Site A een nieuw venster opent en dit nieuwe venster de 'naam' "TEST" geeft, dan kan Site B een nieuwe pagina in de venster met naam "TEST" openen, en de browser zorgt er automatisch voor dat dit dan in het al bestaande venster komt.
De bedoeling is dat dit alleen van dezelfde site zou kunnen, natuurlijk, bijvoorbeeld zo'n oude foto browser (tegenwoordig dmv DHTML of Flash gedaan).
9.
"Internet Explorer 7 Window Injection Vulnerability"
Idem dito.
10.
"Internet Explorer 7 Popup Address Bar Spoofing Test"
als je maar genoeg rare karakters in een url stopt, dan www.site die je wil spoofen.com, dan nog wat karakters, dan lijkt het alsof er in de adresbalk alleen "www.site die je wil spoofen.com". De titelbalk blijft welk correct; lullig is dat deze test -zonder- adresbalk opent bij mij (zowel IE als FF). Altijd de titlebar controleren dus, ongeacht browser, want soms staat die hele adresbalk er niet.
11.
"Internet Explorer File Upload Form Keystroke Event Cancel Vulnerability"
Stel jij weet dat een bepaald bestand -ergens- op de schijf van je slachtoffer staat. Dan kan je met een javascript ervoor zorgen dat dat bestand naar jou toe kan worden geupload. Moet je alleen wel zorgen dat je een FORM hebt waar de gebruiker een lap tekst in gaat tikken die -alle- karakters, in volgorde, van het volledige pad naar dat bestand bevat.
Bijvoorbeeld "c:\temp\temp.txt", dan moet je de gebruiker zo gek krijgen om bijvoorbeeld "Cicero: \ ehhh..", nee laat maar... ik kan zo geen lap tekst bedenken waar een backslash van nature in voor komt.
Op een of andere manier kom ik aan 11, niet 10, maar goed.
AL deze vulnerabilities zijn niet als "kritiek" bestempeld. De ergste is de "
Internet Explorer 7 Window Injection Vulnerability" met "enigszins kritiek". Weer een reden minder voor websites om een apart venster te openen, laat staan met een -bekende- naam (je hebt 'random' niet voor de lol gekregen, tenslotte).
Dat gezegd hebbende - natuurlijk moeten ze ook alle bovenstaande patchen. Maar "10 van de 27 niet gepatcht" doet vaak het ergste vermoeden, terwijl dat best mee valt.
( Ik gebruik al jaren FF, dus mij boeit het niet zo veel; al waren er verscheidene in de bovenstaande die ook op FF van toepassing waren; maar al wel gepatched* \o/ )
Edit: date > dat.
Edit 2: * Whoops. Toch niet. "Firefox Charset Inheritance Cross-Site Scripting Security Issue" is equivalent van #7 bovenstaand. Foei Mozilla. Maar zoals al gezegd... pagina's geen rare rechten geven, en geen externe pagina's in je intranet zetten zonder een goed intranet beheer.
Edit 3: 11 doordat #8 en #9 eigenlijk hetzelfde zijn, maar in de per-jaar overzichten apart zijn opgegeven. Verklaart de 'idem dito' samenvatting ook weer %)
[Reactie gewijzigd door ZeBoxxToo op zondag 1 juni 2008 15:29]
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
De bug in Safari werd op 15 mei gepubliceerd door veiligheidsonderzoeker Nitesh Dhanjani. Een kwaadwillende kan het bureaublad van een slachtoffer middels een 'carpet bombing'-aanval geheel vullen met opstartbare malware-bestanden. Dit is mogelijk omdat Safari nooit middels een dialoogvenster om toestemming vraagt voordat de browser begint met het downloaden van bestanden. Met een eenvoudig script kan de standaard downloadlocatie van Safari, in de Windows-versie vrijwel altijd de desktop, worden vervuild. Apple's veiligheidsteam liet echter weten dat het door Dhanjani geschetste probleem niet als een acuut veiligheidslek wordt beschouwd en dat het vermoedelijk nog wel even zal duren voordat een toekomstige versie van Safari de gebruiker bij een downloadactie eerst om toestemming zal vragen.
15:00
12:10
Door 
![[show]](http://tweakimg.net/g/if/comments/button_down.png "Reactie uitklappen")
...) " 
.
