Did they fix the problem where target="_blank" gives that linked page complete access to the page?
Reshaping web defenses with strict Content Security Policy
11–20 of 25 posts
Re: Reshaping web defenses with strict Content Security Policy
#12Fantastic tool, though it seems to have a couple possible issues:
- Doesn't properly take into account default-src. We have default-src 'none', but it's telling us that we haven't set object-src to none.
- Says "Directive 'meta' is not a known CSP directive", despite the advice to use the meta tag here: http://www.html5rocks.com/en/tutorials/security/content-secu...
For reference these are the issues that came up with the CSP on the front end for our oembed:
https://oembed.fwdeveryone.com?threadId=Nh4apRjSR7qS5y4aGd3N...
Re: Reshaping web defenses with strict Content Security Policy
#13Earlier quoted context omitted.
I have been tempted to go down the bug bounty route, but in this particular instance I might get a small win, but not contribute to the larger problem of browsers and javascript themselves. Browsers are a teeming big ball of complexity and rather than patch and forget, I would rather stick to a single duty, stripped down program like Lynx, or a hardened version of Firefox with heavy about:config tweaks. And of course…
Yeah, I'm going to go out on a limb and suggest that you haven't really looked into your ideas for these attacks, and if you did you'd discover they weren't actually exploitable.
No, I stated I took out entire classes of attacks by using a single duty browser like Lynx and a hardened version of Firefox with JS disabled. Rather than patch and forget, I addressed the larger problem head on. The last thing a browser vendor wants to hear is a user complaining that JavaScript is enabled by default. There is a vested interest in having JavaScript all pervasive in browsers now, and huge lobby groups campaigning for a JavaScript only web, and this is very counter productive. Of course I can exploit Chrome and those exploits do work. My issue is that even if I report them, another one will popup because the design of Chrome (and Firefox) is fundamentally flawed from the very outset. Complexity is the enemy of security, and the onus is on the user to mitigate, not always on the vendors, or the bug reporting ecosystem, or even the bug bounty programs.
Re: Reshaping web defenses with strict Content Security Policy
#14This stuff is not my area of expertise but am I correct in assuming we're talking about a "checker checker"?
In which case, quis checks ipsos checkers? ie will we eventually find we need a checker checker checker, and so on ad infinitum?
Re: Reshaping web defenses with strict Content Security Policy
#15Did they fix the problem where target="_blank" gives that linked page complete access to the page?
yes, use rel=noopener. https://bugs.chromium.org/p/chromium/issues/detail?id=168988
Re: Reshaping web defenses with strict Content Security Policy
#16If browsers were serious about cross-site content issues, Google Ads wouldn't work. Google insists in their policies that their ads must not be placed in IFRAME blocks,[1] where they can't see the page context. Yet, for security, you want any outside content that executes code sandboxed in an IFRAME.
Re: Reshaping web defenses with strict Content Security Policy
#17And there are a dozen third-party scripts injected into this article.
Re: Reshaping web defenses with strict Content Security Policy
#18If browsers were serious about cross-site content issues, Google Ads wouldn't work. Google insists in their policies that their ads must not be placed in IFRAME blocks,[1] where they can't see the page context. Yet, for security, you want any outside content that executes code sandboxed in an IFRAME. [1] https://support.google.com/adsense/answer/3394713?hl=en
100% agree. If Google is serious about CSP, show me where they document the CSP that doesn't break AdSense or Analytics. It's a moving target, AFAICT, and the reason why I don't use CTP in production (at work).
Re: Reshaping web defenses with strict Content Security Policy
#19If browsers were serious about cross-site content issues, Google Ads wouldn't work. Google insists in their policies that their ads must not be placed in IFRAME blocks,[1] where they can't see the page context. Yet, for security, you want any outside content that executes code sandboxed in an IFRAME. [1] https://support.google.com/adsense/answer/3394713?hl=en
At some point you have to leverage 3rd parties in order to get your business to function. To me, letting an ad company run javascript on your page is something akin to letting hired contractors in the real world stroll through your office unwatched. Yes its' a security concern, but it's also necessary to operate a business.
In reality, we don't have a lot of truly secure facilities, but instead rely on legal process to stop bad actors, and make people whole after the fact.
On the web, there's always been a push for total security, which I don't think is useful nor particularly realistically implementable.
Re: Reshaping web defenses with strict Content Security Policy
#20Did they fix the problem where target="_blank" gives that linked page complete access to the page?
yes, use rel=noopener. https://bugs.chromium.org/p/chromium/issues/detail?id=168988
That's not a fix.. the default is that any link like that gives complete control over the page. Its a ridiculous default.