Google Adwords的CSP（内容安全策略）img-src

Question

Google Adwords的CSP（内容安全策略）img-src

javascripthttpgoogle-ads-apicontent-security-policy

45

在内容安全策略头文件的 img-src 指令中，哪些域名/协议是必须允许 Google AdWords 转化跟踪的？

经测试，当我们调用 google_trackConversion 时，浏览器似乎会创建一个图片，其源地址遵循各种域之间的 302 重定向链...

www.googleadservices.com ->
googleads.g.doubleclick.net ->
www.google.com ->
www.google.co.uk

最后的.co.uk对我来说看起来有点可疑。由于我们正在从英国进行测试，我们担心从其他国家调用的跟踪将重定向到其他域。

为使跟踪工作，我们需要打开哪些完整的域名列表？

根据评论中的请求，第一个请求的示例路径组件如下：

pagead/conversion/979383382/?random=1452934690748&cv=8&fst=1452934690748&num=1&fmt=3&label=jvoMCNP4umIQ1uiA0wM&guid=ON&u_h=1080&u_w=1920&u_ah=1033&u_aw=1920&u_cd=24&u_his=18&u_tz=0&u_java=false&u_nplug=5&u_nmime=7&frm=0&url=https%3A//beta.captevate.com/payment%3Flevel%3Da00&async=1

并且再次进行转换后，第一个请求的路径组件为

pagead/conversion/979383382/?random=1452934959209&cv=8&fst=1452934959209&num=1&fmt=3&label=jvoMCNP4umIQ1uiA0wM&guid=ON&u_h=1080&u_w=1920&u_ah=1033&u_aw=1920&u_cd=24&u_his=26&u_tz=0&u_java=false&u_nplug=5&u_nmime=7&frm=0&url=https%3A//beta.captevate.com/payment%3Flevel%3Da00&async=1

我使用了一个免费的VPN服务连接了几个国家（荷兰和新加坡），并且最后的重定向没有发生：对www.google.com的最终请求是200。然而，显然我没有尝试从每个国家连接，因此我的原始问题仍然存在。

- Michal Charemza

1

你介意发一下原始跟踪图像的路径组件吗？或者谷歌会以不可预测的方式更改它，可能连同域名一起更改？ - Sam Gammon

你尝试过使用某种VPN或代理获取外国IP并检查你的怀疑吗？也许你仍然会被重定向到.co.uk域名。 - Phonolog

@sgammon 我已经添加了原始请求的路径组件。 - Michal Charemza

@Phonolog 是的，并且在问题中添加了细节。 - Michal Charemza

大家好，感谢回复，但我仍然找不到解决这个问题的好方法。另外，我们需要允许www和其他域名。这是否意味着我们必须将所有谷歌域名都输入两次： google.be和*.google.be，还是有更短的版本可以避免安全风险？是否存在某些浏览器不允许那么长的标头的风险，或者只有Web服务器会限制长度？谢谢！ - nico008

4个回答

14

你通过锁定img-src想要实现什么目的？

CSP是一个很好的安全选项，但大多数问题都与JavaScript（可能会导致各种问题）、CSS（可用于使用注入内容隐藏或过度元素）或框架选项（可用于类似地叠加内容的点击劫持）有关。在我看来，图像风险要小得多。

我能想到的与加载图像相关的几个安全风险包括：

1. 跟踪和隐私问题。即使您已经使用跟踪很多的Google Adwords，关心隐私问题的人通常也会在其浏览器中阻止它。 2. 加载不安全的内容。这可以通过更松散的CSP策略（仅针对img-src的https）来解决。 3. 加载图像，并随后将您网站的一部分与该恶意图像重叠。但这也需要javascript和/或CSS注入，这应该在CSP中进行锁定。

总之，除非您有XSS漏洞，否则人们不应该轻易地将图像加载到您的页面中。即使他们可以，我认为风险很小。

因此，我倾向于只使用“img-src'self' https:;”，而不尝试任何其他解决方法——所有这些解决方法都有缺点，并且不够未来化。

如果您非常关注您的网站的安全，以至于锁定图像成为首要任务，那么我会质疑您是否应该运行Google Adwords。

但是，如果您正在尝试保护特定威胁，同时仍允许Adwords，则提供有关其的详细信息，可能还有其他解决方法。目前，您已经要求解决一个特定问题的解决方案，而并未必要解释实际的潜在问题，这些问题可能具有与您所询问的解决方案不同的解决方法。

- Barry Pollard

3

我只想提一下，这个答案忽略了安全风险。使用开放的image-src，攻击者可以提取诸如密码、API密钥、信用卡信息等等的东西。那么这怎么成为一个问题呢？除了XSS漏洞，答案提到如果你使用的依赖关系变得恶意也可能发生这种情况。 - Mikael Eliasson

