Custom schemes registered with CefRegisterScheme are treated as standard even when they aren't

[GoogleCodeExporter]

What steps will reproduce the problem?
1. create a scheme, e.g., foo:
2. register it with CefRegisterScheme with an empty string for host
3. load a file:// url
4. access a URL with your custom scheme, e.g.,

a. AJAX access with JSON datatype to foo:bar
b. AJAX access with JSON datatype to foo://bar
c. AJAX access with JSON datatype to foo:///bar
d. AJAX access with JSON datatype to foo:///bar%2Fbar

What is the expected output? 
I expect my handler to be called with the appropriate URLs. Note that "bar" is 
scheme-specific data and should not be interpreted as a host for same-origin 
purposes.

a. called with URL foo:bar
b. called with URL foo://bar
c. called with URL foo:///bar
d. called with URL foo:///bar%2Fbar

What do you see instead?
a. called with URL of foo://bar/
b. never called (presumably same orgin failure)
c. called with URL of foo://bar/
d. never called (the escaped character is invalid in a DNS host)

What version of the product are you using? On what operating system?
v.162 Vista 64-bit

Please provide any additional information below.
CefRegisterScheme is registering all schemes as "standard", which triggers 
standard canonicalization and parsing by Chrome/Webkit. If the URL is 
non-standard, like a data: or javascript: URL, this mangles the URL and may 
fail if the URL has characters that are invalid in a standard URL's hot.

A custom scheme accessed from a null origin resource (such as file://) for a 
same-origin restricted function (such as AJAX), would allow malicious  code 
could to use foo:///bar.com/index.html to bypass the origin check and reach 
foo://bar.com/index.html (because that's what it becomes after 
canonicalization).

FWIW, the failure mode is triggered in Chrome at 
http://code.google.com/p/google-url/source/browse/trunk/src/url_util.cc  
(between lins 183 and 211 where the schemes are dispatched to the appropriate 
canonicalization and parsing).

It is set up by Cef in scheme_impl.cc 
http://code.google.com/p/chromiumembedded/source/browse/trunk/libcef/scheme_impl
.cc 

Original issue reported on code.google.com by JoeAndr...@gmail.com on 28 Feb 2011 at 7:16

[GoogleCodeExporter]

Confirmed behavior with v195.

Original comment by JoeAndr...@gmail.com on 2 Mar 2011 at 5:22

[GoogleCodeExporter]

Ok. Here's a patch, with comments added to cef.h.

Let me know if it works.

Original comment by JoeAndr...@gmail.com on 4 Mar 2011 at 12:44

Attachments:

• cef.customSchemeWithBool.patch

[GoogleCodeExporter]

Btw, I meant, let me know if you need any changes to the patch.  It does 
function properly. I tested a custom non-standard scheme against the a-d test 
cases above.

Original comment by JoeAndr...@gmail.com on 4 Mar 2011 at 6:02

[GoogleCodeExporter]

Support for non-standard schemes committed as revision 199.

I was unable to duplicate your null origin bypass results with either standard 
or non-standard schemes. This is what I did:

1. Change the CefRegisterScheme call in scheme_test.cpp.
2. Load tests/cefclient/res/xmlhttprequest.html via the file:// protocol.
3. Try to load the following URLs via XHR:
client://tests/handler.html
client:///tests/handler.html
client:tests/handler.html

All failed with the following console message:

Message: XMLHttpRequest cannot load client://tests/handler.html. Origin null is 
not allowed by Access-Control-Allow-Origin.

Original comment by magreenb...@gmail.com on 4 Mar 2011 at 5:57

• Changed state: Fixed

[GoogleCodeExporter]

Interesting.  It works on my set up.

How are you loading tests/cefclient/res/xmlhttprequest.html?

I am loading it as a file:// URL parameter in the call to Cef::CreateBrowser. 
That must be triggering a different security context.

Also, here's an test html file for custom schemes. It assumes both "custom" and 
"standard" are registered schemes in scheme_test.cpp.

Original comment by JoeAndr...@gmail.com on 4 Mar 2011 at 10:28

Attachments:

• custom_schemes.html

[GoogleCodeExporter]

Ok. That was a little early to say that it works. I should have said it makes 
it to my handler.  It does not make it back to the AJAX caller.

Diving into WebKit (and asking on webkit-dev), it looks like the right answer 
is to set the Access-Control-Allow-Origin header.  I tried setting it in the 
request header sent to ProcessRequest, but that didn't make it back with the 
response.

How might this be accomplished?

Original comment by JoeAndr...@gmail.com on 20 Mar 2011 at 12:48