Stylesheet principals
Boris Zbarsky
nsCSSValue::URL. That will allow us to do security checks based on the
stylesheet that asked for the load, not the document the sheet is
applied to. In particular, it will allow user stylesheets to load
file:// images. That will also allow us to do better security checks
for CSSOM access, and get us another step closer to eliminating the
non-principal version of CheckLoadURI.
Most of the setup is pretty simple; the only issue, as usual, is the
javascript: URI scheme. If I have a sheet coming from a javascript:
URI, then:
1) Should the script execute at all?
2) If so, should it execute with the principal of the loader, or with
the null principal?
3) If the script is not executed, or executed with the null principal,
should the resulting sheet get the principal of the loader?
This basically applies to
<link rel="stylesheet" href="javascript:...">
and
@import url("javascript:...");
The current setup is that the script executes with the null principal.
At least in part this is a question about what websites that allow
user-submitted content (including user-submitted stylesheets) do or
don't filter out, of course, which is the part I'm not that familiar with.
I'd really like to just make a decision here and implement it; I really
want to nix CheckLoadURI for 1.9.
-Boris
P.S. My personal preference would be to either not run the script at
all or to run it with the loader's principal; I think the null principal
thing is a terrible kludge in this case.
C A Upsdell
> I'd like to store an nsIPrincipal in each stylesheet and in each
> nsCSSValue::URL. That will allow us to do security checks based on the
> stylesheet that asked for the load, not the document the sheet is
> applied to. In particular, it will allow user stylesheets to load
> file:// images. That will also allow us to do better security checks
> for CSSOM access, and get us another step closer to eliminating the
> non-principal version of CheckLoadURI.
JavaScript is not related to CSS, except in Netscape 4, which is no
longer used. So there are no security issues with CSS.
Boris Zbarsky
> JavaScript is not related to CSS, except in Netscape 4
If you ignore the existence of javascript: URIs, sure.
> So there are no security issues with CSS.
This, however, is false. The issues range from "hang the OS" issues (e.g. via
@import of the right file:// URI on some OSes) to cross-site attacks (e.g. via
loading some non-CSS file as a stylesheet from another site, then using the
CSSOM to read the data).
In general, "security issues" doesn't mean JavaScript is directly involved.
-Boris
C A Upsdell
> C A Upsdell > wrote:
>
>> JavaScript is not related to CSS, except in Netscape 4
>
> If you ignore the existence of javascript: URIs, sure.
??? This makes no sense. Linking to a non-CSS file is not a security
issue, it is a bug with no security consequences. Suppose the designer
mistakenly links to (say) a JavaScript file: whatever the content of
the file is, it will be bad CSS, and the browser will treat it as bad
CSS, not as any kind of JavaScript.
>> So there are no security issues with CSS.
>
> This, however, is false. The issues range from "hang the OS" issues
> (e.g. via @import of the right file:// URI on some OSes) to cross-site
> attacks (e.g. via loading some non-CSS file as a stylesheet from another
> site, then using the CSSOM to read the data).
If you have an @import which imports a bad file, that is an error on the
part of the designer, and should have been detected during site testing,
e.g. by doing something as basic as a Validation check. Bad CSS could
sometimes crash Netscape 4, but as I commented earlier, Netscape 4's
implementation of CSS was tied to JavaScript, which is not true of any
other browser, and in any case Netscape 4 is dead. A site with such a
problem should never be deployed, so this can hardly be classed as a
security issue.
Boris Zbarsky
>> If you ignore the existence of javascript: URIs, sure.
>
> ??? This makes no sense. Linking to a non-CSS file is not a security
> issue
You don't understand what javascript: URIs are, do you?
> Suppose the designer mistakenly
We're talking about malicious designers, not mistaken ones.
Something like:
.class { background: url("javascript: do stuff here"); }
is what I'm talking about. This is a way for a user on a site like MySpace to
try to inject script that the site will fail to detect, as a vector for stealing
other user's account info. Please read up on this before commenting more in
this thread?
> If you have an @import which imports a bad file, that is an error on the
> part of the designer, and should have been detected during site testing
We're talking about malicious designers who are trying to screw over the user here.
> A site with such a problem should never be deployed, so this can hardly be
classed as a
> security issue.
It's not a security issue for the _site_ (unlike the javascript: thing above),
but for the user.
-Boris
C A Upsdell
> C A Upsdell > wrote:
>>> If you ignore the existence of javascript: URIs, sure.
>>
>> ??? This makes no sense. Linking to a non-CSS file is not a security
>> issue
>
> You don't understand what javascript: URIs are, do you?
I'm not the only one who does not know what a javascript URI is. The
official list of schemes published by IANA does not include a scheme
named 'javascript' in either its 'official' or 'unofficial but common'
lists, so there is no such thing as a javascript URI. At most there
might exist an entity *resembling* a URI which begins with 'javascript'.
See:
http://www.iana.org/assignments/uri-schemes.html
http://en.wikipedia.org/wiki/URI_scheme#Official_IANA-registered_schemes
http://en.wikipedia.org/wiki/URI_scheme#Unofficial_but_common_URI_schemes
Isn't it hard for me (or anyone else) to understand something that does
not exist?
>> Suppose the designer mistakenly
>
> We're talking about malicious designers, not mistaken ones.
>
> Something like:
>
> .class { background: url("javascript: do stuff here"); }
>
> is what I'm talking about. This is a way for a user on a site like
> MySpace to try to inject script that the site will fail to detect, as a
> vector for stealing other user's account info. Please read up on this
> before commenting more in this thread?
It seems to me that you are addressing a non-problem. Since no valid
URI beginning with 'javascript' can exist for a conforming user agent,
the presence in a stylesheet of such a thing must be considered an
error. And since the CSS specification requires that invalid rules be
ignored, an entity beginning 'javascript:' where a URI is expected
should be ignored.
It also seems to me that, to the extent that you continue to have such a
concern, this is not a topic for discussion in this CSS newsgroup.
Perhaps you should be trying mozilla.dev.tech.xul, or some newsgroup
where discussions of dealing with non-existant URIs would reasonably be
discussed.
Boris Zbarsky
> I'm not the only one who does not know what a javascript URI is. The
> official list of schemes published by IANA does not include a scheme
> named 'javascript'
Sure. I don't think anyone registered it, ever. That doesn't change the fact
that many sites depend on it.
> http://en.wikipedia.org/wiki/URI_scheme#Unofficial_but_common_URI_schemes
I find it funny that this site lists "about" (which is useless for purposes of
rendering web pages) but not javascript:.
> It seems to me that you are addressing a non-problem. Since no valid
> URI beginning with 'javascript' can exist for a conforming user agent
You mean Amaya might not support it?
Every single UA that tries to actually render web pages does. In particular
Gecko does, so for Gecko this is definitely an issue.
> And since the CSS specification requires that invalid rules be
> ignored, an entity beginning 'javascript:' where a URI is expected
> should be ignored.
Actually, that's a valid rule as far as CSS is concerned -- the "ignored" thing
just refers to syntax, and that's a valid CSS url() token.
Please do learn your spec if you plan to quote it.
> It also seems to me that, to the extent that you continue to have such a
> concern, this is not a topic for discussion in this CSS newsgroup.
Er... this is the newsgroup for discussion of the Gecko implementation of CSS.
So this is _absolutely_ the right newsgroup for it.
I'm going to stop replying to you at this point, since you're apparently just
trolling instead of actually trying to contribute meaningfully.
-Boris
C A Upsdell
> C A Upsdell > wrote:
>> I'm not the only one who does not know what a javascript URI is. The
>> official list of schemes published by IANA does not include a scheme
>> named 'javascript'
>
> Sure. I don't think anyone registered it, ever. That doesn't change
> the fact that many sites depend on it.
>
>> http://en.wikipedia.org/wiki/URI_scheme#Unofficial_but_common_URI_schemes
>
> I find it funny that this site lists "about" (which is useless for
> purposes of rendering web pages) but not javascript:.
>
>> It seems to me that you are addressing a non-problem. Since no valid
>> URI beginning with 'javascript' can exist for a conforming user agent
>
> You mean Amaya might not support it?
I said 'conforming' user agent. If a user agent recognizes such a
thing, it is not 'conforming', is it?
> Every single UA that tries to actually render web pages does. In
> particular Gecko does, so for Gecko this is definitely an issue.
So it is a bug, especially in a stylesheet, and that is how your
security concern should be addressed. Recognizing the pseudo URI in
HTML is more problematic, as compatibility with legacy browsers becomes
an issue, but there is no justifiable reason for recognizing it in a
stylesheet.
>> And since the CSS specification requires that invalid rules be
>> ignored, an entity beginning 'javascript:' where a URI is expected
>> should be ignored.
>
> Actually, that's a valid rule as far as CSS is concerned -- the
> "ignored" thing just refers to syntax, and that's a valid CSS url() token.
It is not valid if the 'URI' is not a URI.
> Please do learn your spec if you plan to quote it.
>
>> It also seems to me that, to the extent that you continue to have such
>> a concern, this is not a topic for discussion in this CSS newsgroup.
>
> Er... this is the newsgroup for discussion of the Gecko implementation
> of CSS. So this is _absolutely_ the right newsgroup for it.
>
> I'm going to stop replying to you at this point, since you're apparently
> just trolling instead of actually trying to contribute meaningfully.
Ignore me if you like. I am not a troll. Perhaps someone else will be
able to get through your mental block and make it clear to you that
there should be no security problem with your so-called URI, because
such a URI is invalid, and so a standards-conforming browser should not
try to do anything with it. If a browser recognizes such a thing in a
stylesheet, this is an error, and you should file a bug report
describing this potential security vulnerabiity.
BTW, VeriSign is offering a reward for the first 6 security
vulnerabilities in Vista and IE7. If IE7 recognizes a 'URI' beginning
with 'javascript:' in stylesheets, and you can use this fact to make it
a arbitrary code execution vulnerability, then you could win a couple of
thousand dollars. Perhaps this will give you an incentive to rethink
this issue.
See http://www.internetnews.com/security/article.php/3653516
dou...@netsolis.com
for some time (and work for some really big companies). I've never
encountered the security issues you write about, or at the very least,
have never heard of the things you write about posing a threat.
If you are developing your application to current W3C standards all
non-compliant code will be ignored. Beyond that, the rest is up the
the NOC's and IT admins within your company or the client company.
Further, this is not a Javascript forum nor is it a security forum nor
a "blame" forum nor a "judge who's smarter" forum. Play nice.
Just a few thoughts.
figgy.
Gus Richter
>
> .class { background: url("javascript: do stuff here"); }
>
> is what I'm talking about.
First of all, I would like to say that it was a real mistake to remove
mozilla.support.css which wastes Gecko developer time and authors alike
by having both come to mozilla.dev.tech.css .
Background image with css in html mail is no longer supported and I can
now see the reason why.
If there is no valid reason, other than for malicious intent, to include
javascript in a url, then why support it? So, for your original question:
1) Should the script execute at all?
It seems to me that the answer is a logical no.
Whichever way you end up choosing, please don't forget to apply this
also to the mail client and reinstate background image with css in html
mail.
--
Gus
C A Upsdell
> Boris Zbarsky wrote:
>>
>> .class { background: url("javascript: do stuff here"); }
>>
>> is what I'm talking about.
>
> First of all, I would like to say that it was a real mistake to remove
> mozilla.support.css which wastes Gecko developer time and authors alike
> by having both come to mozilla.dev.tech.css .
Agreed!
> Background image with css in html mail is no longer supported and I can
> now see the reason why.
>
> If there is no valid reason, other than for malicious intent, to include
> javascript in a url, then why support it? So, for your original question:
> 1) Should the script execute at all?
> It seems to me that the answer is a logical no.
>
> Whichever way you end up choosing, please don't forget to apply this
> also to the mail client and reinstate background image with css in html
> mail.
I suspect that the OP is no longer monitoring this thread.
As a general principle, since there is technically no such thing as a
JavaScript URI, and since, if there were such a thing, it might present
a security issue, it would seem to me that, when a URI is called for,
and it begins with 'javascript:', JavaScript should only be executed
when support for legacy sites makes this reasonable, e.g. in an HTML A
HREF tag. And even then I could see this as being something that should
be a configuration parameter, and perhaps allowable only in quirks mode.
'Nuff said.
Boris Zbarsky
> I've been designing & developing the front-end for enterprise sites now
> for some time (and work for some really big companies). I've never
> encountered the security issues you write about, or at the very least,
> have never heard of the things you write about posing a threat.
Sounds like a vote for "don't execute the script, or execute it with the
null principal" to me... ;)
Thank you.
> Further, this is not a Javascript forum nor is it a security forum
I did cross-post the original post to m.d.security, with followups here
(since at heart the discussion is about Gecko's CSS implementation), for
what it's worth.
-Boris
Boris Zbarsky
> First of all, I would like to say that it was a real mistake to remove
> mozilla.support.css which wastes Gecko developer time and authors alike
> by having both come to mozilla.dev.tech.css .
Yeah, well. That battle was lost some time ago. I'm just trying to
keep the design discussion in public instead of just privately mailing
dbaron, sicking, jst, brendan, roc, and maybe a few others... I figure
it's better this way.
> Background image with css in html mail is no longer supported
Huh. I didn't realize that. Do you happen to know when this change was
made? Is this only for images that are not part of the mail, or also
for images that are attached to the mail?
> If there is no valid reason, other than for malicious intent, to include
> javascript in a url, then why support it?
Well. Some people (brendan comes to mind) claim that there are
non-malicious reasons. A javascript: URI _can_ return data, so if you
want to compute you image data on the fly somehow you can do that. I
posit that if we use null principals for javascript: URIs that's just a
more annoying way of doing a data: URI, since the javascript: URI code
can't touch the page's script context and thus has to encapsulate all
the image information.... I suppose someone could generate a different
image based on what Date.now() returns, but to me that seems like very
much a corner case.
> 1) Should the script execute at all?
> It seems to me that the answer is a logical no.
OK.
> Whichever way you end up choosing, please don't forget to apply this
> also to the mail client
Of course. Gecko's the same in all the Gecko-based apps.
Thanks for the feedback,
-Boris
L. David Baron
> Yeah, well. That battle was lost some time ago. I'm just trying to
> keep the design discussion in public instead of just privately mailing
> dbaron, sicking, jst, brendan, roc, and maybe a few others... I figure
> it's better this way.
I think the solution to that is not to use mozilla.dev.tech.css.
I'm not sure why the group was created; it wasn't on the newsgroup
reorganization plan (at least not until the very last minute), and I
didn't think it was necessary.
Style system code should be discussed in mozilla.dev.tech.layout.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
Stanimir Stamenkov
>> Background image with css in html mail is no longer supported
>
> Huh. I didn't realize that. Do you happen to know when this change was
> made? Is this only for images that are not part of the mail, or also
> for images that are attached to the mail?
As far as I remember (and I'm trying it since very long time) it has
never worked. I don't really get the difference between:
<body background="...">
and
<body style="background-image: url(...)">
in a HTML message body. You could take a look at some tests I've
made into the "mozilla.test.multimedia" (Background image test), like:
news://news.mozilla.org/mailman.4252.116819748...@lists.mozilla.org
--
Stanimir
Alfonso Martinez
> Gus Richter wrote:
>> Background image with css in html mail is no longer supported
>
> Huh. I didn't realize that. Do you happen to know when this change was
> made? Is this only for images that are not part of the mail, or also
> for images that are attached to the mail?
>
See this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=154836
Gus Richter
>
>> Background image with css in html mail is no longer supported
>
> Huh. I didn't realize that. Do you happen to know when this change was
> made? Is this only for images that are not part of the mail, or also
> for images that are attached to the mail?
No, sorry it's such a long time ago. Stanimir may be right in that it
never did work. Alfonso's advised Bug# was reported in 2002. I faintly
recollect that it worked when css was substantially fixed for mail, but
not long after, css support in mail was curtailed, reportedly for
security reasons, but I'm not sure about this.
--
Gus
Ron K.
devs and the composer module owner to backout the patch. This happened
back about 0.1 build period. I believe JoeS posted the issue on the
Tbird Moz-zine forum, which was the initial Tbird method of bug
reporting till Bugzilla access was permitted.
--
Ron K.
Don't be a fonted, it's just type casting
Boris Zbarsky
> Briefly mscott patched the bground support but was pressured by senior
> devs and the composer module owner to backout the patch.
Bug #?
-Boris
Boris Zbarsky
Ah, thanks. I commented in that bug.
The javascript: thing isn't an issue in mailnews, since scripts there are
disabled by default anyway. So this just looks like a mailnews bug; see my comment.
-Boris
Ron K.
taking bugs. All early bug reporting was on Mozilla-zine.
Neil
> Briefly mscott patched the bground support but was pressured by senior
> devs and the composer module owner to backout the patch. This
> happened back about 0.1 build period. I believe JoeS posted the issue
> on the Tbird Moz-zine forum, which was the initial Tbird method of bug
> reporting till Bugzilla access was permitted.
As I recall (bz: maybe glazou remembers better) there was a bug in the
editor component which meant that the editor dialogs started setting CSS
styles rather than the HTML attributes they had previously been using in
HTML mail.
--
Warning: May contain traces of nuts.
JoeS
It was https://bugzilla.mozilla.org/show_bug.cgi?id=216753
I could be wrong, but I thought that styled background-image: (url);
rendered as expected in this short timeframe. But maybe that was just my expectations
of the ability to to "compose" a CSS background in mail, which it seems is (purposely) non-existent..
JoeS
Ron K.
Seems odd we did not detect the side effects of mscotts patch which had
to brake the CID process. I highly dislike the current state of users
required to memorize all the CSS keywords and valid values.