为了澄清@MikaelEliasson的评论，如果有人想知道如何通过加载图像来帮助攻击者实现这一点：这与加载图像的能力无关，而是与恶意代码能否向任意域发出网络请求有关。如果您在用户的浏览器中运行的代码捕获了他们的密码，您仍然需要将这些数据从他们的计算机上取出才能使用。如果内容安全策略允许在img-src中使用'*'，那么攻击者可以尝试加载一个带有以下URL的图像："attackers-domain/users-password-here.png"，并让该域上的服务器保存这些请求。 - undefined

10

你可以使用维基百科的Google域名列表。其中有很多与Google Adwords无关的域名，但是我认为允许像youtube.com这样的域名不会引起问题。

目前该列表包括：

google.com
google.ac
google.ad
google.ae
google.com.af
google.com.ag
google.com.ai
google.al
google.am
google.co.ao
google.com.ar
google.as
google.at
google.com.au
google.az
google.ba
google.com.bd
google.be
google.bf
google.bg
google.com.bh
google.bi
google.bj
google.com.bn
google.com.bo
google.com.br
google.bs
google.bt
google.co.bw
google.by
google.com.bz
google.ca
google.com.kh
google.cc
google.cd
google.cf
google.cat
google.cg
google.ch
google.ci
google.co.ck
google.cl
google.cm
google.cn
g.cn
google.com.co
google.co.cr
google.com.cu
google.cv
google.com.cy
google.cz
google.de
google.dj
google.dk
google.dm
google.com.do
google.dz
google.com.ec
google.ee
google.com.eg
google.es
google.com.et
google.fi
google.com.fj
google.fm
google.fr
google.ga
google.ge
google.gf
google.gg
google.com.gh
google.com.gi
google.gl
google.gm
google.gp
google.gr
google.com.gt
google.gy
google.com.hk
google.hn
google.hr
google.ht
google.hu
google.co.id
google.iq
google.ie
google.co.il
google.im
google.co.in
google.io
google.is
google.it
google.je
google.com.jm
google.jo
google.co.jp
google.co.ke
google.ki
google.kg
google.co.kr
google.com.kw
google.kz
google.la
google.com.lb
google.com.lc
google.li
google.lk
google.co.ls
google.lt
google.lu
google.lv
google.com.ly
google.co.ma
google.md
google.me
google.mg
google.mk
google.ml
google.com.mm
google.mn
google.ms
google.com.mt
google.mu
google.mv
google.mw
google.com.mx
google.com.my
google.co.mz
google.com.na
google.ne
google.com.nf
google.com.ng
google.com.ni
google.nl
google.no
google.com.np
google.nr
google.nu
google.co.nz
google.com.om
google.com.pk
google.com.pa
google.com.pe
google.com.ph
google.pl
google.com.pg
google.pn
google.co.pn
google.com.pr
google.ps
google.pt
google.com.py
google.com.qa
google.ro
google.rs
google.ru
google.rw
google.com.sa
google.com.sb
google.sc
google.se
google.com.sg
google.sh
google.si
google.sk
google.com.sl
google.sn
google.sm
google.so
google.st
google.sr
google.com.sv
google.td
google.tg
google.co.th
google.com.tj
google.tk
google.tl
google.tm
google.to
google.tn
google.com.tr
google.tt
google.com.tw
google.co.tz
google.com.ua
google.co.ug
google.co.uk
google.com
google.com.uy
google.co.uz
google.com.vc
google.co.ve
google.vg
google.co.vi
google.com.vn
google.vu
google.ws
google.co.za
google.co.zm
google.co.zw
admob.com
adsense.com
adwords.com
android.com
blogger.com
blogspot.com
chromium.org
chrome.com
chromebook.com
cobrasearch.com
googlemember.com
googlemembers.com
com.google
feedburner.com
doubleclick.com
igoogle.com
foofle.com
froogle.com
googleanalytics.com
google-analytics.com
googlecode.com
googlesource.com
googledrive.com
googlearth.com
googleearth.com
googlemaps.com
googlepagecreator.com
googlescholar.com
gmail.com
googlemail.com
keyhole.com
madewithcode.com
panoramio.com
picasa.com
sketchup.com
urchin.com
waze.com
youtube.com
youtu.be
yt.be
ytimg.com
youtubeeducation.com
youtube-nocookie.com
like.com
google.org
google.net
466453.com
gooogle.com
gogle.com
ggoogle.com
gogole.com
goolge.com
googel.com
duck.com
googlee.com
googil.com
googlr.com
googl.com
gmodules.com
googleadservices.com
googleapps.com
googleapis.com
goo.gl
googlebot.com
googlecommerce.com
googlesyndication.com
g.co
whatbrowser.org
localhost.com
withgoogle.com
ggpht.com
youtubegaming.com

然而，如果您想确定是否真的所有域名都已被阻止，您应该直接向谷歌询问。

- Michał Perłakowski

这样做会超过 CSP 标头长度的限制吗？ - Michal Charemza

1

@MichalCharemza HTTP头的长度没有限制，参见：https://dev59.com/ZnRB5IYBdhLWcg3wN1AQ - Michał Perłakowski

它并不涵盖像gstatic.com这样的大量域名。 - Muhammad Umer

Google在https://www.google.com/supported_domains上有一个页面，可能对于及时了解这个信息很有用。 - undefined

