Google Adwords CSP (politique de sécurité du contenu) img-src

Quels domaines / protocoles dans la directive img-src de l'en-tête Content-Security-Policy sont requis pour permettre le suivi des conversions Google AdWords?

À partir du test, lorsque nous appelons google_trackConversion , il semble que le navigateur crée une image avec un src qui suit une chaîne de 302 redirections entre différents domaines …

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

Le .co.uk final me semble méfiant. Comme nous testons au Royaume-Uni, nous sommes préoccupés par le fait que le suivi des appels d'autres pays sera redirigé vers d'autres domaines.

Quelle est la liste complète des domaines que nous devons ouvrir pour que le suivi fonctionne?

Comme demandé dans les commentaires, un exemple de composant de chemin de la première demande est:

 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

Et répéter la conversion une deuxième fois, le composant de chemin de la première demande est

 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

J'ai utilisé un service VPN gratuit pour me connecter à partir de quelques pays (Pays-Bas et Singapour) et la dernière redirection ne se produit pas: la demande finale à www.google.com est un 200. Cependant, je n'ai évidemment pas essayé de connecter De tous les pays, donc ma question originale réside.

Malheureusement, il n'y a pas beaucoup de façons à ce sujet. Les ressources nécessitent soit une liste blanche (dans le cas de ressources distantes, comme celle-ci), soit des astuces d'alignement (c'est-à-dire nonce ou sha256-... ) lorsque CSP est actif. À la fin de la journée, cependant, CSP peut probablement encore rendre votre site plus sûr et protéger la plupart des ressources.

Selon ce que vous essayez de faire, vous pourriez toujours atteindre votre objectif.

Voici quelques options:

Liste blanche de toutes les images.

Bien sûr, vous pouvez simplement placer un "*" dans votre directive img-src , mais j'imagine que vous le savez déjà et que vous choisissez de ne pas le faire car il défaite la protection de CSP pour les images.
Chargez l'image par des moyens alternatifs.

Si tout ce que vous attendez est spécifiquement verrouiller les images et, par exemple, ne vous souciez tellement de XMLHttpRequest , vous pouvez charger le pixel via POST ou même via une <script> avec un type personnalisé (en utilisant le suivi de l' étiquette d'image AdWords méthode). Cela profite du fait que Google n'a besoin que du navigateur pour compléter le cycle de demande / réponse HTTP (et redirection) à des fins d'analyse, et vous ne vous souciez vraiment pas d'analyser ou d'exécuter le contenu résultant, qui est un pixel 1×1 de toute façon . Cela vous permet de verrouiller votre directive img-src (si c'est vraiment votre objectif) tout en permettant tout ce que Google souhaite utiliser pour les redirections.

Je sais que cela ne fait que remédier à votre problème, mais il est utile que votre principale menace soit une image malveillante.
Placez tous les domaines Google dans votre img-src .

Comme suggéré ci-dessous. Les longueurs d'en-tête seront un problème (même si les spécifications indiquent que vous êtes bien, les implémenteurs ne sont pas toujours aussi généreux) et, plus important encore, vous risquez de faire face à des fautes parasites alors que Google modifie sa liste de domaines, ce qui n'est certainement pas public ou facilement Des actions remarquables (en plus de vos conversions d'annonces ne se produisant pas!). Puisque j'imagine que votre travail n'est pas de mettre à jour cette liste en permanence, vous ne voulez probablement pas utiliser cette option.
Signaler des pannes pendant quelques mois puis rouler avec elle.

Étant donné que CSP prend en charge les rapports URI et la variante Content-Security-Policy-Report-Only , vous pouvez l'afficher en mode seul rapport et attendre l'arrivée des rapports. Si vous avez déjà de bonnes données sur votre base d'utilisateurs (et ce n'est pas le cas, T change beaucoup), cela peut être une bonne option – une fois que vous voyez ces rapports se stabiliser sur une liste de domaines, scellez-le dans un en-tête CSP régulier. En option, vous pouvez placer un URI de déclaration sur l'en-tête final pour détecter tout échec supplémentaire. L'inconvénient de cette stratégie, bien sûr, c'est que vous n'obtenez pas de protection en mode rapport uniquement, et lorsque vous passez à l'appliquer, les pannes provoquent des données de conversion perdues et vous jouez au rattraper le retard.
Pixel statique avec proxy inverse

D'accord. Eh bien, les options ci-dessus n'étant pas si bonnes (je l'avoue), il est temps de penser à l'extérieur de la boîte. Le problème ici est que les techniques d'optimisation HTTP appliquées par Google (domaines de déchiquetage / géo-épingles) sont en contradiction avec une bonne pratique de sécurité (c.-à-d. CSP). La cause principale de l'ambiguïté du domaine est l'emplacement géographique du client, alors pourquoi ne pas l'épeler vous-même?

En supposant que vous avez un contrôle avancé de votre propre serveur HTTP, vous pouvez utiliser l'approche statique du pixel pour suivre et repérer la demande vous-même, de la manière suivante:

 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

L'utilisation d'un pixel statique (comme l'approche n ° 2) et le fait que votre proxy, par exemple, aux États-Unis ou au Royaume-Uni devrait s'assurer que l'adresse IP source est géographiquement fixée là-bas, et l'interface Anycast de Google devrait vous acheminer vers un point d'extrémité stable. Le fait de placer un proxy entre l'utilisateur et Google vous donne également la chance de forcer à réécrire la redirection si vous le souhaitez.

Pour simplifier la configuration du proxy (et ajouter des spices de performance), vous pouvez opter pour quelque chose comme Fastly with Origin Shielding au lieu de le construire vous-même. Si vous ajoutez le backend et le proxy DoubleClick à partir de là, vous pouvez spécifier les requêtes d'origine du CDN pour venir uniquement d'une région géographique donnée. Quoi qu'il en soit, votre utilisateur devrait voir un ensemble stable de redirections, et vous pouvez réduire cette liste de domaines Google uniquement à img-src 'self' *.google.com *.doubleclick.net *.googleadservices.net .

Edit: Il est également intéressant de noter rapidement (et une liste croissante d'autres fournisseurs de CDN ) directement avec Google Cloud à quelques-uns de leurs points de présence, offrant un chemin optimisé dans les réseaux de Google pour votre trafic avancé.

Qu'est-ce que vous essayez d'obtenir en verrouillant votre img-src?

CSP est une excellente option de sécurité, mais la plupart des problèmes sont avec javascript (qui peut causer toutes sortes de problèmes), css (qui peut être utilisé pour masquer ou trop d'éléments avec du contenu injecté) ou des options d'encadrement (ce qui peut être utilisé pour faire un clic Contenu similaire sur le dessus). Les images sont un risque beaucoup plus faible IMHO.

Il y a peu de risques de sécurité que je peux penser avec le chargement des images, qui se résument à:

Le suivi et les implications de la vie privée de cela. Bien que vous utilisez déjà Google Adwords qui suit autant. Et ceux qui s'en soucient le bloquent généralement dans leur navigateur.
Chargement de contenu non sécurisé (je présume que vous utilisez exclusivement HTTPS ou que cette conversation est un peu inutile?). Cela peut être remédié à une politique CSP plus lâche de la seule https pour img-src.
Chargement d'une image et, par la suite, recouvre une partie de votre site Web avec cette image déloyale. Mais cela nécessite également une injection javascript et / ou CSS – qui devrait être verrouillée dans CSP.

En fin de compte, sauf si vous avez une vulnérabilité XSS, les personnes ne devraient pas pouvoir charger facilement des images dans vos pages. Et même s'ils pouvaient, je pense que les risques sont faibles.

Donc, je serais tenté d'avoir un "img-src" auto 'https :; " Plutôt que d'essayer l'un des autres travaux autour des autres ont suggéré – tous ceux qui ont des inconvénients et ne sont pas des preuves du futur.

En fin de compte, si vous êtes préoccupé par la sécurité de votre site, le verrouillage des images est une priorité élevée. Je voudrais savoir si vous devriez utiliser Google Adwords .

Toutefois, s'il existe une menace spécifique, vous essayez de vous protéger, tout en autorisant Adwords , puis à fournir des détails à ce sujet et il peut y avoir d'autres moyens. En ce moment, vous avez demandé une solution à un problème particulier sans expliquer nécessairement le problème sous-jacent qui peut avoir des solutions autres que celle que vous posez.

Vous pouvez utiliser la liste des domaines Google de Wikipedia. Il existe de nombreux domaines indépendants de Google Adwords, mais je ne pense pas que les domaines tels que youtube.com pourraient causer des problèmes.

Actuellement, la liste est:

 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

Toutefois, si vous voulez être sûr que ce soit vraiment tous les domaines, vous devriez demander à Google directement.