An entertaining article about the dangers of untrusted JS dependencies. But it gets one crucial thing wrong: CSP is absolutely not capable of preventing data exfiltration once the attacker's script runs in the context of your app https://lists.w3.org/Archives/Public/public-webappsec/2016Sep/0012.html … http://www.cse.chalmers.se/~andrei/asiaccs16.pdf …https://twitter.com/D__Gilbertson/status/949563399272361984 …
window.outer should always just be window.inner plus some constant matching a common historic window decoration style. Actually giving the real value is a fingerprinting leak bug.
-
-
The other things in the SO answer are also bugs/leaks that should be fixed/plugged.
-
Sounds reasonable in principle, but in practice removing all the side channels is a huge amount of work for a browser vendor for a fairly unclear benefit (hiding the "is console open" bit for a tiny fraction of users). Not a hill I'd want to die on ;-)
-
It's just a matter of undoing mistakes & stopping adding new ones. They're not just console state leaks but tracking vectors (big privacy issue).
-
Removing all of them for devtools might be infeasible. Here's another one: with devtools opened, by default, JS pauses on errors. Check if that happens in an iframe. There's probably 100s of ways like that.
-
I once made a PoC of checking whether devtools are open by measuring the time of console.log (obviously takes longer with devtools opened). https://jsbin.com/tutotepovu/edit?html,output …
-
There are lots of ways to abuse console.log that should be plugged. Like execution of tostring should happen in sandbox with no visible side effects.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.