[webkit-dev] Allow "cross-origin" XHR requests for non-standard URLs?
Adam Barth
abarth at webkit.org
Sat Mar 19 06:53:58 PDT 2011
I should also say, please feel free to grab me on #webkit can we can
try to find a solution for you more interactively.
Adam
On Sat, Mar 19, 2011 at 6:53 AM, Adam Barth <abarth at webkit.org> wrote:
> On Fri, Mar 18, 2011 at 10:46 PM, Joe Andrieu <joe at andrieu.net> wrote:
>> I've been working with the Chromium Embedded Framework (in windows) which
>> gives webkit version 534.20. I am trying to get a custom scheme to work with
>> XHR.
>>
>> By way of background, I first updated the Cef code so that custom schemes
>> can be declared "non-standard", which avoids certain parsing errors.
>> Non-standard schemes include "data", "javascript", "file". Webkit has a
>> mechanism for registering standard schemes, so all I needed to do was /not/
>> register custom schemes that were non-standard.
>>
>> My custom scheme works fine at the beginning of the request. Chromium/Cef
>> successfully calls my scheme handler and my response data is read. But it
>> fails when the DocumentThreadableLoader::DocumentThreadableLoader
>> constructor starts checking for cross-origin security.
>>
>> I was able to get the code to "work" by bypassing the origin tests and
>> simply calling "loadRequest" in that constructor.
>>
>> As a fix, I'd like to propose that non-standard scheme URLs be accessible
>> from any security origin.
>
> I'm afraid this would be a security vulnerability. It would be very
> dangerous to default unusual schemes to be accessible from any
> security origin. :(
>
> I'm not entirely sure what you're trying to do, but it's likely to can
> return CORS headers from your custom URL handler that allow access
> from every security origin.
>
> Adam
>
>
>> A patch to SecurityOrigin::canRequest could set
>> DocumentThreadableLoader::m_sameOriginRequest to true if
>> url_util::DoIsStandard returns false. This would use Webkit's existing
>> whitelist mechanism for standard schemes. If necessary, exclusions could be
>> hardcoded if certain non-standard schemes are inappropriate for this policy.
>>
>> Since this could have significant security implications, I wanted to run it
>> by here first.
>>
>> I realize that my use case is stretching XMLHttpRequest well past http, but
>> this would allow using custom schemes with libraries that support AJAX
>> requests, such as JSTree.
>>
>> Curiously enough, I ran into the "rdar" scheme in the code, referencing
>> Apple's internal bug database. Given the current webkit security policy, it
>> would be impossible to access rdar URLs via Ajax. My proposed change would
>> allow it (assuming an appropriate scheme handler is available).
>>
>> FWIW, I'd be happy to figure out and provide a patch.
>>
>> -j
>>
>> --
>> Joe Andrieu
>> joe at andrieu.net
>> +1 (805) 705-8651
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
More information about the webkit-dev
mailing list