Noscript 1.1.4.6.070318 is a very experimental development build featuring a First attempt to anti-XSS countermeasures.

"Default deny" sanitization is applied to every request coming from an
unknown (restricted) site and landing on a trusted (scripting allowed) site:
1. GET requests with a query string get all the matches for the
   noscript.filterXGetRx regular expression replaced with space
2. POST requests are turned into no-data GET
3. Every request filtering action is logged to the Console, while a
   short notification is issued through the info-bar* (if enabled)
   *Info-bar notifications require Fx 2.0 or above
Behaviours 1 and 2 can be controlled from NoScript Options|Advanced

This development path aims to protect users from volatile XSS attacks originating from untrusted sites and attempting to evade NoScript by targeting a whitelisted site.

It's all in progress (fine tuning probably needed, currently adding counter-measures against scriptless scanners), and any help or criticism is very appreciated.

Thanks!

-- ma1

I've installed it. Looks good so far. What about functionality to auto whitelist any site that gets bookmarked and also when installed you could get a list of your bookmarked sites which you can optionally whitelist.

Don't forget our IRC: irc://irc.irchighway.net/#slackers
-WhiteAcid - your friendly, very lazy, web developer

WhiteAcid Wrote:
-------------------------------------------------------
> I've installed it. Looks good so far. What about
> functionality to auto whitelist any site that gets
> bookmarked

ATM you've got an option to auto-whitelist bookmarked sites as they're opened by actually clicking on a bookmark. This way you avoid to accidentally whitelist old sites you forgot about.
BTW, I added these "auto" options by user requests, but I would never keep them enabled for myself (after all I've got some forum sites in my bookmarks...)

> and also when installed you could get a
> list of your bookmarked sites which you can
> optionally whitelist.

This is one is interestening, thanks.

I asked a question here: http://sla.ckers.org/forum/read.php?1,8548

I won't repeat it, due to cross-posting, but you can answer here if you like.

- RSnake
Gotta love it. http://ha.ckers.org

I answered there too, basically a "works for me".
I did not see your post in this topic, but I do prefer continuing here.
Since I'm developing on your feedback, I'll open a topic for each new available build (unless the homeowner disagrees, of course...).

Thanks!

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript

No, in second tests I was able to confirm that whatever I had thought I tested didn't work (or rather it did work in the way that it should). But I did find a series of strange side-effects:

http://goodsite.com/whatever.cgi?asdf=%22eval%2600x22((

returns:

asdf = "eval&00x22((

But through an iframe in badsite it returns:

asdf = ?%22eval%22&00x22%20=

Seems like a bug.

- RSnake
Gotta love it. http://ha.ckers.org

Oh, btw, before I forget, do you want me to blog about this or keep it on the down low until you get closer? I think a lot of people would be interested in it.

- RSnake
Gotta love it. http://ha.ckers.org

rsnake, feel free to blog about it at any stage.

Just report my statement about this being a very experimental work in progress and aggressive feedback being more than welcome.

I do expect several "side effects" in navigation from badsites to goodsites (Untrusted2Trusted), since the filter is very aggressive in this direction (default deny), preferring safety over fidelity.
All Untrusted2Untrusted, Trusted2Trusted and Trusted2Untrusted requests should always pass unfiltered (with no side effects), though.
What I want to guarantee is that a script can't be injected on the fly into a trusted domain, even if following some legit links may fail (you can still copy and paste in the location bar, if you feel it's a false positive).
Special care is being put to preserve links to search engine results, "almost semantically" if not literally (e.g. double quotes are allowed but, if present, other symbols are even more aggressively erased and unmatched double quotes are forcibly paired).

Thanks again and good night for now (GMT+1 here).

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript



Edited 1 time(s). Last edit at 03/20/2007 05:55PM by ma1.

Only looking at the code so far:

1. It only sanitizes the query string, there are lots of examples for XSS through PATH_INFO URL part or Referer header however.
2. Did you check whether channel.documentURI is set correctly for popup windows and HTTP redirects?
3. This will cause issues on any site using Google's search.

