Currently we can turn off allowFileAccessFromFileURLs() to enable security origin checking for file-based html. However it is too strict to be any useful. I have some lacks to polish and post here.
Make it PLATFORM(BLACKBERRY) only thing for now.
Created attachment 151140 [details] A test case The different behaviors of 3 desktop browsers: 1. Safari always allows file-to-file XHR request... no matter where the target is. 2. Google Chrome doesn't allow file-to-file XHR, even the target file is in same folder or subfolder. 3. FireFox allows XHR to a file in same folder or a subfolder. the objective of this bug is to add a policy, so webkit can be configured to do the same thing as firefox.
Created attachment 151141 [details] the patch
Comment on attachment 151141 [details] the patch forgot to put more info to the changelog
Created attachment 151143 [details] again
Please give me a chance to review this patch before landing. This stuff is very subtle.
Comment on attachment 151143 [details] again We shouldn't do this. The web security model doesn't support asymmetric access between frames.
(In reply to comment #7) > (From update of attachment 151143 [details]) > We shouldn't do this. The web security model doesn't support asymmetric access between frames. 1) This patch doesn't change the behavior of symmetric methods like equal() and isSameSchemeHostPort(). 2) The security model DOES support asymmetric access. 2.1) when a security origin has universal access, it can access those security origins that doesn't have universal access. For example, it can be configured to give file URL universal access and block HTTP URL from accessing file URL. 2.2) Whitelist isn't symmetric. A security origin may be able to access another because the target is in its whitelist. It is asymmetric. Can you think again?
> 1) This patch doesn't change the behavior of symmetric methods like equal() and isSameSchemeHostPort(). Right, but it encourages people to use canAccess in an asymmetric way, which doesn't work the way you'd expect. > 2) The security model DOES support asymmetric access. No, it doesn't. If A canAccess B, then B can hack A, which means that the relation isn't actually asymmetric. > 2.1) when a security origin has universal access, it can access those security origins that doesn't have universal access. For example, it can be configured to give file URL universal access and block HTTP URL from accessing file URL. Universal access is very insecure and should never be used. I would remove it from WebKit if I could. > 2.2) Whitelist isn't symmetric. A security origin may be able to access another because the target is in its whitelist. It is asymmetric. That's different because canRequest deals only with passive objects, like HTTP responses, not active objects like frames. > Can you think again? We've had this discussion many times over the years. The current policy isn't great, but it works ok. Folk shouldn't be using file URLs anyway. Their security model is completely broken.
(In reply to comment #9) > > 1) This patch doesn't change the behavior of symmetric methods like equal() and isSameSchemeHostPort(). > > Right, but it encourages people to use canAccess in an asymmetric way, which doesn't work the way you'd expect. > > > 2) The security model DOES support asymmetric access. > > No, it doesn't. If A canAccess B, then B can hack A, which means that the relation isn't actually asymmetric. > > > 2.1) when a security origin has universal access, it can access those security origins that doesn't have universal access. For example, it can be configured to give file URL universal access and block HTTP URL from accessing file URL. > > Universal access is very insecure and should never be used. I would remove it from WebKit if I could. > > > 2.2) Whitelist isn't symmetric. A security origin may be able to access another because the target is in its whitelist. It is asymmetric. > > That's different because canRequest deals only with passive objects, like HTTP responses, not active objects like frames. What if I apply this policy only to canRequest? That will at least solve some issues for sure. > > We've had this discussion many times over the years. The current policy isn't great, but it works ok. Folk shouldn't be using file URLs anyway. Their security model is completely broken. This is why I'm adding this policy, to make file URL work better. The policy doesn't affect any port/product as long as it is not turned on. No matter we like or don't like, file URLs is still being widely used. Many of our layout tests is based on file URL.
+More Currently WebKit can either be configured to allow file-based pages to access all file system (as Safari does), or block file-to-file access (as Google Chrome does). The former doesn't have any security check, and leaves potential security issues. The latter is too restrict and breaks many offline utilities. Assume that user has downloaded a full set of web pages to local file system, he is supposed to be able to browser the page offline with very little impact. And he shouldn't have to take the risk of having local private data leaked. I really think this new policy will be very helpful.
Created attachment 152297 [details] Remove the change to canAccess. It is only for request now.
Comment on attachment 152297 [details] Remove the change to canAccess. It is only for request now. Still think this is a bad idea. I'm not sure what you're planning to use this for, but I suspect there's a better solution that doesn't involve using file URLs.
(In reply to comment #13) > (From update of attachment 152297 [details]) > Still think this is a bad idea. I'm not sure what you're planning to use this for, but I suspect there's a better solution that doesn't involve using file URLs. I'm not using file URLs very often for myself. But there are people that do use file-based html utilities very often, and they work in FireFox and Safari. I cannot ask all of them to run a local http server on their own devices. The problem of Safari solution is it gives universal access to file URL's. Can you consider this as an enhancement of current Safari solution? Adding this policy doesn't force any products to use it. This just gives more options as other policies and settings do.
> I'm not using file URLs very often for myself. But there are people that do use file-based html utilities very often, and they work in FireFox and Safari. I cannot ask all of them to run a local http server on their own devices. Either that, or you can introduce a new URI scheme that has a sane security model, like the chrome-extension URI scheme. > The problem of Safari solution is it gives universal access to file URL's. Can you consider this as an enhancement of current Safari solution? There doesn't seem to be a problem to solve in Safari given that these utilities already work there. We're unlikely to adopt this policy in Chromium, so it's not going to solve your problem there either. > Adding this policy doesn't force any products to use it. This just gives more options as other policies and settings do. That's true, but it does make our local security checks even more complicated. I'd much rather make them simpler than more complicated.
(In reply to comment #15) > > I'm not using file URLs very often for myself. But there are people that do use file-based html utilities very often, and they work in FireFox and Safari. I cannot ask all of them to run a local http server on their own devices. > > Either that, or you can introduce a new URI scheme that has a sane security model, like the chrome-extension URI scheme. Can you point me somewhere I can find more information about this solution? > > > The problem of Safari solution is it gives universal access to file URL's. Can you consider this as an enhancement of current Safari solution? > > There doesn't seem to be a problem to solve in Safari given that these utilities already work there. We're unlikely to adopt this policy in Chromium, so it's not going to solve your problem there either. These utils already working there doesn't mean there is no problem. There is security concerns. When universal access is given to file URL, file-based html can make request to those files that are outside of its own folder, and then send to remote server. > > > Adding this policy doesn't force any products to use it. This just gives more options as other policies and settings do. > > That's true, but it does make our local security checks even more complicated. I'd much rather make them simpler than more complicated. I understand simplicity is good. But we do want to make things work better. The FireFox ways makes sense to me because usually people assume a file-based html package is organized in a folder, and behaves as the folder was the web site.
The Firefox policy is vastly more complicated that just allowing access in one folder. It's so complicated that the Firefox developer who implemented it couldn't explain it to me. He told me how he thought it worked, and I showed him a bunch of cases where it worked differently than he thought. As I wrote above, you should file another solution besides using file URLs. The security model for file URLs is broken beyond repair.
(In reply to comment #17) > The Firefox policy is vastly more complicated that just allowing access in one folder. It's so complicated that the Firefox developer who implemented it couldn't explain it to me. He told me how he thought it worked, and I showed him a bunch of cases where it worked differently than he thought. > > As I wrote above, you should file another solution besides using file URLs. The security model for file URLs is broken beyond repair. Speaking of simplicity, actually I think once the folder policy is done and accepted, we could remove one of these settings or maybe both. void setAllowUniversalAccessFromFileURLs(bool); bool allowUniversalAccessFromFileURLs() const { return m_allowUniversalAccessFromFileURLs; } void setAllowFileAccessFromFileURLs(bool); bool allowFileAccessFromFileURLs() const { return m_allowFileAccessFromFileURLs; }
> Speaking of simplicity, actually I think once the folder policy is done and accepted, we could remove one of these settings or maybe both. That's not correct. > void setAllowUniversalAccessFromFileURLs(bool); > bool allowUniversalAccessFromFileURLs() const { return m_allowUniversalAccessFromFileURLs; } This setting is required for Safari and backwards compatibility in the Mac OS X WebView. > void setAllowFileAccessFromFileURLs(bool); > bool allowFileAccessFromFileURLs() const { return m_allowFileAccessFromFileURLs; } This setting is required for Chromium. I can't speak for Safari, but I can tell you that Chromium does not want to adopt the "folder" policy.
(In reply to comment #19) > > Speaking of simplicity, actually I think once the folder policy is done and accepted, we could remove one of these settings or maybe both. > > That's not correct. > > > void setAllowUniversalAccessFromFileURLs(bool); > > bool allowUniversalAccessFromFileURLs() const { return m_allowUniversalAccessFromFileURLs; } > > This setting is required for Safari and backwards compatibility in the Mac OS X WebView. > > > void setAllowFileAccessFromFileURLs(bool); > > bool allowFileAccessFromFileURLs() const { return m_allowFileAccessFromFileURLs; } > > This setting is required for Chromium. > > I can't speak for Safari, but I can tell you that Chromium does not want to adopt the "folder" policy. Even though, setting one policy (or leaving default value) is still simpler than turning off 2 settings per page.
I feel like I'm repeating myself, but Chromium does not want to use the "folder" policy.