Issue metadata
Sign in to add a comment
|
Security: spoofing forward and back button
Reported by
danielsz...@gmail.com,
Jan 26 2018
|
||||||||||||||||||
Issue description
VULNERABILITY DETAILS
It is possible to manipulate the back and forward button. A user can be sent to unexpected and unpleasant pages.
The problem is chrome specific.
With the back and forward button the request accept content-type is ignored in the browser cache.
You can use the following php code to reproduce the problem.
1. call code via url (... backtofakeebay.php)
2. go back in the browser
3. go forward in the browser.
The same can be extended in different variants for forward and backward movement.
VERSION
Chrome Version: Version 64.0.3282.119 (Offizieller Build) (64-Bit)
Operating System: All
REPRODUCTION CASE
Here is a minimal example:
backtofakeebay.php:
<?php
$s = "";
foreach (getallheaders() as $name => $value) {
$s = $s."$name: $value<br>";
if (strpos($value, 'json') !== false){
header('Content-Type: application/json');
echo "<b>FAKESITE</b>";
return;
}
}
echo $s;
echo "<script>var xmlHttp = new XMLHttpRequest(); xmlHttp.open( 'GET', '/backtofakeebay.php', false ); xmlHttp.setRequestHeader('Accept', 'application/json'); xmlHttp.send( null ); </script>";
?>
,
Jan 26 2018
A live repro of this can be seen here: https://whytls.com/backtofakeebay.php I don't see any security problems here at all. This PHP file works by looking at the request headers, and if it sees the word JSON, it returns simple html markup ("<b>FAKESITE</b>") to the client. Otherwise, it echos the request headers. The user, upon first visit, is shown their request headers and in the background an XHR is sent for the same URL with a header containing the word JSON. The "FAKESITE" response is then stored in Chrome's cache. The user subsequently navigates somewhere else and navigates back. Chrome finds the XHR-retrieved version of the page in its cache and displays it ("FAKESITE") instead of what the user saw last time the page loaded (the headers). This behavior is standards-compliant under that applicable RFCs (the site did not send a "Vary: Accept" response header that would demand different behavior). At no point is there any spoof of the Omnibox or another security surface.
,
May 5 2018
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Jan 26 2018