463948 - Prevent XSS with <meta name=disablescripts> or <untrusted></untrusted>

Status: RESOLVED DUPLICATE of bug 493857

(Firefox :: Security, enhancement)

Description

[Ray Morris]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9

This is an idea to make Gecko based browsers much less 
susceptible to cross site scripting attacks.  It will 
require some discussion to fine tune, but I believe the 
concept would be a major leap in browser security.

Because of many great Gecko features, such as the ability to 
recognize 63 different encodings for the character "<", it is 
_extremely_ difficult for Web 2.0 type applications to filter user 
input to _reliably_ avoid cross site scripting.  An application 
may filter the word "javascript" from a user provided URL, but 
how may would filter "jav&#x09;ascript", which also works?
Similarly back end code may remove the "<" character, but 
Gecko recognizes roughly 62 other ways of representing that 
character.

Enter <meta name=disablescripts>.
Blogs, message boards, tube sites, or any other site 
which displays user generated content could use such 
a tag to tell Firefox to turn off scripting for that page, 
thereby neutering all current and future scripting based 
attacks. It may also be decided that such a tag should 
also disable Java and other clearly risky functionality.
Probably it would also be recoginized when used as 
an HTTP header.

Even better would be to be able to surround user generated 
content with <untrusted></untrusted>, but that would seem 
to require making sure that the nefarious user doesn't 
inject </untrusted> along with the other malicious content, 
so </untrusted> would at least have to be treated strictly - 
</untrusted<img src="legit.gif> must not be allowed to work, 
for example. This end tag problem may be insurmountable, 
meaning that using <meta name=disablescripts> to disable 
scripts on the entire page is the best we can do, and that 
would sure be better than the current state of affairs.
Any page marked <meta name=disablescripts> could have 
no script based attacks, period, because scripts simply 
wouldn't be executed.



Reproducible: Always

Comment 1

[Nochum Sossonko [:Natch]]

Most of these sites need javascript, so how would it help them? In other words, they need a way to just disable javascript on certain parts of their page, not the whole page.

Comment 2

[Jesse Ruderman]

Sounds like you either want something like Content Restrictions (bug 390910) or the proposed "jail tag".

Comment 3

[Ray Morris]

(In reply to comment #2)
Yes it appears that I've re-invented Content Restrictions (bug 390910), 
thank you for pointing that out.  In the searching I did prior to 
posting I did not find bug 390910.  Searching bugzilla and Google 
now finds no mention of the "jail tag".  Do you have a link?

(In reply to comment #1)
As an active developer creating these kinds of sites, 
I disagree with the idea that "most of these sites need 
Javascript".  Because many users have Javascript turned 
off completely, it would be unwise to rely on it.  
Further, some sites may use Javascript on some pages, 
such as a photo upload page perhaps, but need not use 
it on the specific pages which display user generated 
content.

Comment 4

[Nochum Sossonko [:Natch]]

(In reply to comment #0)
> Even better would be to be able to surround user generated 
> content with <untrusted></untrusted>, but that would seem 
> to require making sure that the nefarious user doesn't 
> inject </untrusted> along with the other malicious content, 
> so </untrusted> would at least have to be treated strictly - 
> </untrusted<img src="legit.gif> must not be allowed to work, 
> for example. This end tag problem may be insurmountable,

Actually, maybe it would be possible to implement this tag with an id, so <untrusted id="1"> doesn't close until </untrusted id="1">. Now say the user injects his own </untrusted id="1"> then there would be two end-tags with id="1" in which case the policy is enforced from the first tag until the last closing tag with that id. Problem is, I'm not sure how feasible this is, being that the whole page would have to be parsed before js could begin execution (is that a problem ?)...

Maybe there could be a hint in the opening tag as to where the closing tag is meant to be, but that would add a whole bunch of complication, and this is probably not the right place to work out these details...

Comment 5

[Nochum Sossonko [:Natch]]

Bug 493857 is going to take care of this somewhat.