Skip to content

Do not trust URI during WEBKIT_LOAD_STARTED

Michael Catanzaro requested to merge mcatanzaro/CVE-2019-6251-Regressions into master

Since WebKit r243434 [1][2], the web view's URI property might not be updated during WEBKIT_LOAD_STARTED. For example, when on the about:overview page, if we click on any overview thumbnail, the URI is still ephy-about:overview at this point. WebKit internally knows the URI is different, but it is hiding the change from us until WEBKIT_LOAD_COMMITTED because it doesn't know if web content is maliciously attempting to spoof the URI. The URI is now only expected to be accurate if the load was initiated by API request, e.g. webkit_web_view_load_uri(), and our code here doesn't know anything about how the load was initiated, so we'd better not check the URI here at all.

There were several regressions that I never noticed until today:

(1) We freeze the history here improperly, since we incorrectly think that we are loading about:overview. Then the page we load doesn't make it into history.

(2) For the same reason, we don't save a new snapshot of the page for the overview, resulting in stale snapshots persisting the next time the overview is opened.

(3) We set the loading message in the floating statusbar to indicate that we are loading the currently-viewed page, rather than the page that is actually being loaded. To fix this, we can just set the label to "Loading...", without displaying any URL at all, until WEBKIT_LOAD_COMMITTED is reached.

These bugs only occur when the load is initiated by web content, or by user interaction with web content. Loads triggered by API request should be fine.

Edited by Michael Catanzaro

Merge request reports