javascript - violates - Google Adwords CSP(política de seguridad de contenido) img-src
default-src https: data: ''unsafe-inline'' ''unsafe-eval'' (3)
¿Qué estás tratando de lograr cerrando tu img-src?
CSP es una excelente opción de seguridad, pero la mayoría de los problemas son con javascript (que puede causar todo tipo de problemas), css (que se puede usar para ocultar o sobredimensionar elementos con contenido inyectado) u opciones de encuadre (que se pueden usar para el clicking). contenido superpuesto similar). Imágenes son un riesgo mucho menor en mi humilde opinión.
Hay pocos riesgos de seguridad que se me ocurren al cargar imágenes, que se reducen a:
El seguimiento y las implicaciones de privacidad de eso. Aunque ya está utilizando Google Adwords que rastrea tanto. Y aquellos que se preocupan por esto normalmente lo bloquean en su navegador.
Carga de contenido inseguro (¿Supongo que está utilizando HTTPS exclusivamente o toda esta conversación es un poco inútil?). Esto se puede remediar con una política de CSP más holgada de solo https para img-src.
Cargar una imagen y, posteriormente, cubrir parte de su sitio web con esa imagen deshonesta. Pero eso también requiere javascript y / o inyección de CSS, que debería estar bloqueado en CSP.
En última instancia, a menos que tenga una vulnerabilidad XSS, las personas no deberían poder cargar fácilmente imágenes en sus páginas. E incluso si pudieran, creo que los riesgos son pequeños.
Por lo tanto, estaría tentado de tener solo un "img-src ''self'' https :;" en lugar de probar cualquiera de las otras alternativas de trabajo que otros han sugerido, todas las cuales tienen desventajas y no son una prueba de futuro.
En última instancia, si le preocupa la seguridad de su sitio, el bloqueo de imágenes es una prioridad alta. Me preguntaría si debería ejecutar Google Adwords .
Sin embargo, si hay una amenaza específica contra la que intenta protegerse, al mismo tiempo que todavía permite Adwords , proporcione detalles de eso y puede haber otras formas de evitarlo. En este momento, ha solicitado una solución a un problema en particular sin necesariamente explicar el problema subyacente real que puede tener soluciones distintas a la que usted está preguntando.
¿Qué dominios / protocolos en la directiva img-src del encabezado Content-Security-Policy son necesarios para permitir el seguimiento de conversiones de Google AdWords?
Desde las pruebas, cuando llamamos a google_trackConversion , parece que el navegador crea una imagen con un src que sigue una cadena de 302 redirecciones entre varios dominios ...
www.googleadservices.com ->
googleads.g.doubleclick.net ->
www.google.com ->
www.google.co.uk
El último .co.uk parece sospechoso. Como estamos realizando pruebas desde el Reino Unido, nos preocupa que el seguimiento de llamadas de otros países se redirija a otros dominios.
¿Cuál es la lista completa de dominios que necesitamos abrir para que el seguimiento funcione?
Como se solicita en los comentarios, un componente de ruta de ejemplo de la primera solicitud es:
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
y repitiendo la conversión por segunda vez, el componente de ruta de la primera solicitud es
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
Utilicé un servicio VPN gratuito para conectarme desde un par de países (Países Bajos y Singapur), y no se produce el último redireccionamiento: la solicitud final a www.google.com es 200. Sin embargo, obviamente no he intentado conectarme de todos los países, por lo que mi pregunta original se mantiene.
Desafortunadamente, no hay muchas maneras de evitar esto. Los recursos requieren listas blancas (en el caso de recursos remotos, como este) o trucos sha256-... (es decir, nonce o sha256-... ) cuando CSP está activo. Sin embargo, al final del día, es probable que el CSP aún pueda hacer que su sitio sea más seguro y proteger la mayoría de los recursos.
Sin embargo, dependiendo de lo que esté tratando de hacer, es posible que aún pueda lograr su objetivo.
Aquí hay algunas opciones:
Lista blanca de todas las imágenes.
Por supuesto, simplemente puede colocar un
"*"en su directivaimg-src, pero me imagino que ya lo sabe y está optando por no hacerlo porque anula la protección de imágenes de CSP.Cargar la imagen a través de medios alternativos.
Si todo lo que está buscando es específicamente bloquear imágenes y, por ejemplo, no le importa mucho
XMLHttpRequest, puede cargar el píxel mediantePOSTo incluso a través de una etiqueta<script>con untypepersonalizado (utilizando el seguimiento de etiquetas de imagen de AdWords método). Esto aprovecha el hecho de que Google solo necesita que el navegador complete el ciclo de solicitud / respuesta (y redirección) de HTTP para fines analíticos, y no le importa realmente analizar o ejecutar el contenido resultante, que es un píxel transparente de 1x1 de todos modos . Esto le permite bloquear su directivaimg-src(si ese es su objetivo) al mismo tiempo que permite cualquier dominio que Google quiera usar para las redirecciones.Sé que esto solo mueve su problema, pero es útil si su principal amenaza son las imágenes maliciosas.
Coloque todos los dominios de Google en su
img-src.Como se sugiere a continuación. La longitud del encabezado será un problema (incluso si las especificaciones dicen que está bien, los implementadores no siempre son tan generosos) y, lo que es más importante, puede encontrar fallas falsas a medida que Google cambie su lista de dominios, lo que ciertamente no es público o fácil. acción notable (además de las conversiones de anuncios que no llegan). Como me imagino que su trabajo no es actualizar esa lista constantemente, probablemente no quiera optar por esta opción.
Reporte las fallas por algunos meses y luego continúe con esto.
Debido a que CSP es compatible con los URI de informes y la variante de
Content-Security-Policy-Report-Only, puede implementarlo en modo de solo informe y esperar a que lleguen los informes. Si ya tiene buenos datos sobre su base de usuarios (y no los tiene) (Cambie mucho), esta puede ser una buena opción: una vez que vea que esos informes se estabilicen en una lista de dominios, ciérrelos en un encabezado CSP normal. Opcionalmente, puede colocar un URI de informes en el encabezado final para detectar cualquier falla adicional. La desventaja de esta estrategia, por supuesto, es que no obtiene protección mientras está en modo de solo informe, y cuando cambia a su cumplimiento, las fallas causan la pérdida de los datos de conversión y se están recuperando.Pixel estático con proxy inverso
Bueno. Bueno, como las opciones anteriores no son tan buenas (lo admito), es hora de pensar fuera de la caja. El problema aquí es que las técnicas de optimización de HTTP aplicadas por Google (dominios de fragmentación / geo-pinning) están en desacuerdo con las buenas prácticas de seguridad (es decir, CSP). La causa raíz de la ambigüedad del dominio es la ubicación geográfica del cliente, ¿por qué no lo determina usted mismo?
Suponiendo que tenga control avanzado de su propio servidor HTTP, podría utilizar el enfoque de píxeles estáticos para el seguimiento y la solicitud de proxy, así:
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
El uso de un píxel estático (como el enfoque nº 2) y la colocación de su proxy, por ejemplo, en los EE. UU. O el Reino Unido deben garantizar que la IP de origen esté localizada geográficamente allí, y la interfaz de usuario de cualquier emisión de Google debe dirigirlo a un punto final estable. Colocar un proxy entre el usuario y Google también le da la oportunidad de volver a escribir la redirección si lo desea.
Para simplificar la configuración del proxy (y agregar algo de rendimiento), puede optar por algo como Fastly con Origin Shielding en lugar de construirlo usted mismo. Si agrega el backend y el proxy de DoubleClick desde allí, puede anclar las solicitudes de origen desde el CDN para que provengan solo de una determinada región geográfica. De cualquier manera, su usuario debería ver un conjunto estable de redirecciones, y usted puede recortar esa lista de dominios de Google para simplemente img-src ''self'' *.google.com *.doubleclick.net *.googleadservices.net .
Edición: también vale la pena señalar que Fastly (y una lista creciente de otros proveedores de CDN ) se unen directamente con Google Cloud en algunos de sus Puntos de Presencia, ofreciendo una ruta optimizada a las redes de Google para su tráfico de proxy.
Puede utilizar la Lista de Wikipedia de dominios de Google . Hay muchos dominios no relacionados con Google Adwords, pero no creo que permitir dominios como youtube.com pueda causar problemas.
Actualmente la lista es:
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
Sin embargo, si quieres estar seguro de que realmente sean todos los dominios, debes preguntarle a Google directamente.