Closed Bug 361915 Opened 13 years ago Closed 5 years ago

HTML security META tag to suppress XSS holes in web sites

Categories

(Core :: Security, defect)

x86
Windows XP
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 493857

People

(Reporter: BijuMailList, Assigned: dveditz)

References

Details

HTML security META tag to suppress XSS holes in web sites 

There are many bugs submitted here asking to suppress many currently available browser features, to avoid XSS holes in web sites (see bug 301375) 

It is mainly required to avoid phishing and other malicious activities on many social networking site, wiki, forums etc.

If those features removed, then we troubles legitimate sites which use that technologies for years.


So I suggest another option.
which is a win for all, and will be page specific.

Why not use HTML META tag on a page to decide what kind of security level is needed for that page. A semicolon delimited list of security flags should be provided as content of META tag with name security.


syntax:-
<meta name="security" content="[semicolon delimited list of security flags]" />

eg:-
1.
<meta name="security"
      content="captivedataurl; 
               noxbl; 
               noxsitesubmit; 
               pagelevelpwd" />

2.
<meta name="security" 
      content="shoplevelpwd; 
               import(http://mozilla.org/security/tight.txt)" />


security flags:-

captivedataurl - bug 255107 Prevent data: URLs from being used for XSS
noxbl          - bug 324253 -moz-binding can be used for XSS
noxsitexbl     - only support xbl hosted on same server     
noxsitesubmit  - bug 321815 form URI and action URI have same host
noxsitelogin   - similar too bug 321815, but allow non password forms 
pagelevelpwd   - bug 263387 passwords should be stored for host+path
shoplevelpwd   - http://geocities.com/userid1/sub1/page.html and
                 http://geocities.com/userid1/sub2/page.html share store password 
                 but not with http://geocities.com/userid2/sub1/page.html
noxsitescript  - allow only script from same host
nodataurl      - dataurl on the page or css should not be supported
nojsurl        - javascript urls on page should not be supported
noforms        - no form support on this page
noonevents     - no onevent handlers allowed in tag
noinlinestyle  - inline style tag should not be allowed
                 only <LINK REL=STYLESHEET TYPE="text/css" HREF=...>
                 in side HTML <HEAD> tag allowed
nobodystyle    - <STYLE> tag and <LINK REL=STYLESHEET TYPE="text/css" HREF=...>
                 allowed only inside HTML <HEAD> tag
nobodyscript   - <SCRIPT> tag allowed only inside HTML <HEAD> tag
noinlinescript - only external <SCRIPT> tag
                 in side HTML <HEAD> tag allowed
noxhostscript  - no cross domain script allowed

import(url)    - allow to read the security setting in an external page


there should be only one security meta tag needed
but if found more than one merge them and fall back to more restrictive option present

Future: 
* mozilla.org should go for standardization at W3C
* browser ui should indicate warning icon at status bar if it did not understand a particular 

flag.
* just like vendor specific CSS, ignore flags starts with -xxx but not -moz-xxxx
Functionally, this would be better implemented as a server header/http-equiv, like Compact Privacy Policy.  Are you proposing that the browser be locked-down in the absence of these flags?
A "trusted domains" field would give the xsite flags a great deal of flexibility ;)
(In reply to comment #0)
> import(url)    - allow to read the security setting in an external page

additionally...
for import(url) "," and ";" in the url should be encoded/escaped
may be the form import(url1, url2, url3) also good.

(In reply to comment #3)
> A "trusted domains" field would give the xsite flags 
> a great deal of flexibility ;)

good.. something like
trusteddomains(www.abc.com, ssl.abc.com, xyz.com)
but need to again define what all should be allowed from/to trusteddomain
or we could say trusteddomains can do what sameorigin pages can do with that page

(In reply to comment #1)
> Functionally, this would be better implemented as a server header/http-equiv,
> like Compact Privacy Policy.  

Do you mean http-response-header or "http-equiv" tag in header?
if "http-equiv" tag, no prob using it instead of a META tag
What about honoring both http-response-header and META/http-equiv TAG

> Are you proposing that the browser be locked-down
> in the absence of these flags?
NO, in absence keep current standard
all these thing is because we need to make social networking sites 
(or similar ones) more safe.
a trust able site dont have this problem
we dont want to break them for not having these extra flags
remember W3C standards are not asking this.

but we may need to add one more flag, 
which should be the very first flag if present.

"lockonfail" - ie, there is a "security" META tag but browser cannot understand it.
then we should goto complete safe mode with a warning to user


(In reply to comment #2)
> Something like this?
> http://www.gerv.net/security/content-restrictions/

yes that also works
but I want to add, some of the flags should be capable of 
taking more than one value at a time
some thing like

   cookies=(body,none);cookies=(header,all);

ie, if script is in header it can be trusted 
if script is in body dont trust, or run at lesser privilege...
Here is a neat idea, although I'm not sure if there is a valid way to implement it in HTML or XHTML without changing the spec.

A new element, called <usermarkup> that requires a closing tag.  The UA guarantees that everything inside this element will be "sanitized" else the element and its contents are ignored.  UA also guarantees that if the server removes all instances of the exact string "</usermarkup>" from the element's contents, then no other sanitizing is required of the server.

Combined with flags mentioned above, there is no longer a "moving target" for filtering forums and blog systems.
btw, could this be implemented as "<!-- <usermarkup>"  ?
Can we all please stop having ideas that have been had many, many times before? <sigh>. The usermarkup (or sandbox or whatever it's called this week) tag is, according to bz last time I asked him, extremely hard to implement in a way that would actually work and achieve what you wanted.

If people have ideas for new security stuff, propose it in the newsgroup.

Gerv
Could relate to Bug #252342 where it was suggested server headers be used to filter out cookies on incorrect domain names, such as ".com."
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: CSP
You need to log in before you can comment on or make changes to this bug.