Filtering scripts by file suffix/MIME type (CSRF)

[chris_l]

Hi,

this is my first post here. I just installed NoScript - and it does so exactly what I want I'm amazed Great work guys.

Question (I'll simplify the scenario here, I'm not as careless as the following description may sound ):

Let's assume I have a file on my (firewalled) local server. URL: "http://localhost/secret.js". Content:

Code: Select all

secret="i'll never tell anyone"

This script can be embedded into evil's HTML page. URL: "www.evil.com/index.html". Content:

Code: Select all

...<script src="http://localhost/secret.js"></script><script>alert(secret)</script>...

That's bad of course. But what I found out is, that when I change the name of my file from "secret.js" to "secret.txt", it can't be embedded anymore, if NoScript is turned on. That's exactly what I hoped!

But how does that work? Does NoScript decide this based on file suffix, or rather on MIME type? What feature is responsible for this (is there an option to turn it on/off)?

(BTW, unfortunately I don't get any message, that the script has been blocked.)

Thanks
Chris

p.s.
I think this feature is so important, it should be integrated by default into every browser, or integrated into the HTML spec. Because it's always possible, that some file lies around on some server, which just happens to be parseable as JavaScript (think Subversion servers etc.). Then the information in the file is easy prey for a CSRF style attack (even with CSRF guards up on all JSON services etc.) This kind of protection doesn't even require complicated rules.

[Giorgio Maone]

1. Resources inside your LAN (including localhost) are protected against CSRF by ABE's SYSTEM ruleset, no matter if they're scripts or anything else.
2. Script and CSS inclusions are checked by NoScript for temptative type-correctness with a rather complicated algorithm, involving both the Content-type header and the file extension for web-compatibility sake.