Google Analytics Content Security Policy

Ich habe die Inhalt Sicherheitspolitik:Google Analytics Content Security Policy

default-src 'none'; 
style-src 'self'; 
script-src 'self' https://www.google-analytics.com; 
img-src 'self' https://www.google-analytics.com; 
connect-src 'self';

Auf meiner Seite ich den Inline-GA-Code in einen Asynchron-Skript gesetzt habe:

<script src="/javascript/ga.js" async></script>

Dieser CSP Fehler verursacht:

Refused to load the script 'data:application/javascript;base64,KGZ1bmN0aW9uKCkgewoJLy8gaHR0cHM6Ly9kZXZl…07Cgl9OwoJZ2EucmVtb3ZlID0gbm9vcGZuOwoJd2luZG93W2dhTmFtZV0gPSBnYTsKfSkoKTs=' because it violates the following Content Security Policy directive: "script-src 'self' https://www.google-analytics.com ".

gibt es eine Möglichkeit, dieses Skript aus einer JS-Datei zu dienen, und wenn nicht, wie würde ich die CSP ändern müssen?

Quelle

2016-12-30 Tom Gullen

Könnte das dem ähnlich sein: http://stackoverflow.com/questions/41118558/what-is-the-correct-content-security-policy-for-google-analytics? –

@Eike Ich denke nicht, dass es viel Hilfe tut, sorge dafür, eine Kopfgeld auf diese Frage in der Hoffnung, eine Antwort zu bekommen. –

Es protokolliert die Header der Anfrage, aber nicht die URI. Kannst du das bitte melden? Wenn Sie auf der Registerkarte "Netzwerk" nachsehen: – gr3g

Bitte siehe Michele Spagnuolo's answer und upvote.

Dies wird durch ublock Herkunft verursacht und es ist, weil data URLs nicht die weiße Liste gesetzt werden:

script-src data:;

Es gibt keinen Grund dies, da dies tun, um Ihre Anwendung anfällig sollten nicht vertrauenswürdige Daten wie URLs überall dort eingesetzt werden lassen könnte innerhalb Ihre Anwendung oder wenn der Angreifer Tags mit solchen URLs einfügen kann. Dies hängt natürlich vom Injektionspunkt ab und welche Zeichen erlaubt sind.

Natürlich sollten Sie alle vom Nutzer eingegebenen URLs auf die Whitelist setzen (z. B. sicherstellen, dass sie mit http:// oder https:// beginnen), aber da CSP Defense-in-Depth ist, möchten Sie es wahrscheinlich nicht zu sehr schwächen.

Das Ergebnis ist, dass Sie Ihren CSP dadurch schwächen, um zu verhindern, dass ein CSP-Bericht oder ein Fehler ausgelöst wird.

Quelle

2017-01-05 12:54:39 SilverlightFox

Dies macht die Richtlinie völlig nutzlos für XSS Mitigation, da ein Angreifer einfach injizieren könnte: '' ' 'um Javascript auszuführen. –

Darin liegt der Fehler mit CSP. Zu schwierig, Post-Entwicklung und Probleme zu integrieren, sind Ihre Add-ons von Drittanbietern so konzipiert, dass ihre Implementierung Ihren CSP verwässert. – SilverlightFox

Ps. Warum der Downvote? Ich habe bereits erwähnt, dass dies die Politik schwächt. Es ist der Unterschied zwischen Analytics und nicht. – SilverlightFox

Google Analytics ist CSP-kompatibel. Das base64-kodierte data: Blob-OP wird von der uBlock Origin-Erweiterung injiziert. Um es zu überprüfen, deaktivieren Sie es/versuchen Sie es inkognito. IIRC, dies ist auf eine Einstellung "experimental/unbreak" in der Erweiterung zurückzuführen.

Bitte widerstehen Sie der Versuchung zur Whitelist data: in script-src. Das würde die Richtlinie für die XSS-Minderung völlig unbrauchbar machen, da ein Angreifer einfach <script src="data:text/javascript,alert(1)"></script> injizieren könnte, um Javascript auszuführen.

Quelle

2017-05-29 14:20:24

Google Analytics Content Security Policy

Antwort

Verwandte Themen