Re: HTTP access control confusion
On Fri, Jul 30, 2010 at 1:45 PM, Tab Atkins Jr. wrote: > On Thu, Jul 29, 2010 at 8:10 AM, Douglas Beck wrote: >> I have recently read through: >> https://developer.mozilla.org/En/HTTP_access_control >> https://wiki.mozilla.org/Security/Origin >> >> I've discussed what I've read and learned with my coworkers and there's been >> some confusion. I understand and appreciate the need for a security policy >> that allows for cross-site https requests. I do not understand how >> Access-Control-Allow-Origin addresses usability and security concerns. >> >> The basis of our confusion: >> I create domain-a.com and I want to make an ajax request to domain-b.com. A >> preflight request is made to domain-b, domain-b responds with if it is safe >> to send the request. >> >> Does it not make more sense for me (the author of domain-a) to define the >> security policy of my website? I know each and every request that should be >> made on my site and can define a list of all acceptable content sources. If >> the preflight request is made to domain-a (not domain-b) then the content >> author is the source of authority. >> >> A more functional example (and the source of my curiosity), I work for the >> University of Central Florida. I am currently working on a subdomain that >> wants to pull from the main .edu TLD. The university has yet to define an >> Access-Control header policy, so my subdomain is unable to read what's >> available on the main .edu website. >> >> Additionally, if I am working with authorized content, it would be useful >> for me to define/limit where cross-site requests can be made. It seems >> backwards that an external source can define a security policy that effects >> the usability of my content. > > As the author of your site, you *already* have complete control over > where cross-site requests can be made. If you don't want to make a > particular cross-site request, *just don't make that request*. > > On the other hand, the content source doesn't have that kind of > control. They can't prevent you from making requests to them that > they don't want, or allow requests that they like. That's where the > same-origin policy (default deny all such requests) and CORS > (selectively allow certain requests) comes in. > > I suppose you might be thinking of a situation where you are allowing > untrusted users to add content to your site, and you only want them to > be able to link to specific other sites. Same-origin restrictions do > part of this for you automatically. Most of the rest should be > handled by you in the first place - if untrusted users are doing XHRs, > you've got bigger problems. > > ~TJ Untrusted users (or untrusted content) will probably be doing XHRs quite frequently (this is almost the definition of a widget). You just need to ensure that they're running inside a sandboxed iframe (or something like Caja) so that they can't exploit your site as easily. -- Dirk
Re: HTTP access control confusion
On Thu, Jul 29, 2010 at 8:10 AM, Douglas Beck wrote: > I have recently read through: > https://developer.mozilla.org/En/HTTP_access_control > https://wiki.mozilla.org/Security/Origin > > I've discussed what I've read and learned with my coworkers and there's been > some confusion. I understand and appreciate the need for a security policy > that allows for cross-site https requests. I do not understand how > Access-Control-Allow-Origin addresses usability and security concerns. > > The basis of our confusion: > I create domain-a.com and I want to make an ajax request to domain-b.com. A > preflight request is made to domain-b, domain-b responds with if it is safe > to send the request. > > Does it not make more sense for me (the author of domain-a) to define the > security policy of my website? I know each and every request that should be > made on my site and can define a list of all acceptable content sources. If > the preflight request is made to domain-a (not domain-b) then the content > author is the source of authority. > > A more functional example (and the source of my curiosity), I work for the > University of Central Florida. I am currently working on a subdomain that > wants to pull from the main .edu TLD. The university has yet to define an > Access-Control header policy, so my subdomain is unable to read what's > available on the main .edu website. > > Additionally, if I am working with authorized content, it would be useful > for me to define/limit where cross-site requests can be made. It seems > backwards that an external source can define a security policy that effects > the usability of my content. As the author of your site, you *already* have complete control over where cross-site requests can be made. If you don't want to make a particular cross-site request, *just don't make that request*. On the other hand, the content source doesn't have that kind of control. They can't prevent you from making requests to them that they don't want, or allow requests that they like. That's where the same-origin policy (default deny all such requests) and CORS (selectively allow certain requests) comes in. I suppose you might be thinking of a situation where you are allowing untrusted users to add content to your site, and you only want them to be able to link to specific other sites. Same-origin restrictions do part of this for you automatically. Most of the rest should be handled by you in the first place - if untrusted users are doing XHRs, you've got bigger problems. ~TJ
Re: HTTP access control confusion
On 7/29/10 11:10 AM, Douglas Beck wrote: The basis of our confusion: I create domain-a.com and I want to make an ajax request to domain-b.com. A preflight request is made to domain-b, domain-b responds with if it is safe to send the request. Does it not make more sense for me (the author of domain-a) to define the security policy of my website? I think the source of your confusion is that HTTP access control in the above scenario is protecting domain-b from domain-a. It's not protecting domain-a. Thus the security policy needs to be defined by domain-b. I know each and every request that should be made on my site and can define a list of all acceptable content sources. The point here is that domain-a should not be able to get data from domain-b using the user's credentials that it wouldn't be able to get otherwise. No one here is trying to protect domain-a from getting the "wrong" data or something. A more functional example (and the source of my curiosity), I work for the University of Central Florida. I am currently working on a subdomain that wants to pull from the main .edu TLD. The university has yet to define an Access-Control header policy, so my subdomain is unable to read what's available on the main .edu website. Unfortunately, there's no obvious way to distinguish your situation from an attack on the main .edu website trying to get unauthorized information from it... Additionally, if I am working with authorized content, it would be useful for me to define/limit where cross-site requests can be made. This is legitimate useful use-case. The proposed technology for handling it is http://people.mozilla.com/~bsterne/content-security-policy/details.html (see the "xhr-src" directive). It seems backwards that an external source can define a security policy that effects the usability of my content. Here's an illustration of what HTTP access control is supposed to prevent. A user visits your website. You do an XHR to a bankofamerica.com URL on the off chance that the user is a Bank of America customer and is currently logged in. If this XHR were allowed you would at the very least be able to read information about the user's account, and depending on the setup of the bankofamerica.com site may be able to do things like transfer money. _That_ is the threat HTTP access control is meant to mitigate. While it might be convenient if you could show the user information about their bank account on your site in some circumstances, that's something the bank (or ideally the user, but that's harder to set up) needs to opt into. Hope that helps, Boris
Re: HTTP access control confusion
* Douglas Beck wrote: >I create domain-a.com and I want to make an ajax request to >domain-b.com. A preflight request is made to domain-b, domain-b >responds with if it is safe to send the request. > >Does it not make more sense for me (the author of domain-a) to define >the security policy of my website? I know each and every request that >should be made on my site and can define a list of all acceptable >content sources. If the preflight request is made to domain-a (not >domain-b) then the content author is the source of authority. How the domains interact with each other is their business, the question is whether the user wants his browser to act as proxy for communication between those domains, in your case, whether he is okay with letting the domain domain-a impersonate you when communicating with domain-b. As an example, university networks are often configured to deny access to some resources from outside the network, but grant access to anyone within the network. If you can trick someone within the network to access your site, you would inherit their privileges inside the university network. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
HTTP access control confusion
I have recently read through: https://developer.mozilla.org/En/HTTP_access_control https://wiki.mozilla.org/Security/Origin I've discussed what I've read and learned with my coworkers and there's been some confusion. I understand and appreciate the need for a security policy that allows for cross-site https requests. I do not understand how Access-Control-Allow-Origin addresses usability and security concerns. The basis of our confusion: I create domain-a.com and I want to make an ajax request to domain-b.com. A preflight request is made to domain-b, domain-b responds with if it is safe to send the request. Does it not make more sense for me (the author of domain-a) to define the security policy of my website? I know each and every request that should be made on my site and can define a list of all acceptable content sources. If the preflight request is made to domain-a (not domain-b) then the content author is the source of authority. A more functional example (and the source of my curiosity), I work for the University of Central Florida. I am currently working on a subdomain that wants to pull from the main .edu TLD. The university has yet to define an Access-Control header policy, so my subdomain is unable to read what's available on the main .edu website. Additionally, if I am working with authorized content, it would be useful for me to define/limit where cross-site requests can be made. It seems backwards that an external source can define a security policy that effects the usability of my content. I sincerely appreciate any time you can give explaining the policy. Thank you for all the great work that's been done. Sincerely, Douglas Beck -- Douglas Beck Web Communications | 407.823.1699
Re: Lifetime of Blob URL
On Thu, Jul 29, 2010 at 4:33 PM, Jonas Sicking wrote: > Sorry about the slow response. I'm currently at blackhat, so my > internet connectivity is somewhat... unreliable, so generally having > to try to stay off the webs :) > > On Tue, Jul 27, 2010 at 1:16 PM, Dmitry Titov wrote: > > Thanks Jonas, > > Just to clarify some details we had while discussing this, could you > confirm > > if this matches with your thinking (or not): > > 1. If blob was created in window1, blob.url was queried, then passed (as > JS > > object) to window2, and window1 was closed - then the url gets > invalidated > > when window1 is closed, but immediately re-validated if window2 queries > > blob.url. The url string is going to be the same, only there will be a > time > > interval between closing window1 and querying blob.url in window2, during > > which loading from the url returns 404. > > Actually, it might make sense to make blob.url, when queried by > window2, return a different string. This makes things somewhat more > consistent as to when a URL is working an when not. > Now suppose window2 queries the .url attribute before window1 is closed? I think most people would expect the same value as returned in window1 (yes?). Having the same or different value depending on whether the attribute was queried before or after another window was closed seems confusing. I think having the .url remain consistent from frame to frame/window to window could help with debugging. Without fully understanding the gap between blob and .url life time, some folks are going to be mystified by when/why a url value stops working, or why the .url value is sometimes different than it was before. There are some pretty hidden side affect of accessing that attribute in a particular frame. These subtle oddities with the .url attribute are in part what originally motivated the proposal to make it more explicit. We're trying to make blob.url easy and natural feeling, but with too many caveats, will it be? I guess that's a long winded vote for resurrecting the same url value used in window1 in the particular case Dmitry raised. > > I.e. you're less likely to end up covering up a bug due to a URL > coming back to life because another page started using a blob whose > URL you were previously handed. > > It's a somewhat unlikely scenario so I don't feel very strongly either way. > > > 2. If blob is sent to a Worker via worker.postMessage(blob), the > 'structured > > clone' mechanism is used, so on the other side of postMessage a new blob > > object is created, backed by the same data, but having its own unique > > blob.url string (and separate lifetime). > > Yes. > > / Jonas > > > On Mon, Jul 26, 2010 at 2:12 PM, Jonas Sicking wrote: > >> > >> On Tue, Jul 13, 2010 at 7:37 AM, David Levin wrote: > >> > On Tue, Jul 13, 2010 at 6:50 AM, Adrian Bateman < > adria...@microsoft.com> > >> > wrote: > >> >> > >> >> On Monday, July 12, 2010 2:31 PM, Darin Fisher wrote: > >> >> > On Mon, Jul 12, 2010 at 9:59 AM, David Levin > >> >> > wrote: > >> >> > On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman > >> >> > > >> >> > wrote: > >> >> > I read point #5 to be only about surviving the start of a > navigation. > >> >> > As > >> >> > a > >> >> > web developer, how can I tell when a load has started for an ? > >> >> > Isn't > >> >> > this similarly indeterminate. > >> >> > > >> >> > As soon as img.src is set. > >> >> > > >> >> > "the spec could mention that the resource pointed by blob URL > should > >> >> > be > >> >> > loaded successfully as long as the blob URL is valid at the time > when > >> >> > the > >> >> > resource is starting to load." > >> >> > > >> >> > Should apply to xhr (after send is called), img, and navigation. > >> >> > > >> >> > Right, it seems reasonable to say that ownership of the resource > >> >> > referenced > >> >> > by a Blob can be shared by a XHR, Image, or navigation once it is > >> >> > told > >> >> > to > >> >> > start loading the resource. > >> >> > > >> >> > -Darin > >> >> > >> >> It sounds like you are saying the following is guaranteed to work: > >> >> > >> >> img.src = blob.url; > >> >> window.revokeBlobUrl(blob); > >> >> return; > >> >> > >> >> If that is the case then the user agent is already making the > >> >> guarantees > >> >> I was talking about and so I still think having the lifetime mapped > to > >> >> the > >> >> blob > >> >> not the document is better. This means that in the general case I > don't > >> >> have > >> >> to worry about lifetime management. > >> > > >> > Mapping lifetime to the blob exposes when the blob gets garbage > >> > collected > >> > which is a very indeterminate point in time (and is very browser > version > >> > dependent -- it will set you up for compatibility issues when you > update > >> > your javascript engine -- and there are also the cross browser issues > of > >> > course). > >> > Specifically, a blob could go "out of scope" (to use your earlier > >> > phrase) > >> > and then one could do im
