[deleted]
Target=”_blank” is an underestimated vulnerability
51–56 of 56 posts
Re: Target=”_blank” is an underestimated vulnerability
#52Earlier quoted context omitted.
For anyone who wants to see this defeated: - Disable JavaScript. Seriously, seeing all these interesting behaviours just makes me advocate even more strongly browsing the "open Web" with JS off by default. The power of JavaScript is not to be underestimated, and while it makes for some very good things that would be otherwise impossible, I think users should be more aware of and understand the risks that allowing any…
The web now requires JS to function. I think it's time to take off the tin foil hat and accept it.
Unfortunately, two things can be true at the same time: JavaScript increases security risk, and JavaScript is necessary for a lot of the web.
Re: Target=”_blank” is an underestimated vulnerability
#53Earlier quoted context omitted.
To be fair, not all of those chat interfaces were fake. Some are just scripts that connect to real people quickly once you interact favorably. Then they try to sell you on $50 of cam show credits.
Wait, how do you know that? :P "Market research" eh?
I wrote that software for several networks of sites.
Re: Target=”_blank” is an underestimated vulnerability
#54Earlier quoted context omitted.
Of course it's whack a mole. Moat things in infosec are, that doesn't mean browsers shouldn't ship with secure defaults or present trustworthy info in the address bar. Agreed CSP would be a good place to fix.
This game off whack-a-mole feels different. Unlike the typical "memory corruption of the week", this kind of stuff isn't fixed by a simple browser update and inherited "for free" by all sites. And, this kind of fix doesn't enable a browser to ship with a secure default. Instead, it adds a new thing you have to opt into and retroactively add to all existing links on your site. That is a fair bit of work, and adding mo…
> this kind of stuff isn't fixed by a simple browser update and inherited "for free" by all sites
Why not? What's stopping browser from disabling window.opener unless CSP specifically allows it?
(totally appreciate there may be something I'm missing here, and thanks for responding)
Re: Target=”_blank” is an underestimated vulnerability
#55Earlier quoted context omitted.
This game off whack-a-mole feels different. Unlike the typical "memory corruption of the week", this kind of stuff isn't fixed by a simple browser update and inherited "for free" by all sites. And, this kind of fix doesn't enable a browser to ship with a secure default. Instead, it adds a new thing you have to opt into and retroactively add to all existing links on your site. That is a fair bit of work, and adding mo…
> this kind of stuff isn't fixed by a simple browser update and inherited "for free" by all sites Why not? What's stopping browser from disabling window.opener unless CSP specifically allows it? (totally appreciate there may be something I'm missing here, and thanks for responding)
Unless we are talking about something terribly dire (arbitrary code execution) browser vendors are super unlikely to change behavior that has existed, and potentially relied upon, for many years. The bar for changing existing behavior is extremely high and this kind of attack won't come anywhere near meeting it. So, the only realistic solution is something that a site opts into (or out of depending on your perspective). CSP would at least let the site that is a potential victim protect itself. And, if there was a good reason to let a partner site have window ref (I could imagine something related to payment providers and modal pop up payment flows), they could opt in to that. It would look something like.
window-ref 'self' PayPal.com
Something like that would let the site reference their own windows as well as grant access to a "trusted partner" like PayPal.
Re: Target=”_blank” is an underestimated vulnerability
#56Earlier quoted context omitted.
> this kind of stuff isn't fixed by a simple browser update and inherited "for free" by all sites Why not? What's stopping browser from disabling window.opener unless CSP specifically allows it? (totally appreciate there may be something I'm missing here, and thanks for responding)
Unless we are talking about something terribly dire (arbitrary code execution) browser vendors are super unlikely to change behavior that has existed, and potentially relied upon, for many years. The bar for changing existing behavior is extremely high and this kind of attack won't come anywhere near meeting it. So, the only realistic solution is something that a site opts into (or out of depending on your perspectiv…
Browser vendors do 'phase out' old behavior and phase in new ones. I understand "don't break the web", but as someone else famously replied, "the web is a self healing mechanism". Look at what browsers have done re: forms submitted over HTTP.
A maintained site that relies on window.opener should, after a 24 month period of angry console warnings saying a change needs to be made, actually make that change.