Re: HTML imports: new XSS hole?

2014-06-10 Thread Frederik Braun
On 04.06.2014 11:00, Anne van Kesteren wrote:
 On Tue, Jun 3, 2014 at 7:20 PM, Oda, Terri terri@intel.com wrote:
 Perhaps it would make sense to also require explicit allowing of imports via
 CSP?  Scripts are allowed when no CSP is provided for historical
 compatibility so you'd need to make sure that imports fell under a separate
 directive, but there's no need for backwards compatibility so it probably
 makes sense to choose a more conservative default behaviour for HTML
 Imports.
 
 Using script import seems like a solution that would be better in
 that case, as it does not provide opt-in through HTTP. Whenever we
 require HTTP for a feature, we get a ton of complaints. And script
 import is not that bad authoring-wise either:
 
 script import/script
 link rel=import href
 
 (Okay, you win two code points if you omit the quotes with link.)
 
 

Were you saying script import=url/script or script src=url
import/script?

I, by the way, wholeheartedly agree that link tags become more
dangerous through HTML imports and that they are somehow breaking the
dogma of security by no surprises :)



Re: HTML imports: new XSS hole?

2014-06-10 Thread Anne van Kesteren
On Tue, Jun 10, 2014 at 10:36 AM, Frederik Braun fbr...@mozilla.com wrote:
 Were you saying script import=url/script or script src=url
 import/script?

The former. The latter is reserved for loading and executing scripts.


 I, by the way, wholeheartedly agree that link tags become more
 dangerous through HTML imports and that they are somehow breaking the
 dogma of security by no surprises :)


-- 
http://annevankesteren.nl/



Re: HTML imports: new XSS hole?

2014-06-04 Thread Anne van Kesteren
On Tue, Jun 3, 2014 at 7:20 PM, Oda, Terri terri@intel.com wrote:
 Perhaps it would make sense to also require explicit allowing of imports via
 CSP?  Scripts are allowed when no CSP is provided for historical
 compatibility so you'd need to make sure that imports fell under a separate
 directive, but there's no need for backwards compatibility so it probably
 makes sense to choose a more conservative default behaviour for HTML
 Imports.

Using script import seems like a solution that would be better in
that case, as it does not provide opt-in through HTTP. Whenever we
require HTTP for a feature, we get a ton of complaints. And script
import is not that bad authoring-wise either:

script import/script
link rel=import href

(Okay, you win two code points if you omit the quotes with link.)


-- 
http://annevankesteren.nl/



Re: HTML imports: new XSS hole?

2014-06-03 Thread Simon Pieters
On Mon, 02 Jun 2014 11:32:45 +0200, Anne van Kesteren ann...@annevk.nl  
wrote:



How big of a problem is it that we're making link as dangerous as
script? HTML imports can point to any origin which then will be able
to execute scripts with the authority of same-origin.


I still think it is a problem.

http://www.w3.org/mid/op.ww3ecpo5idj3kv@simons-macbook-pro.local

--
Simon Pieters
Opera Software



Re: HTML imports: new XSS hole?

2014-06-03 Thread Robin Berjon

On 02/06/2014 15:08 , Boris Zbarsky wrote:

On 6/2/14, 9:02 AM, James M Snell wrote:

I suppose that If you
needed the ability to sandbox them further, just wrap them inside a
sandboxed iframe.


The worry here is sites that currently have html filters for
user-provided content that don't know about link being able to run
scripts.  Clearly once a site knows about this they can adopt various
mitigation strategies.  The question is whether we're creating XSS
vulnerabilities in sites that are currently not vulnerable by adding
this functionality.

P.S. A correctly written whitelist filter will filter these things out.
  Are we confident this is standard practice now?


I haven't bumped into a blacklist filter in a *long* while. I suspect 
that any that might exist will be hand-rolled and not part of any 
platform. The odds are pretty strong that they're already unsafe if not 
wide open.


So I would say there's a risk, but not a huge one. That said, I still 
prefer Simon's approach.


PS: I've been wondering if adding an HTML sanitiser to the platform 
might make sense.


--
Robin Berjon - http://berjon.com/ - @robinberjon



Re: HTML imports: new XSS hole?

2014-06-03 Thread Hajime Morrita
A clarification to make sure people in same page:

On Mon, Jun 2, 2014 at 5:54 AM, James M Snell jasn...@gmail.com wrote:

 So long as they're handled with the same policy and restrictions as the
 script tag, it shouldn't be any worse.

