- From: Adam Barth <w3c@adambarth.com>
- Date: Sat, 22 Jun 2013 21:54:42 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: WebAppSec WG <public-webappsec@w3.org>
On Thu, Jun 20, 2013 at 12:20 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Thu, Jun 20, 2013 at 4:16 PM, Anne van Kesteren <annevk@annevk.nl> wrote: >> What it says about XMLHttpRequest is wrong. Fetching happens after >> send() is invoked (or during for synchronous requests). Yeah, I'm happy to re-write that section once the fetch spec provides the proper hooks. > Also, grouping WebSocket into this seems somewhat weird as WebSocket > does something different from fetching. And XMLHttpRequest/EventSource > are not too different from what <img> can do. > > What were the criteria used for this? I don't think we had a particularly rigorous criteria. The connect-src directive is a bit of a grab-bag of various script APIs for connecting to remote servers. It's true that WebSockets doesn't use "fetch" internally, but the underlying connection method isn't that relevant to which directive bucket we put the API into. As for XMLHttpRequest/EventSource not being too different from <img> in capability, the difference from CSP's point of view is that an HTML injection can trigger an <img> load without needing to first trigger script execution because <img> loads can be initiated from markup directly. The reason we've put script-based networking APIs into a separate bucket is because they're more difficult for an attacker to exploit: the attacker first needs to execute script before he or she can try to abuse script-based APIs. > I'm trying to make sense of http://wiki.whatwg.org/wiki/Contexts (and > improve it) for eventual convergence between CSP and Fetch. That sounds wonderful. Please let me know if I can be of further assistance. If you like, we can use a different context for fetch-based APIs (e.g., XMLHttpRequest) and WebSockets. The connect-src directive can say that it applies to both contexts. Adam
Received on Sunday, 23 June 2013 04:55:41 UTC