Re: [widgets] dropping Asynchronous HTTP Requests and Storage
These are common practices that are ready to be standardised to realize a benefit for widget developers and widget users. The argument of user agents having to support two storage mechanisms for widgets is a strawman: the cost for a UA to support the Widget Preferences (Storage) API and wire it to their existing storage implementation is trivial. However, the cost for widget developers to have to code multiple times for different UAs - and the opportunity cost to users and UAs where developers simply don't bother and end up sticking to developing for a single UA - is far greater. The only debate is whether to standardize the existing practice (Apple/ Nokia/Opera method signatures) or attempt to harmonise with future practice (use Web Storage method signatures). S On 6 Apr 2009, at 14:45, Anne van Kesteren wrote: On Mon, 06 Apr 2009 15:28:47 +0200, Scott Wilson scott.bradley.wil...@gmail.com wrote: A consistent preferences interface is crucial for widget interoperability; most of the widget platforms surveyed in the Landscape document have a Preferences API - and have been pretty consistent in how they've designed it. Its not exactly radical standardisation practice to take 5 existing implementations and harmonize them in a standard - in fact, not doing so is downright odd! Why would you standardize on a storage API, but not on a markup language, markup language API, styling language, styling language API, scripting language, etc.? It doesn't make a whole lot of sense to me. Especially if it leads to user agents having to support two storage mechanisms for widgets if they happen to have one already. -- Anne van Kesteren http://annevankesteren.nl/ smime.p7s Description: S/MIME cryptographic signature
Re: Do we need to rename the Origin header?
Thomas Roessler wrote on 4/6/2009 4:19 AM: On 3 Apr 2009, at 20:26, Jonas Sicking wrote: We've done a lot of discussions internally at mozilla, but was hoping that Adam Barth would start work somewhere so that we could send our feedback. Perhaps it's worthwhile to summarize the Mozilla-internal discussions and send them here first? I'm having a sense that much of what's needed right now is for somebody to ask the right questions. I would like to see it. Another option that I haven't seen proposed is to keep CORS-Origin and HTML5-Origin both named Origin but make them contextual, so that Origin when sent via CORS will behave as outlined in CORS, and Origin when sent via HTML5 will behave as outlined in HTML5. - Bil
Re: [widgets] dropping Asynchronous HTTP Requests and Storage
On Mon, 06 Apr 2009 16:26:15 +0200, Scott Wilson scott.bradley.wil...@gmail.com wrote: These are common practices that are ready to be standardised to realize a benefit for widget developers and widget users. The argument of user agents having to support two storage mechanisms for widgets is a strawman: the cost for a UA to support the Widget Preferences (Storage) API and wire it to their existing storage implementation is trivial. Maybe. It still increases QA cost (e.g. is the storage limit per API per widget or per widget, etc.) and confuses developers who have to pick one or the other. However, the cost for widget developers to have to code multiple times for different UAs - and the opportunity cost to users and UAs where developers simply don't bother and end up sticking to developing for a single UA - is far greater. You will have this problem regardless of how you solve this issue if you do not also require a specific scripting language, markup language, etc. The only debate is whether to standardize the existing practice (Apple/ Nokia/Opera method signatures) or attempt to harmonise with future practice (use Web Storage method signatures). -- Anne van Kesteren http://annevankesteren.nl/
Re: [widgets] remove update related methods form AE
On Apr 6, 2009, at 15:36 , Marcos Caceres wrote: I would like to propose we get remove the following methods from the AE spec: 7.17 The onbeforeupdate Callback 7.18 The onafterupdate Callback For onbeforeupdate, there is no guarantee that the widget will be running when an update is takes place. For onafterupdate, late binding of this may make this method impractical or just unusable. I.e., when would this method be called? When the widget restarts, but after document.onload or before document.onload? etc. Agreed, in many ways they are like install/uninstall, they don't need to be exposed (and any use case I can think of can be done without them). -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Do we need to rename the Origin header?
Bil Corry wrote on 4/6/2009 9:32 AM: Another option that I haven't seen proposed is to keep CORS-Origin and HTML5-Origin both named Origin but make them contextual, so that Origin when sent via CORS will behave as outlined in CORS, and Origin when sent via HTML5 will behave as outlined in HTML5. Nevermind, I forgot that Adam conceded to changing his original Origin spec to match the redirect behavior in CORS, and reading through his draft, I see the change has been made to make them compatible. - Bil [1] http://www.ietf.org/internet-drafts/draft-abarth-origin-00.txt
Re: [widgets] dropping Asynchronous HTTP Requests and Storage
On Apr 6, 2009, at 6:46 AM, ext Marcos Caceres wrote: I had a discussion with Anne on IRC about using the Storage interface and XHR [1]. He recommended that we recommend support for Storage only on user agents that support HTML5. With regards to XHR, the same applies: it would be a property of the underlying document technology. So, proposal are: drop Asynchronous HTTP Requests requirement [2] and remove its support from Widgets 1.0: AE. Regarding dropping XHR, Marcos and I chatted about this [1] and since none of the functionality in the A+E spec actually requires XRR, I agree with the proposal to remove the related statement in Section 3.1. Regarding the requirement ([2] below), I think it is a reasonable requirement for a Widget User Agent so I would keep it despite none of our existing specs in progress address it (ATM). -Regards, Art Barstow [1] http://krijnhoetmer.nl/irc-logs/webapps/20090406 For Storage, specify that only HTML-aware UAs support Storage interface. Kind regards, Marcos [1] http://krijnhoetmer.nl/irc-logs/webapps/20090403#l-36 [2] http://dev.w3.org/2006/waf/widgets-reqs/#asynchronous-http- requests
Re: [widgets] remove update related methods form AE
On Apr 6, 2009, at 10:36 AM, ext Marcos Caceres wrote: I would like to propose we get remove the following methods from the AE spec: 7.17 The onbeforeupdate Callback 7.18 The onafterupdate Callback For onbeforeupdate, there is no guarantee that the widget will be running when an update is takes place. For onafterupdate, late binding of this may make this method impractical or just unusable. I.e., when would this method be called? When the widget restarts, but after document.onload or before document.onload? etc. I support this proposal. Marcos - if there are no objections by April 10, please implement your proposal. -Regards, Art Barstow
[cors] security issue with XMLHttpRequest API compatibility
It looks like the client-side API for cross-origin messaging is the same as the current XMLHttpRequest API. I think there's a security issue with this decision. The current XMLHttpRequest implementation drops any attempted cross-origin request. This implementation protects a client-side application that inadvertently sends a request to an unexpected target URL. Since the request is dropped by the browser implementation, any client credentials (such as a password) in the request body are not exposed to the wrong server. Since XMLHttpRequest has, to date, provided this protection, client scripts have had no real need to vet the URLs that they send messages to. Consequently, it seems unlikely that these scripts do any vetting of their target URLs. It may be possible for an attacker to cause a client script in another domain to send a request to a target URL on the attacker's server. Since the attacker controls his server, the resource can be marked as accepting cross-domain requests. Since the client script wasn't expecting such requests to succeed, it may include client credentials in the sent request. Whether or not a particular web application is vulnerable to this kind of attack requires studying the particular application and how it obtains the target URLs that it sends requests to, to see if there is an opportunity for an attacker to inject an unexpected URL. --Tyler
Re: Do we need to rename the Origin header?
On Mon, Apr 6, 2009 at 2:19 AM, Thomas Roessler t...@w3.org wrote: Perhaps it's worthwhile to summarize the Mozilla-internal discussions and send them here first? I'm having a sense that much of what's needed right now is for somebody to ask the right questions. I'll let someone from Mozilla fill in the details, but the general idea is twofold: 1) Enable CSRF mitigation for GET requests. 2) Providing additional information in the header to help mitigate ClickJacking as well. To achieve (1), the Mozilla proposal sends the header (let's call it Blame-List for easy of discussion) for some GET requests, depending on how the requests were generated. For example, a hyperlink or an image would not send Blame-List, but a form submission would. To achieve (2), the Blame-List contains not only the origin that initiated the request, but also the origin of all the ancestor frames. For example, if attacker.com created an iframe to example.com, and the user clicked on the buy button inside of the example.com iframe, the header would look something like this: Blame-List: http://example.com http://attacker.com I believe Mozilla has fleshed out the details in a document somewhere. Adam
Re: Do we need to rename the Origin header?
On Mon, Apr 6, 2009 at 8:01 AM, Bil Corry b...@corry.biz wrote: Nevermind, I forgot that Adam conceded to changing his original Origin spec to match the redirect behavior in CORS, and reading through his draft, I see the change has been made to make them compatible. Yes. This is not ideal from a CSRF mitigation point of view, but it is workable. Adam
Re: Do we need to rename the Origin header?
Brandon Sterne wrote on 4/6/2009 3:34 PM: I'm adding Sid, who has been editing the document: https://wiki.mozilla.org/Security/Origin As is mentioned in the first section of that document, the name of the proposed header is subject to change. I'm confused, what is the relationship of this Origin (let's call it Moz-Origin): https://wiki.mozilla.org/Security/Origin To this Origin (IETF-Origin)? http://www.ietf.org/internet-drafts/draft-abarth-origin-00.txt - Bil
Re: Do we need to rename the Origin header?
Brandon Sterne wrote on 4/6/2009 3:34 PM: I'm adding Sid, who has been editing the document: https://wiki.mozilla.org/Security/Origin As is mentioned in the first section of that document, the name of the proposed header is subject to change. If you're going for an entirely new header, then you should consider adding the redirect path as well to it: Origin: origin host frame-ancestor*[, redirect-host]* So site A frames B which frames C that then POSTs to D, which redirects to E which redirects to F becomes: Origin: C B A, D, E - Bil
Re: [cors] security issue with XMLHttpRequest API compatibility
On Mon, Apr 6, 2009 at 1:54 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Apr 6, 2009 at 11:29 AM, Tyler Close tyler.cl...@gmail.com wrote:
It looks like the client-side API for cross-origin messaging is the
same as the current XMLHttpRequest API. I think there's a security
issue with this decision. The current XMLHttpRequest implementation
drops any attempted cross-origin request. This implementation protects
a client-side application that inadvertently sends a request to an
unexpected target URL. Since the request is dropped by the browser
implementation, any client credentials (such as a password) in the
request body are not exposed to the wrong server. Since XMLHttpRequest
has, to date, provided this protection, client scripts have had no
real need to vet the URLs that they send messages to. Consequently, it
seems unlikely that these scripts do any vetting of their target URLs.
It may be possible for an attacker to cause a client script in another
domain to send a request to a target URL on the attacker's server.
Since the attacker controls his server, the resource can be marked as
accepting cross-domain requests. Since the client script wasn't
expecting such requests to succeed, it may include client credentials
in the sent request.
How would the script include client credentials in the request? Can
you show some an example of the type of script you are concerned
about?
Using a variation on the example in the spec...
var password = ... // global variable holds user's password
function deleteItem(itemURL, updateUI) {
var client = new XMLHttpRequest()
client.open(DELETE, itemURL)
client.onload = updateUI
client.onerror = updateUI
client.onabort = updateUI
client.send(password= + password)
}
So now we have to wonder where the value for the itemURL parameter
comes from. Perhaps it comes from an HTML element in the current
document, and has a value that was determined by the attacker in some
previous interaction. For example, perhaps this is code from a shared
blogging site. The function is deleting items from an Atom collection
and the itemURL came from a feed representation. If the author of that
feed is the attacker, he might be able to use an item URL that refers
to a resource on his own server, rather than on the shared blogging
site. Before [cors], this attack would not have worked, since the
browser would have dropped the request on the floor. Now the request
goes through.
--Tyler
Re: [cors] security issue with XMLHttpRequest API compatibility
Using a variation on the example in the spec...
var password = ... // global variable holds user's password
function deleteItem(itemURL, updateUI) {
var client = new XMLHttpRequest()
client.open(DELETE, itemURL)
client.onload = updateUI
client.onerror = updateUI
client.onabort = updateUI
client.send(password= + password)
}
Well, if a script can rely on someone being as foolish as to store
their username and password as globals then why bother working that
hard...just ping a url with them. I can't see how this is relevant to
the spec in terms of a specific vulnerability.
ss
Re: [cors] security issue with XMLHttpRequest API compatibility
On Mon, Apr 6, 2009 at 2:23 PM, Tyler Close tyler.cl...@gmail.com wrote:
On Mon, Apr 6, 2009 at 1:54 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Apr 6, 2009 at 11:29 AM, Tyler Close tyler.cl...@gmail.com wrote:
It looks like the client-side API for cross-origin messaging is the
same as the current XMLHttpRequest API. I think there's a security
issue with this decision. The current XMLHttpRequest implementation
drops any attempted cross-origin request. This implementation protects
a client-side application that inadvertently sends a request to an
unexpected target URL. Since the request is dropped by the browser
implementation, any client credentials (such as a password) in the
request body are not exposed to the wrong server. Since XMLHttpRequest
has, to date, provided this protection, client scripts have had no
real need to vet the URLs that they send messages to. Consequently, it
seems unlikely that these scripts do any vetting of their target URLs.
It may be possible for an attacker to cause a client script in another
domain to send a request to a target URL on the attacker's server.
Since the attacker controls his server, the resource can be marked as
accepting cross-domain requests. Since the client script wasn't
expecting such requests to succeed, it may include client credentials
in the sent request.
How would the script include client credentials in the request? Can
you show some an example of the type of script you are concerned
about?
Using a variation on the example in the spec...
var password = ... // global variable holds user's password
function deleteItem(itemURL, updateUI) {
var client = new XMLHttpRequest()
client.open(DELETE, itemURL)
client.onload = updateUI
client.onerror = updateUI
client.onabort = updateUI
client.send(password= + password)
}
So now we have to wonder where the value for the itemURL parameter
comes from. Perhaps it comes from an HTML element in the current
document, and has a value that was determined by the attacker in some
previous interaction. For example, perhaps this is code from a shared
blogging site. The function is deleting items from an Atom collection
and the itemURL came from a feed representation. If the author of that
feed is the attacker, he might be able to use an item URL that refers
to a resource on his own server, rather than on the shared blogging
site. Before [cors], this attack would not have worked, since the
browser would have dropped the request on the floor. Now the request
goes through.
Ah, ok, I'm following you now.
This seems like a very risky situation already for the site since it
would allow for an attacker to issue a DELETE request to any URI on
the site. A request that would include the users credentials such as
auth tokens and session-id bearing cookies. So the site has
essentially CSRFed itself in a pretty bad way.
But I do agree that it adds I do agree that this is a theoretical
risk. I'm not sure if this risk is big enough that it's something that
we need to adjust the specs to.
Input from others is very welcome.
/ Jonas
Re: [cors] security issue with XMLHttpRequest API compatibility
On Tue, 07 Apr 2009 01:37:05 +0200, Tyler Close tyler.cl...@gmail.com wrote: I don't have any numbers, but I believe using a plaintext password in the request body or URL is a fairly common design in web applications. I certainly see it in a lot of protocol documentation. Before CORS, there was no threat of this password being sent to the wrong site, since the client code could only message with the one site. Now the attacker can instruct the browser to message with additional sites. That's wrong actually. There are plenty of ways to send messages cross-origin nowadays: * img src * iframe src * object data * embed src * form action * script src * 'background-image' * 'cursor' * 'list-style-image' * ... (All can be instantiated from script, in case that was not clear.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [cors] security issue with XMLHttpRequest API compatibility
Well, Anne, as I said in the previous paragraph, the one you deleted, I'm considering an application that does its messaging via XMLHttpRequest. Sheesh. --Tyler On Mon, Apr 6, 2009 at 4:47 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 07 Apr 2009 01:37:05 +0200, Tyler Close tyler.cl...@gmail.com wrote: I don't have any numbers, but I believe using a plaintext password in the request body or URL is a fairly common design in web applications. I certainly see it in a lot of protocol documentation. Before CORS, there was no threat of this password being sent to the wrong site, since the client code could only message with the one site. Now the attacker can instruct the browser to message with additional sites. That's wrong actually. There are plenty of ways to send messages cross-origin nowadays: * img src * iframe src * object data * embed src * form action * script src * 'background-image' * 'cursor' * 'list-style-image' * ... (All can be instantiated from script, in case that was not clear.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [cors] security issue with XMLHttpRequest API compatibility
On Mon, Apr 6, 2009 at 5:36 PM, Tyler Close tyler.cl...@gmail.com wrote: On Mon, Apr 6, 2009 at 5:21 PM, Jonas Sicking jo...@sicking.cc wrote: Additionally, if the attacker can make a GET request happen to any URI but with a sensitive password added, it is quite likely that this could be directed to some URI on the site that will for example insert a comment into a forum, or otherwise publish the data to somewhere where it can be read. If the site abuses GET in this way, then it is vulnerable to damage via a simple img tag constructed by the attacker (assuming the password rides along in a cookie, as is common). I don't mean that the harm is in that you can use CSRF attacks against the site to insert forum posts. The attack against the site would go something like this: 1. Trick the site to issue a GET request to a URL that adds a post to a public forum. 2. Go to said public forum 3. Read the newly posted item The URL in 1 will include the password since that was added to the URL. It's possible that this will result in the password being part of the posted forum item. In step 3 then you can read the secret password. This works in todays browsers that don't have cross site XMLHttpRequest. For every single feature we add, security related or otherwise, there is a theoretical risk that a security problem can appear on a site. We have to weigh that risk against the benefits that the feature provides, otherwise we are never going to build anything new. Seems simple enough to solve this problem by not substituting the cross-site API for the non-cross-site API. Just using different constructors and keeping the interface API the same would be sufficient. While this is simple to do on the implementation side, it results in bloat on the usage side. I.e. we're adding more API to the web development platform. Additionally the API we're adding has a very subtle difference, and one that is different only in the security model. I do have a very hard time judging what the right thing to do here is. I do agree there is a risk that what you are describing can happen. However I judge the risk to be very small, but non-zero. And the risk will decrease with time as people become aware of this new API. And the only solution is IMHO bad since it increases the complexity of the platform, which we'll have to live with for the foreseeable future. / Jonas
Re: [widgets] dropping Asynchronous HTTP Requests and Storage
On Mon, Apr 6, 2009 at 8:48 AM, Scott Wilson scott.bradley.wil...@gmail.com wrote: On 6 Apr 2009, at 15:33, Anne van Kesteren wrote: You will have this problem regardless of how you solve this issue if you do not also require a specific scripting language, markup language, etc. It seems to be rather strongly _implied_ that widgets will use HTML, ECMAScript and CSS... Could we also similarly imply that the .localStorage API also be implemented? This is especially easy now that localStorage is becoming its own spec [1]. / Jonas [1] http://dev.w3.org/html5/webstorage/
