Dev,

Indeed, I'm worried about what other people could do with the feature
too. I'm much more worried though about the bad stuff that they're
already doing in their PHP that the browser can't check it in any way.
I think the nice thing about my patch is that it's not enough just to
set a flag in the JavaScript, you have to write some server-side code
for the browser to receive the right WebSocket headers. That's enough
to prevent anyone stumbling across the feature by accident. There
might still be people who aren't careful, but by this stage, they've
jumped through enough hoops and written enough server-side code (which
the browser can't verify) that we may as well stop worrying. There's
little practical difference in security from the browser's point of
view.

I added some comments about CSP to the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=924957 Could you comment
there if you'd want to say more?

I'm only interested in opening up a very small loophole for really
dedicated webapp developers, so I'm in favour of requiring a strict
CSP. It's a sensible addition to the mixed-content heuristic, and
addresses one of the big security concerns with allowing these sorts
of WebSocket connections. Hopefully that will Mozilla happier with the
patch.

Nick

-----
Nicholas Wilson: nicho...@nicholaswilson.me.uk


On 14 October 2013 04:01, Devdatta Akhawe <dev.akh...@gmail.com> wrote:
> Nicholas,
>
> I am sure the protocol and encryption you have written is solid and
> secure. The concern is that once this is opened up, it will be open
> for all and others won't be so careful. There are lots of examples of
> people not implementing the crypto correctly.
>
> Re the leaking of sensitive data: browsers already make a practical
> decision to let some of that data leak by e.g., allowing passive
> content over HTTP on HTTPS pages (last I checked). I was arguing that
> once a strong CSP policy is enforced, one can reasonably be certain
> that arbitrary code won't execute.* In that case, the insecure XHR/WS
> data can't convert to code (which is presumably the reason it was
> treated as active content originally) and thus should be treated as
> passive content and allowed.
>
> ~Dev
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Reply via email to