Bug 51674 – [Qt] LocalContentCanAccessRemoteUrls creates cross frame scripting vulnerability

• Status: RESOLVED
• Resolution: INVALID
• Component: New Bugs

[Pushparajan V]

Created attachment 77550 [details]
test case for cross frame access

In QtTestBrowser, enable the below setting,

QWebSettings::globalSettings()->setAttribute(QWebSettings::LocalContentCanAccessRemoteUrls, true);

Without enabling this attribute, qttestbrowser never allows any cross domain features (i.e, XHR from local scheme)

But after enabling this settings, qttestbrowser also allows cross domain javascript access across iframe. i.e, Parent can call the child iframe's Javascript. But the reverse (child calling the parent JS API) is not allowed somehow. 


As per the documentation, LocalContentCanAccessRemoteUrls should only enable XHR for remote URL. 

I read a comment in BindingSecurityBase.cpp like,
// Same origin policy prevents JS code from domain A from accessing JS & DOM
// objects in a different domain B. There are exceptions and several objects
// are accessible by cross-domain code. For example, the window.frames object
// is accessible by code from a different domain, but window.document is not.

But still doubtful whether such an access should be allowed (even when LocalContentCanAccessRemoteUrls is enabled) as iframe URL is never a trusted URL. 

Attached a test case which modifies content in an iframe. iframe is loaded from a different URL.

In normal qttestbrowser, this is not reproducable. Please enable LocalContentCanAccessRemoteUrls to verify this bug.

[Alexey Proskuryakov]

> As per the documentation, LocalContentCanAccessRemoteUrls should only enable XHR for remote URL. 

Maybe a documentation mistake?

[Pushparajan V]

(In reply to comment #1)
> > As per the documentation, LocalContentCanAccessRemoteUrls should only enable XHR for remote URL. 
> 
> Maybe a documentation mistake?

Not sure.  May be its a documentation problem. But LocalContentCanAccessRemoteUrls blindly grants universalAccess for the page where its enabled which in turn allows parent to child javascript calls to execute. 

Previously, XHR was allowed using, SecurityOrigin::addOriginAccessWhitelistEntry API. The XHR security check is done only for the requests using SecurityOrigin::canRequest API inside webkit.

But now, with LocalContentCanAccessRemoteUrls, the SecurityOrigin::canAccess API is used which always returns true in the context of the page where its enabled.

Is this an expected behavior from LocalContentCanAccessRemoteURLs?

[Adam Barth]

> Not sure.  May be its a documentation problem. But LocalContentCanAccessRemoteUrls blindly grants universalAccess for the page where its enabled which in turn allows parent to child javascript calls to execute. 

That's correct.

> Previously, XHR was allowed using, SecurityOrigin::addOriginAccessWhitelistEntry API. The XHR security check is done only for the requests using SecurityOrigin::canRequest API inside webkit.

I think that's a question of how far back in history you go.  Certainly local URLs had universal access in WebKit before the addOriginAccessWhitelistEntry API existed.

> But now, with LocalContentCanAccessRemoteUrls, the SecurityOrigin::canAccess API is used which always returns true in the context of the page where its enabled.

Correct.

> Is this an expected behavior from LocalContentCanAccessRemoteURLs?

It is.  Note that this setting is pretty insecure because once local content starts interacting with remote URLs, it's very likely to leak its privileges to those URLs.  We can add another setting for LocalContentCanRequestRemoteURLs to enable XHR access only, if you like, which is a bit safer but also problematic on systems, such as laptops, that let users store remote content in the local filesystem.

[Pushparajan V]

(In reply to comment #3)

> I think that's a question of how far back in history you go.  Certainly local URLs had universal access in WebKit before the addOriginAccessWhitelistEntry API existed.

I can think of DumpRenderTree Qt implementation for this. Previously it used, qt_drt_whiteListAccessFromOrigin for XHR to be whitelisted for local content. Now, it uses LocalContentCanAccessRemoteURLs. But for tools like this, this option should be fine.

> It is.  Note that this setting is pretty insecure because once local content starts interacting with remote URLs, it's very likely to leak its privileges to those URLs.  We can add another setting for LocalContentCanRequestRemoteURLs to enable XHR access only, if you like, which is a bit safer but also problematic on systems, such as laptops, that let users store remote content in the local filesystem.

Its better if we have QWebSetting named LocalContentCanRequestRemoteURLs. It is also possible now to use qt_drt_whiteListAccessFromOrigin API to whitelist the URLs suitable for remote request. But if there is a Setting for this, then this can be widely used for any local content which just need to request remote URLs. This option can also stress on the property that no privileges are leaked to any external URLs.

[Benjamin Poulain]

I agree with Adam, this is the intended behavior for this property.

It is very useful to do Hybrid development, in which you really want to break the security based on origin.

I agree with Alexey, the doc should be updated.

Pushparajan, could you update the doc?

[Pushparajan V]

(In reply to comment #5)
> I agree with Adam, this is the intended behavior for this property.
> 
> It is very useful to do Hybrid development, in which you really want to break the security based on origin.
> 
> I agree with Alexey, the doc should be updated.
> 
> Pushparajan, could you update the doc?

Its not just a documentation issue. If you read my comment, the property gives universalAccess to the securityOrigin on which its set. It creates security problems when used in applications which needs only XHR. 

Rather than updating the documents, I feel its better to add a new setting named LocalContentCanRequestRemoteURLs to avoid confusion. I have cooked up a patch for it. But it touches critical code in webkit. So, we need to discuss about the necessity of this setting in detail.

Whitelisting is a better option which can be used instead of such a setting. But it creates unnecessary security origins for each every origin and destination URLs. So, such a setting for the page will be really helpful and less confusing.

[Benjamin Poulain]

(In reply to comment #6)
> Its not just a documentation issue. If you read my comment, the property gives universalAccess to the securityOrigin on which its set. It creates security problems when used in applications which needs only XHR. 
> [...]

I understand that, but it is an other problem altogether. You should create another bug report for that.

This bug is about "LocalContentCanAccessRemoteUrls", which as you said has documentation problem. The patch for this particular bug is updating the doc. What you need is a new use case that you should detail separately.

[Jocelyn Turcotte]

=== Bulk closing of Qt bugs ===

If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary.

If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.