HTML Imports are a bit more strict. They see CORS header and decline if
there is none for cross origin imports.
Also, requests for imports don't send any credentials to other origins.



 On Jun 2, 2014 2:35 AM, Anne van Kesteren ann...@annevk.nl wrote:

 How big of a problem is it that we're making link as dangerous as
 script? HTML imports can point to any origin which then will be able
 to execute scripts with the authority of same-origin.


 --
 http://annevankesteren.nl/




-- 
morrita


Re: HTML imports: new XSS hole?

2014-06-03 Thread Boris Zbarsky

On 6/3/14, 12:48 PM, Hajime Morrita wrote:

HTML Imports are a bit more strict. They see CORS header and decline if
there is none for cross origin imports.
Also, requests for imports don't send any credentials to other origins.


These two measures prevent attacks on other origins via imports.

It does nothing about attacks by the imported script on the page the 
import is happening into.


-Boris



Re: HTML imports: new XSS hole?

2014-06-03 Thread Oda, Terri
On Tue, Jun 3, 2014 at 9:59 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 6/3/14, 12:48 PM, Hajime Morrita wrote:

 HTML Imports are a bit more strict. They see CORS header and decline if
 there is none for cross origin imports.
 Also, requests for imports don't send any credentials to other origins.

 These two measures prevent attacks on other origins via imports.
 It does nothing about attacks by the imported script on the page the
 import is happening into.


Perhaps it would make sense to also require explicit allowing of imports
via CSP?  Scripts are allowed when no CSP is provided for historical
compatibility so you'd need to make sure that imports fell under a separate
directive, but there's no need for backwards compatibility so it probably
makes sense to choose a more conservative default behaviour for HTML
Imports.


HTML imports: new XSS hole?

2014-06-02 Thread Anne van Kesteren
How big of a problem is it that we're making link as dangerous as
script? HTML imports can point to any origin which then will be able
to execute scripts with the authority of same-origin.


-- 
http://annevankesteren.nl/



Re: HTML imports: new XSS hole?

2014-06-02 Thread James M Snell
So long as they're handled with the same policy and restrictions as the
script tag, it shouldn't be any worse.
On Jun 2, 2014 2:35 AM, Anne van Kesteren ann...@annevk.nl wrote:

 How big of a problem is it that we're making link as dangerous as
 script? HTML imports can point to any origin which then will be able
 to execute scripts with the authority of same-origin.


 --
 http://annevankesteren.nl/




Re: HTML imports: new XSS hole?

2014-06-02 Thread Anne van Kesteren
On Mon, Jun 2, 2014 at 2:54 PM, James M Snell jasn...@gmail.com wrote:
 So long as they're handled with the same policy and restrictions as the
 script tag, it shouldn't be any worse.

Well, script is assumed to be unsafe, link is not (at least not to
the same extent).


-- 
http://annevankesteren.nl/



Re: HTML imports: new XSS hole?

2014-06-02 Thread Boris Zbarsky

On 6/2/14, 8:54 AM, James M Snell wrote:

So long as they're handled with the same policy and restrictions as the
script tag, it shouldn't be any worse.


It's worse for sites that have some sort of filtering on user-provided 
content but don't catch this case right now, no?


-Boris



Re: HTML imports: new XSS hole?

2014-06-02 Thread James M Snell
Yup, like I said, it shouldn't be any worse. From what I've seen with
chrome, at the very least, import links are handled with the same CSP as
script tags. Which is certainly a good thing. I suppose that If you needed
the ability to sandbox them further, just wrap them inside a sandboxed
iframe. It's a bit ugly but it works.
On Jun 2, 2014 5:56 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Mon, Jun 2, 2014 at 2:54 PM, James M Snell jasn...@gmail.com wrote:
  So long as they're handled with the same policy and restrictions as the
  script tag, it shouldn't be any worse.

 Well, script is assumed to be unsafe, link is not (at least not to
 the same extent).


 --
 http://annevankesteren.nl/



Re: HTML imports: new XSS hole?

2014-06-02 Thread James M Snell
Yes, that's true. Content filters are likely to miss the links themselves.
Hopefully, the imported documents themselves get filtered, but there's no
guarantee. One assumption we can possibly make is that any implementation
that knows how to follow import links ought to know that they need to be
filtered. Im not aware of any current user agents that are not import aware
that automatically follow and execute link tags.
On Jun 2, 2014 6:12 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 6/2/14, 9:02 AM, James M Snell wrote:

 I suppose that If you
 needed the ability to sandbox them further, just wrap them inside a
 sandboxed iframe.


 The worry here is sites that currently have html filters for user-provided
 content that don't know about link being able to run scripts.  Clearly
 once a site knows about this they can adopt various mitigation strategies.
  The question is whether we're creating XSS vulnerabilities in sites that
 are currently not vulnerable by adding this functionality.

 -Boris

 P.S. A correctly written whitelist filter will filter these things out.
  Are we confident this is standard practice now?