If you could possible add some support into the extension that would allow users to force all cookies to http only then it would be greatly appreciated (I haven't dealt with FF extension etc so I really have no idea how hard this would be).

----------
'Just because you got the bacon, lettuce, and tomato don't mean I'm gonna give you my toast.'

HTTP only cookies are already implemented - Firefox 3.0 will support them. But you can of course disable reading access to document.cookie already, at the cost of breaking lots of sites. Add this line to prefs.js in your profile:

user_pref("capability.policy.default.HTMLDocument.cookie.get", "noAccess");

Mao, I just realized that you aren't allowing the parameter separators (& and ;) or = in query strings. Then you can simply remove query strings altogether, the effect will be the same.

trev Wrote:
-------------------------------------------------------
> Only looking at the code so far:

Thank you for your time.

> 1. It only sanitizes the query string,
It strips out upload requests, turning them in data-less GETs.
These are by far the most common and viable injection vectors.

>there are lots of examples for XSS through PATH_INFO

and "crazy URL rewritings" as well...

> or Referer header however.

Thanks for this reminder.
I've already added full request URL and referer sanitization in the build I'm about to publish.

> 2. Did you check whether channel.documentURI is
> set correctly for popup windows and HTTP
> redirects?

Yes I did of course, and it does not set it "correctly" under some circumstances, if by "correctly" you mean reflecting the originating site: about:blank usually takes over when the creation of a new DocShell is involved).

However, if you looked at the code you should already know that I'm not *using* channel.documentURI.
I'm just checking for its existence as an optimization step in order to avoid further processing for background requests (e.g. RSS feed synchronizations or the many Google phone calls Firefox does).

The real origin is captured early (in ContentPolicy.shouldLoad()) and attached to the document as a __noscript_sticky_origin__ property.
So far this "hack" seems to work right, but please let me know if you think I'm missing something.

> 3. This will cause issues on any site using Google's search.

This is already fixed :)
The new build is just a few hours away and I'll open another topic for that.

trev Wrote:
-------------------------------------------------------
> Mao, I just realized that you aren't allowing the
> parameter separators (& and ;) or = in query
> strings. Then you can simply remove query strings
> altogether, the effect will be the same.

Trev, now I suspect you're looking to someone else's code :)

I see, I missed the part where you are splitting the query. Then make it: "you don't consider ; as a parameter separator". The HTML spec recommends using ; as a parameter separator because it doesn't need to be entity encoded. So splitting should be done by /[&;]/. Also I see that you decode parameters with decodeURIComponent. This function is meant for UTF-8 input. If it gets windows-1251 (Russian) input for example it will throw an exception, "malformed URI sequence". See http://www.google.com/search?ie=windows-1251&q=%F2%E5%F1%F2 - and any exception in your code means that the request is let through. Not that your regexp allows anything but English - \w will not even match German umlauts. Italian also has its "à" at the very least.

trev Wrote:
-------------------------------------------------------
> I see, I missed the part where you are splitting
> the query. Then make it: "you don't consider ; as
> a parameter separator".

I didn't even answer to that part because I already changed the splitting regexp yesterday. You'll get it in the upcoming build, along with some improvements in charset handling.
That said, I don't care too much if some edgy parameter gets mangled, I would be much more concerned if every URL could pass, included the malicious ones which are likely to be "edgy".
NoScript imposes (reasonable) restrictions on untrusted sites, and while it tries to make them work "almost as expected", it obviously won't let them do everything.

BTW, thanks for noticing the unhandled decodeURIComponent() "exceptional" behaviour.
I actually put a try {} catch {} guard around it as soon as I started playing with different encodings ;)

ma1 Wrote:
-------------------------------------------------------
> The real origin is captured early (in
> ContentPolicy.shouldLoad()) and attached to the
> document as a __noscript_sticky_origin__ property.

That's fun! You are probably not aware of bug 345857, your code hits this crash as well. I already changed Adblock Plus not to touch the document before I am sure that it exists - the tendency in this bug is to WONTFIX it, content policies are very restricted in what they are allowed to do.

Btw, you can create frames with the <object> tag as well:

<object type="text/html" width="300" height="150" data="something.html"></object>

You will get a request for TYPE_OBJECT in the content policy then (at least in the trunk nightlies). And of course there is the case that the user clicks a manipulated link - getting him to do so isn't difficult. In that case it would be TYPE_DOCUMENT and I think the origin parameter is useless. Edit: I was looking at Gecko 1.7 docs, the constants have changed since then. So the only obvious mistake in your code is: it doesn't recognize TYPE_DOCUMENT in Gecko 1.7. And the fact that you really should not rely on the numerical values of these constants.



Edited 2 time(s). Last edit at 03/21/2007 05:56PM by trev.

trev Wrote:

> I was looking at Gecko 1.7 docs,
> the constants have changed since then. So the only
> obvious mistake in your code is: it doesn't
> recognize TYPE_DOCUMENT in Gecko 1.7.

Glad to hear this, since I already announced 1.1.4.6 as the last NoScript version supporting Gecko 1.7 (I'm sick of doing all the XPCom native wrapping by hand via lookupMethod() to reduce the performance hit) :)