Czy zasady bezpieczeństwa treści mogą być zgodne z Google Analytics i AdSense?

Question

Czy ktoś wie, jak uzyskać CSP, nawet z symbolem wieloznacznym default-src, aby działał w taki sposób, aby nowoczesny skrypt Analytics wysyłał dane strony na stronę (a nie tylko dane strony głównej) na konto właściciela witryny, aby wyświetlały się reklamy AdSense?

Próbowałem wielu odmian CSP na mojej stronie internetowej, w tym w pliku <H5BP.com> .htaccess, ale wszystkie zablokowały Google Analytics tworzenie danych na stronę (z wyjątkiem strony głównej) i Google AdSense od akceptowania reklam na dowolnej stronie.

Maszyny Google nie widziały skryptu Analytics, mimo że ludzie Google zawsze widzieli go w kodzie źródłowym mojej witryny. Nawet ustawienie domyślnego CSP-src na gwiazdce gwiazdki nie powiodło się.

Pytając na forum Google i na forum innym niż Google, nic nie działało, poza tym, że ludzie mówili, że problem dotyczył mojego CSP, i otrzymałem jeden e-mail z informacją, że powinienem całkowicie skomentować CSP. To ostatnie zadziałało. Komentowanie nie powinno być lepsze niż wildcard default-src, ale komentowanie to jedyny sposób, w jaki otrzymuję reklamy i dane wewnątrz witryny.

• I wysłana do Google około miesiąc temu z powodu niekompatybilności ale nie obalił, że odpowiedź (https://www.en.advertisercommunity.com/t5/Code-Implementation/content-security-policy-and-Analytics-and-likely-AdSense/m-p/491031).

• przepełnienia stosu odpowiedzi na < Google Analytics and Content-Security-Policy header > nie oznacza, że ​​ktoś jest uzyskiwanie danych Wewnątrz stronie Analytics i że gwint jest oparte na przestarzałej skryptu Google.

• Gwint na < Google analytics.js and Content Security Policy > jest dla aplikacji, a nie strony, nikt nie poinformował coraz wewnątrz-stronie dane Analytics, a moje wysiłki zawiodły nawet przy maksymalnie pozwalającej CSP.

• Rozwiązaniem jest w wątku < Google analytics Universal code not tracking > ale rozwiązanie jest ograniczone do ustawiania CSP do raportowania, nie blokuje, co nie jest zbyt użyteczne dla mnie.

Brak wątku przepełnienia stosu dotyczy CSP i AdSense. Kiedy zaproponowałem, aby H5BP informował użytkowników o tym w ich modelu <. Htaccess >, ich respondent powiedział, że działa dla niego i odesłał mnie do ciebie.

Czy ktoś, kto widzi dane dotyczące danej strony na swoim koncie Google Analytics i widzi reklamy AdSense w trakcie działania .htaccess CSP?

Answer 1

Korzystanie poniżej kod działa dla mnie:

default-src 'self' googleads.g.doubleclick.net; 
script-src 'self' 'unsafe-inline' data: pagead2.googlesyndication.com storage.googleapis.com googleads.g.doubleclick.net ajax.googleapis.com; 
img-src 'self' data: storage.googleapis.com pagead2.googlesyndication.com; 
style-src 'self' 'unsafe-inline'; 
font-src 'self' fonts.googleapis.com; frame-ancestors 'self'; object-src 'self' 

Answer 2

Albo zalogować wszystkie błąd z raport-uri źródeł dodać do CSP.

JSON prześle pod ten adres URL (https://example.com/csp/log.php).

Content-Security-Policy: default-src 'self'; 
report-uri: https://example.com/csp/log.php; 

Answer 3

Nie. Od dzisiaj (8 września 16). Wyłączyliśmy CSP, ponieważ źródło ramki Google było domeną -> frame-src: ... google.co.uk google.co.fr ...

Answer 4

Adsense

Dla Google AdSense, na przykład ten kod CSP "działa":

Content-Security-Policy: frame-ancestors 'self'; 

Zapobiega to oprawianiu strony bez ograniczania możliwości strony. Stąd jego ochrona XSS nie istnieje.

Ale skrypty AdSense mogą ładować coś, co ładuje, co z kolei ładuje itp. I biorąc pod uwagę tysiące (w chwili pisania: 3103) zewnętrznych sieci reklamowych, z których mogą korzystać, po prostu nie ma rozsądnego ani praktycznego sposobu abyśmy kiedykolwiek wiedzieli, czego mogą potrzebować wszystkie reklamy. Tak więc, aby uniknąć sytuacji, w której zamierzasz załadować obrazy, flash, javascript itp., Jeśli chcesz, aby Adsense właśnie się nie stało.

Jedno albo drugie:

• albo Adsense
• albo restrykcyjne CSP

Ale nie oba.

Analytics

to inna sprawa, już uwzględnione w innych odpowiedzi. [Nie użytkownik]

polityka CSP

Potencjalni autorzy dopuszczalnych polityk CSP należy przypomnieć, że na przykład https: i * nie obejmują uprawnień do źródeł unsafe-inline ani data:. Widziałem już kilka miejsc w sieci, w których autorzy zakładają, że tak robią.

Podczas pisania zasad lepiej jest najpierw umieścić tylko raport. Nagłówek nosi nazwę "Content-Security-Policy-Report-Only" zamiast "Content-Security-Policy" i nie zatrzyma niczego, po prostu wykonaj część raportowania w jsonie do określonego miejsca docelowego. Zobacz tutaj: https://developers.google.com/web/fundamentals/security/csp/#report-only

Answer 5

Przy ścisłym CSP 3 i noncesach, myślę, że jest to możliwe, ale nie mam możliwości testowania, ponieważ nie używamy AdSense.

1.) Umieść wszystkie javascript w (GA, AdSense, itp.) W plikach .js. Brak wbudowanego JS.

2.) Za pomocą proponowanego "ścisłe" CSP: https://csp.withgoogle.com/docs/strict-csp.html

3.) obejmują pliki .js jak zwykle zawierać dowolny plik, ale dodać nonce:

<script src="/mygooganalytics.js" nonce="[your nonce here]"></script> 

Efekt powinno być, że wszystko, co pochodzi od mygooganalytics.js, będzie dozwolone. Niestandardowe są zwykle tworzone przez kod po stronie serwera (php, ruby, itp.), Ale jeśli jest to poza twoją aplikacją/w zwykłym starym pliku html, możesz wygenerować numer przy użyciu twojego serwera. Jeśli używasz Apache: Generate a nonce with Apache 2.4 (for a Content Security Policy header)