
Reshaping web defenses with strict Content Security Policy - syjer
https://security.googleblog.com/2016/09/reshaping-web-defenses-with-strict.html
======
Animats
If 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](https://support.google.com/adsense/answer/3394713?hl=en)

~~~
gavinpc
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).

~~~
arturjanc
Essentially, here: [https://csp-experiments.appspot.com/strict-
dynamic](https://csp-experiments.appspot.com/strict-dynamic)

The idea behind CSP based on nonces (as opposed to the "old" approach of using
whitelists) is that you add the valid nonce token only to the script directly
sourced from your page, and trust propagates to other scripts loaded
dynamically by the "loader" script. This way you no longer have to care about
what domains the widget uses -- if you trust the initial script, give it a
nonce and it will execute, along with the subresources it needs.

Of course you can still have a domain whitelist or use Subresource Integrity
if you're loading scripts from potentially untrusted infrastructure. But the
nonce-based approach is meant precisely to avoid the "moving target" problem
you mentioned.

~~~
Animats
That's a very Google idea, and it's a bad one. Malware distributed through
Google's ad system has been an ongoing problem.[1][2] Letting Google's
advertiser customers inherit Google's trust is a _terrible_ idea.

Google needs to put all their ads in IFRAME sandboxes. Tightening up on what
an IFRAME can do wouldn't be a bad idea, either. No popups, no self-starting
video, no absolute positioning outside the clipping pane, no expanding the
frame size...

[1] [http://www.theverge.com/2014/9/19/6537511/google-ad-
network-...](http://www.theverge.com/2014/9/19/6537511/google-ad-network-
exposed-millions-of-computers-to-malware) [2]
[http://www.businessinsider.com/android-malware-spreads-
using...](http://www.businessinsider.com/android-malware-spreads-using-google-
adsense-advertising-network-kaspersky-researchers-2016-8)

------
niftich
This tool they just released, is hopefully helpful, and will help site
administrators craft specific CSPs for specific parts of their site -- other,
more generic tools already exist.

On the HN thread on the cited study, I posted [1] that C-S-P is 'another damn
header' that has to be included to stay secure and, unlike many of the 'other
damn headers', its value is hopefully fine-tuned to the particular protected
resource, unlike a site-wide hardcoded string.

I think more so than another configuration helper tool, what the Web really
needs is a CSP rule engine evaluator that allows rules to be specified
declaratively ahead of time, and integrates with some existing web framework
to allow the resulting C-S-P value to be spliced into the outgoing response.
Portions of this approach are implicitly proposed by OWASP here [2], but I've
yet to see it written down formally, as opposed to just some code example.
Widely adopting this approach would result in a paradigm shift that lifts
C-S-P from 'just a header' to a first-class construct integral to the
operation of the web application.

[1]
[https://news.ycombinator.com/item?id=12408680](https://news.ycombinator.com/item?id=12408680)

[2]
[https://www.owasp.org/index.php/Content_Security_Policy#Coun...](https://www.owasp.org/index.php/Content_Security_Policy#Countermeasure)

------
Alex3917
Fantastic 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...](http://www.html5rocks.com/en/tutorials/security/content-security-
policy/)

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...](https://oembed.fwdeveryone.com?threadId=Nh4apRjSR7qS5y4aGd3NMA)

------
aegarbutt
They really missed an opportunity to have their URL be [https://evaluate-
csp.withgoogle.com](https://evaluate-csp.withgoogle.com)

Rolls off the tongue better than [https://csp-
evaluator.withgoogle.com](https://csp-evaluator.withgoogle.com).

~~~
lfx
Agree with you, thought majority of the people will not pronounce this url
ever.

------
phs318u
This 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?

------
intrasight
And there are a dozen third-party scripts injected into this article.

------
zerognowl
CSP is another baseline config that web application developers consistently
don't include for whatever reason. It could be plain ignorance, but I think it
goes deeper than that: I think CSP is too specific for the larger problem at
hand which is Javascript itself. If I want to perform XSS on a site, I will
find a way. There are still unpatched SVG vectors I can use in Chrome which
have gone un-noticed for the longest time, and they will, can, and are being
used today. There's just too many code paths in browsers to exploit, and CSP
only partially addresses the problem. I'm still seeing TrueType libraries from
the 90s executing arbitrary code in browsers, and it's 2016.

~~~
magicalist
> _There are still unpatched SVG vectors I can use in Chrome which have gone
> un-noticed for the longest time, and they will, can, and are being used
> today._

If you know of exploitable XSS vectors in SVG implementations, you should
report them. Not only would you get some nice big bug bounties, you'd, you
know, close XSS vulnerabilities for hundreds of millions of people.

~~~
zerognowl
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, Javascript turned off at all costs.
I routinely ask people on public forums to switch to Firefox and block
JavaScript, and I am a firm advocate of Lynx for surfing text-based websites.
I might not be able to view some websites, but that's on them. It's a
webmaster's job to make a website accessible, not mine.

~~~
magicalist
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.

~~~
zerognowl
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.

------
anaptdemise
Can't load on iPad with Focus filter...

------
ilaksh
Did they fix the problem where target="_blank" gives that linked page complete
access to the page?

~~~
notatoad
yes, use rel=noopener.
[https://bugs.chromium.org/p/chromium/issues/detail?id=168988](https://bugs.chromium.org/p/chromium/issues/detail?id=168988)

~~~
ilaksh
That's not a fix.. the default is that any link like that gives complete
control over the page. Its a ridiculous default.