Re: HTML imports: new XSS hole?

2014-06-02 Thread Boris Zbarsky

On 6/2/14, 9:22 AM, James M Snell wrote:

Yes, that's true. Content filters are likely to miss the links
themselves. Hopefully, the imported documents themselves get filtered


By what, exactly?  I mean, CSP will apply to them, but not website 
content filters...



One assumption we can possibly make is that
any implementation that knows how to follow import links ought to know
that they need to be filtered.


Sure, but that assumes the filtering we're talking about is being done 
by the UA to start with.


-Boris



Re: HTML imports: new XSS hole?

2014-06-02 Thread James M Snell
Im not saying it's perfect. Not by any stretch. I'm saying it shouldn't be
worse. Any impl that supports the mechanism will need to be aware of the
risk and content filters will need to evolve. Perhaps an additional
strongly worded warning in the spec would be helpful.
On Jun 2, 2014 6:43 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 6/2/14, 9:22 AM, James M Snell wrote:

 Yes, that's true. Content filters are likely to miss the links
 themselves. Hopefully, the imported documents themselves get filtered


 By what, exactly?  I mean, CSP will apply to them, but not website content
 filters...

  One assumption we can possibly make is that
 any implementation that knows how to follow import links ought to know
 that they need to be filtered.


 Sure, but that assumes the filtering we're talking about is being done by
 the UA to start with.

 -Boris



Re: HTML imports: new XSS hole?

2014-06-02 Thread Boris Zbarsky

On 6/2/14, 9:54 AM, James M Snell wrote:

Im not saying it's perfect. Not by any stretch. I'm saying it shouldn't
be worse.


I don't understand why you think it's not worse.


and content filters will need to evolve.


And until they do, we may have vulnerable pages, right?  How is that not 
worse?


Say an OS added some new functionality that meant software running on 
that OS would be insecure unless it got patched.  Would you consider 
that acceptable?  This is a pretty similar situation.


The only thing that might make this OK is if good whitelist-based 
filters are overwhelmingly used in practice.



Perhaps an additional
strongly worded warning in the spec would be helpful.


By what mechanism would someone who created a web page a year ago see 
this warning and go update their page?


-Boris



Re: HTML imports: new XSS hole?

2014-06-02 Thread Giorgio Maone
On 02/06/2014 15:01, Boris Zbarsky wrote:
 On 6/2/14, 8:54 AM, James M Snell wrote:
 So long as they're handled with the same policy and restrictions as the
 script tag, it shouldn't be any worse.

 It's worse for sites that have some sort of filtering on user-provided
 content but don't catch this case right now, no?

 -Boris


I do hope any filter already blocked out link elements, as CSS has
been a XSS vector for a long time, courtesy of MSIE expressions and XBL
bindings.
-- G




Re: HTML imports: new XSS hole?

2014-06-02 Thread Boris Zbarsky

On 6/2/14, 4:21 PM, Giorgio Maone wrote:

I do hope any filter already blocked out link elements, as CSS has
been a XSS vector for a long time


link elements without stylesheet in rel don't load CSS, though.

Hence the worries about blacklist vs whitelist...

-Boris



Re: HTML imports: new XSS hole?

2014-06-02 Thread James M Snell
Some initial informal testing shows that import links do make it through
the filters I have readily handy. It was quick work to write up some custom
filters, however.
On Jun 2, 2014 1:52 PM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 6/2/14, 4:21 PM, Giorgio Maone wrote:

 I do hope any filter already blocked out link elements, as CSS has
 been a XSS vector for a long time


 link elements without stylesheet in rel don't load CSS, though.

 Hence the worries about blacklist vs whitelist...

 -Boris




Re: HTML imports: new XSS hole?

2014-06-02 Thread Eduardo' Vela Nava
As with any new feature, there's the risk of introducing new security bugs
on applications that otherwise wouldn't have them. The usual argument goes
as follows:

Browser vendors have a lot of undocumented functionality, and it would be
foolish to create a blacklist approach on content filtering, since you
can't possibly know what are all the things the browser does.

There is a common counter-argument is that in some cases, you might
certainly ask to browser vendors is doing X safe? And they will be able
to say yes.

This is the perfect example of that.

Say you have a website, and you have a whitelist-based content filter. You
want to allow your users to run arbitrary CSS, so you HTML-sanitize their
content, and allow link tags. You thorougly check that the user's browser
is Chrome or Firefox latest version, and even, before load, you do a
runtime check to ensure that they are up-to-date and safe.

