Scriptorama.nl

Vandaag op het IEBlog staat er een aankondiging dat IE8, waarvan de tweede beta overigens ergens in Augustus zal uitkomen, een XSS filter implementeert waarmee veel simpele XSS aanvallen geneutraliseerd zullen worden.

Het IE8 XSS filter werkt anders dan het Site Security Policy voorstel van Mozilla waar ik laatst al overschreef. Waar Site Security Policy werkt met een whitelist systeem, bekijkt het IE8 filter alle input van een gebruiker, denk aan de querystring. postdata en cookies, wanneer hier iets (zoals bijv. een script tag) tussen zit dat het filter ziet als een XSS aanval en deze zelfde HTML komt later weer terug in de resultaat pagina - dan zal IE8 het betreffende script blokkeren en de gebruiker informeren wat hij gedaan heeft.

he XSS Filter operates as an IE8 component with visibility into all requests / responses flowing through the browser. When the filter discovers likely XSS in a cross-site request, it identifies and neuters the attack if it is replayed in the server’s response. Users are not presented with questions they are unable to answer – IE simply blocks the malicious script from executing.

Mensen die om wat voor reden dan ook toch HTML/Script tags via de URL willen doorgeven en dus niet beveiligd willen worden door het IE8 XSS filter kunnen een nieuwe custom header meegeven:

Daarmee wordt het filter uitgeschakeld.

Het lijkt er op dat mensen die bijvoorbeeld een CMS ontwikkelen waarbij ook Javascript geplaatst kan en mag worden, even zullen moeten opletten bij de release van IE8 - aangezien hun admin wel eens problemen kan gaan opleveren bij het gebruik van IE8. Deze mensen kunnen in Augustus met IE8 beta 2 in elk geval al testen, beta2 zal het IE8 XSS filter bevatten.

Verder is het een iets minder ingrijpend en eigenlijk iets pragmatischer systeem dan het Site Security Policy voorstel. Waar het Site Security Policy voorstel altijd het versturen van een header vereist om de beveiliging in te schakelen werkt dit filter altijd. Aan de andere kant is het SSP voorstel iets completer, aangezien ook CSRF aanvallen behandeld worden, en er ook een manier gedefinieerd is om de website beheerder op de hoogte te stellen van problemen die zijn gedetecteerd.