Persist prompt/block download limiter state on renderer-initiated loads.
The download request limiter will reset its state to allow a download
when it receives a notification of a pending navigation. This ensures
that the newly loaded page is always allowed to download one file. The
reset does not occur if the current state allows or blocks all downloads
AND the navigation is to the same host.
This means that a site can avoid prompting the user for multiple
downloads as follows:
1. trigger a download (moves state from ALLOW_ONE to PROMPT)
2. change window.location.href, creating a navigation and
resetting the limiter state to ALLOW_ONE
Sites can repeatedly loop and trigger downloads in a new pop-up window,
or use meta refresh tags to "ping-pong" between pages, downloading a
new file on each page. Because the limiter is in the PROMPT state when
the pending navigation arrives, the state is reset and the next download
is always permitted.
This CL closes the loophole by making the limiter maintain state
following a renderer-initiated navigation, unless the state is allowing
one or all downloads. This ensures that navigations which are not
triggered by the user cannot be used to reset the limiter to allowing
downloads if the state is either blocking downloads or prompting the
user to permit downloads. Both carpet bomb attacks described above
are mitigated in the CL.
A new IsRendererInitiated method is added to
content::NavigationHandle to enable this functionality. The limiter now
overrides WebContentsObserver::DidStartNavigation so it can access
the handle.
BUG=559515
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
Review-Url: https://codereview.chromium.org/1964863002
Cr-Commit-Position: refs/heads/master@{#394721}
12 files changed