Now, CSS now a days in modern browsers (even Opera) is relatively safe
against JavaScript injection attacks. Sure, there are bugs every once in a
while, but browsers have been killing those features slowly and steadily.

So, this guy (let's call him Mark) comes to Blackhat and find the security
guy from Firefox and the security guy from Chrome, and hey, why not,
even a web security guy from Internet Explorer. Let's call them Dave,
Chris and Jesse. And they ask them during the Microsoft Party.. hey guys,
I want to make the internet more fun and allow people to run arbitrary CSS.
If I make sure to strip all PII from the document I'm injecting the CSS to,
there shouldn't be any way for the user to attack other parts of my web app
right???. And they all look at each other, think what is this guy doing?
and why doesn't he have a wristband? and eventually say you should use
seamless iframe sandboxes. And he goes home, and make a big company based
on that promise.

Now, fast-forward 2014. Turns out, he used iframe sandbox=allow-scripts
allow-same-origin because he wanted to append an event handler to the
sandboxed iframe content from the outer document, and until today, that
would have been safe.. because there was no PII to leak from that site
(perhaps.. visited state for links in some browsers?). He also, foolishly
assumed that since link tags can only be *really* used for CSS, he didn't
have to check for rel, since, well, you know, CSS was the worst thing
you could do from an iframe. He knew to remove secret data from the
document, since he read the existing literature and he learnt that you can
exfiltrate data with CSS, but he saw, as mentioned online many times, that
CSS-based XSS doesn't yield JavaScript execution anymore in modern browsers.

Now, fast-forward 2015. Some guy, let's call him Mario documents this
feature in a website, say, html5sec.org, and another guy, let's call him
Alex, is bored one weekend, and decided to well, go on a rampage and own
Mark's website to it's knees. Mark, baffled, can't understand what
happened. He literally followed the security advice from 3 of the top
browser vendors. WHYYY!?!?

He would be right to be upset. I think. We can't really expect Mark to know
about all obscure browser features and how the rest of the internet has to
evolve around them.

Well, turns out he is NOT right. Mark made three mistakes:
 1. He went to BlackHat seeking security advice. BlackHat isn't really the
place you go for learning about secure coding practices. Also, you
shouldn't go to a party that requires you to use a wrist band.
 2. He misused iframe@sandbox. allow-same-origin and allow-scripts probably
shouldn't be allowed together.. they make little sense (or if they are
allowed together, they should be making it clearer that all security
benefits went down the toilet).
 3. Finally, and most importantly, he designed a security feature by
himself, and decided not to be kept up to date (said in a different way, he
should be subscribed to some of these mailing lists).

Now, I'm not sure how many have tried to implement an HTML sanitizers. Even
a whitelist-based one has the following problems:
 1. You have to write a parser OR You have to use a third-party parser.
  1.1 This has the problem of writing-your-own is a headache, and you will
get it wrong. If you use a third-party parser, it'll most likely try to be
as lenient as flexible as possible, accepting malformed input (for
compatibility yay!).
 2. You have to get a serializer.
  2.1 This is way harder than the parser. Even browsers get it wrong (and
the FSM shall bless you if you need to write a serializer for CSS).
 3. You need a sane whitelist.
  3.1 And the whitelist, apparently, needs to be aware of not just
tag/attribute pairs, but also tag/attribute + rel=stylesheet geez!

That is to say, no one really has a good HTML sanitizers. Everyone either
over-protects, or has XSS. Possibly a mixture of both. So what can poor
Mark do?

I personally think that HTML imports are a nice feature (and I mean, I'm
legitimately happy about it, they sound 

Re: HTML imports: new XSS hole?

2014-06-02 Thread Boris Zbarsky

On 6/2/14, 11:17 PM, Eduardo' Vela Nava wrote:

Now, I'm not sure how many have tried to implement an HTML sanitizers.


I've reviewed Gecko's implementation of one, if that counts...


  1. You have to write a parser OR You have to use a third-party parser.


Wasn't an issue for us obviously.


  2. You have to get a serializer.


Likewise.


  3. You need a sane whitelist.


This was a pain.


   3.1 And the whitelist, apparently, needs to be aware of not just
tag/attribute pairs, but also tag/attribute + rel=stylesheet geez!


And this.  We actually rip out all @rel values specifically on link 
elements, because we in fact do not want to allow rel=stylesheet (but 
we do want to allow we do allow @rel on other elements)


I agree with your general point, though, which is that writing a good 
sanitizer is pretty nontrivial.


-Boris