Technical magazine: Non-secure IE 8 across XSS as a means of protection against attacks

From the article:

"NoScript is in disagreement with the add-on in IE8.
It analyses answers server and not requests for users, which could be the attackers of manipulation of answers server and injection certain codes for its implementation, Giorgio Maone says.

"And who did not disclose the details of the matter is that the whole matter is based on an error in the basic design, which should be reconsidered in the design, Maone adds."

Pretty bad translation — I know people who could do better — but the bottom line comes out the same in any language. Looks like the whole world knows the story. :-)

Der XSS-Schutz des IE8 bröckelt.Der neueingeführte Cross-Site-Scripting Schutz des Internet Explorer 8 lässt sich anscheinend aushebeln.
Gorgio (der Entwickler von NoScript) berichtet in einem Blogeintrag darüber.
Konkret liegt das Problem in der…

I was refering to one time.. where the POST was stripped but the GET args were left, so it trigers an error (with the GET args) since there’s no POST data.. then if you do unsafe reload, it trigers an error since the nonce sent via GET was used before.

anyway, I only found that specific case on some openid service I was pentesting.. (against logic flaw errors, nothing to do with xss).. but well..

Greetz!

Thanks for your comment.

Yes, I was referring to “unsafe reload”.

break things (POST unsafe reloads for instance)

Nope, a POST unsafe reload doesn’t break anything because the filtered request had been turned in a data-less GET and therefore did not modify webapp status.

regarding slide 16: user can disable the filter..

Anyway, mmm maybe you mean "unsafe reload" so then you are right.. that’s not possible..

I think webkit’s approach compared to IE’s is better (regarding compatibility) but IE is safer (actually, is the one with less bypasses so far.. evendo they did created security issues with the response rewriting approach..).. but NoScript request modification is known to either:
1.- break things (POST unsafe reloads for instance)
2.- hard to spot bugs (I wasnt used to check the error console before)

I would recommend you to allow the server to disable NoScript’s filter.. anyway, I dont have any good idea on how to do it.. =/

Said that.. great ppt again!! :)

Greetings!!