1

很遗憾，没有干净的解决方法，它只接受域名左侧的通配符*。

您可以在GTM或Universal Analytics上禁用此功能，但如果您使用Google Adds，则需要此功能来计算定位广告的细分，否则您的广告将非常昂贵（且不具有针对性）。

因此：您可以在此处检查所有有效的Google域 https://www.google.com/supported_domains，并将它们添加到CSP策略中的img-src和connect-src的白名单中，祈祷Google不会再添加更多（您可以使用任何提供此服务的服务监视此URL以进行更改）。

这场噩梦将于2023年中期结束，届时他们将停用Universal Analytics，GA4不使用此功能。

不确定您是否正在使用任何报告CSP故障的工具，我们发现了这个服务https://report-uri.com/，免费版提供了一个合理的端点来报告故障，一旦我们上线后，我们在两天内就用完了我们的配额，但它确实有助于找到我们CSP中的漏洞。

它确实导致了服务器崩溃，我们不得不增加HTTP头大小，一旦我们将所有谷歌域名都放入其中。

- Ignacio Gil

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Sam Gammon · Accepted Answer

抱歉，这方面没有太多的解决方法。资源需要白名单（对于远程资源，比如这个）或内联技巧（即当CSP激活时，nonce或sha256-...）。然而，归根结底，CSP可能仍然能够使您的站点更安全，并保护大多数资源。

不过，根据您所尝试的内容，您可能仍然可以实现您的目标。

以下是一些选项：

将所有图片列入白名单。

当然，您可以简单地在img-src指令中放置一个"*"，但我想您已经知道这一点，并选择不这样做，因为它会破坏CSP对图像的保护。
通过其他方式加载图片。

如果您只是想严格限制图片的使用，而不太关心XMLHttpRequest等其他内容，您可以通过POST或甚至通过带有自定义type的<script>标签（使用AdWords image tag跟踪方法）加载像素。这利用了Google仅需浏览器完成HTTP请求/响应（和重定向）周期以进行分析的事实，并且您并不真正关心解析或执行结果内容，它只是一个1x1透明像素。这允许您锁定您的img-src指令（如果这确实是您的目标），同时仍允许Google想要用于重定向的任何域名。

我知道这只是转移了您的问题，但如果您主要受到恶意图像的威胁，则非常有用。
将所有Google域名放置在您的img-src中。

如下所示建议。标头长度会是一个问题（即使规范说您没问题，实施者并不总是那么慷慨），更重要的是，您可能会遇到错误失败，因为Google会更改他们的域名列表，这绝对不是公开或易于注意的操作（除了您的广告转化量不会来！）。由于我想您的工作不是不断更新该列表，因此您可能不想选择此选项。
报告几个月的故障，然后再进行处理。

因为CSP支持报告URI和Content-Security-Policy-Report-Only变体，您可以在报告仅模式下推出它，并等待报告的到来。如果您已经有关于您用户群的好数据（并且它没有太多变化），那么这可能是一个不错的选择 - 一旦您看到这些报告在一组域上稳定下来，就封闭在常规CSP标头中。可选地，您可以在最终标头上放置报告URI以捕获任何其他故障。当然，此策略的缺点是，在报告仅模式下您无法获得保护，而当您切换到执行模式时，故障会导致丢失的转化数据，并且您需要追赶。
使用反向代理的静态像素

好吧。既然上述选项不太好（我承认），那么就该跳出传统思路了。问题在于Google应用的HTTP优化技术（分片/地理位置定位域）与良好的安全实践（即CSP）不符。域名模糊的根本原因是客户端所在的地理位置，那么为什么不自己定位呢？

假设您已经对自己的HTTP服务器有高级控制，您可以使用静态像素方法来进行跟踪并自己代理请求，如下所示：

User ---> GET http://your-page/

User <--- <html>...
          pixel: http://your-page/pixel?some=params

User ---> http://your-page/pixel?some=params
          ---> fetch http://googleads.g.doubleclick.net/pagead/viewthroughconversion/12345/?some=params
          <--- redirect to http://google.com, or http://google.co.uk
User <--- return redirect

使用类似于第二种方法的静态像素，并将代理放置在美国或英国，可以确保源IP地理位置被固定在那里，并且谷歌的任何播出前端应该会将您路由到一个稳定的终点。在用户和谷歌之间放置代理还可以让您有机会强制重写重定向（如果您想这样做）。

为了简化代理设置（并增加一些性能调味料），您可以选择像Fastly这样的东西，而不是自己构建它，并使用Origin Shielding。如果您从那里添加DoubleClick后端并进行代理，则可以将CDN的起始请求固定为仅来自某个地理区域。无论哪种方式，您的用户都应该看到一组稳定的重定向，并且您可以将Google域名列表缩减为img-src 'self' *.google.com *.doubleclick.net *.googleadservices.net。 < p >< em >编辑：值得注意的是，Fastly（以及越来越多的其他CDN提供商）在他们的一些出现点直接与Google Cloud 对等连接，为您代理的流量提供了通向Google网络的优化路径。