Giorgio Maone wrote:@GµårÐïåñ:
I'm unable to reproduce that untrusted/trusted issue. I've tried going to msn.com, marking ads1.msn.com as untrusted and allowing msn.com and everything works as expected (ads1.msn.com is kept untrusted).
Can you come with a reproducible step-by-step test case?
Here is the thing, it works as expected on my machine but this was a fresh install, fresh config on this machine and it behaved this way and it blew my mind. I checked my machine and my exact same configuration is valid, so I was just confused, that's why I thought it was possibly a new thing. I have no way to reproduce it as such other than what happened. I will keep you posted though if it comes up, in the meantime I just wanted to share it with you as more of a heads up, just in case, nothing to worry really.
Regarding your XSS tests, thanks for your feedback but as far as I can see there's nothing to worry about NoScript's effectiveness:
Code: Select all
data:text/html;charset=utf-7;base64,Ij48L3RpdGxlPjxzY3JpcHQ+YWxlcnQoMTMzNyk8L3NjcmlwdD4=
well obviously in our test, we are not going to use something harmful, its intended to be a proof of concept and this would and could contain ANY data, if its allowed to execute then whatever it contains will execute, that's the idea. Personally I am not worried about NoScript's effectiveness, we were just working as part of a group of security consultants to see if there is a clever way a security can be defeated. This in turn provides more reliability and seal of effectiveness if repeated efforts to intentionally defeat something, fail. You know how that goes, its a hacker's stress test. We do it against encryption, security, and so on, I am sure you know what I mean. I was sharing simply because it didn't catch or call it and I was wondering why more than anything else, I know it was harmless in its current form. Anyway.
This is irrelevant because
- NoScript prevents data: URIs from being launched by untrusted sites
- data: URIs inherit the same principal as the containing document, therefore there's no proper XSS here
Ok, explains why it wasn't caught because of the other NoScript policy in effect, gotcha. Sort of shot ourselves in the foot with that one, I probably should have allowed to see if it catches it, regardless, gotcha and thanks.
Code: Select all
[color=red width=expression(alert(123))][color]
This is irrelevant because dynamic properties (AKA "CSS expressions") are a proprietary Microsoft extension to CSS and cannot work on Firefox.
I am aware of that but I was under the impression as part of the CSS standard, it would still be processed BEFORE it is ignored this means that the code can be still injected using this method, no? As long as you are sure it will never process on Firefox, then I guess that's a moot point then.
This one beats me: how is it supposed to be executed, exactly?
It using the improper character to force the browser to correct the coding in the process of which it interprets and executes what is contained inside it. It has worked successfully on IE and other Mozilla based browsers, I was just testing it on Firefox to mostly see if NoScript would catch it. As to how it is executed, sorry not at a liberty to divulge the secret sauce
Code: Select all
'">><marquee><h1>XSS</h1></marquee>
Marquee is not scripting, you can move text around but you can't execute anything...
Yes, as stated before the codes we execute are intended to be harmless, after all we can't afford to destroy ourselves running every test, but the principle is that once the marquee is executed, it will execute the code within it. So if you embed a malicious code in the place of XSS in the above example, when it renders it, it will execute it.
In other words, not every "XSS" sample in the wild is caught by NoScript, by design: NoScript only filters out stuff which can actually harm a Firefox/NoScript user, it doesn't care about generic "exploits" which cannot work against Firefox and/or NoScript for different reasons (e.g. incompatibility or a different protection kind).
So the assumption here is that it "EVALUATES" the threat before blocking it, even if it is an injection and XSS by design? If that's the case, then it would be valid that it didn't catch these, because they were not intended to be harmful, just a proof of concept. Would you have an objection to us going through NoScript to see the logic it uses to "evaluate" the threat and how it decides its a harmful exploit or a generic one?
