Inhaltssicherheitsrichtlinie: Die Einstellungen der Seite blockierten das Laden einer Ressource

100

Ich verwende CAPTCHA beim Laden von Seiten, aber es wird aus Sicherheitsgründen blockiert.

Ich stehe vor diesem Problem:

    Inhaltssicherheitsrichtlinie: Die Einstellungen der Seite haben das Laden blockiert
    einer Ressource bei
    http://www.google.com/recaptcha/api.js?onload=myCallBack&render=explicit
    ("script-src http://test.com:8080 'unsicher-inline' 'unsicher-eval'").

Ich habe das folgende JavaScript und Meta-Tag verwendet:

<meta http-equiv="Content-Security-Policy" content="default-src *; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval'">
<script src="http://www.google.com/recaptcha/api.js?onload=myCallBack&render=explicit" async defer></script>

javascript jquery content-security-policy

— Shakti Sharma
quelle

Wenn ich Sie wäre, würde ich versuchen, dies mit serverseitigem Code und nicht mit Javascript zu tun. JS ist nicht so gut mit CORS und ähnlichen Dingen. Google hat Optionen dafür ..

— Gogol

Ich habe javascriptdieser Frage ein Tag hinzugefügt , da die Frage nichts mit jQuery zu tun hat. Es betrifft jedes JavaScript. Tatsächlich wäre die Frage nützlicher, wenn Sie das jQueryTag vollständig entfernen , aber es ist nicht meine Aufgabe, dies zu tun.

— Manngo

1

Eine jetzt gelöschte Antwort ist korrekt. Ein Grund für "Inhaltssicherheitsrichtlinie: Die Einstellungen der Seite haben das Laden einer Ressource blockiert" ist, wenn JavaScript im Browser nicht aktiviert oder blockiert ist (z. B. durch NoScript ). In diesem Fall könnte ein Teil der Fehlerausgabe "Unbekannte Direktive 'Noscript-Marker' konnte nicht verarbeitet werden" sein .

— Peter Mortensen

83

Sie haben gesagt, Sie können nur Skripte von Ihrer eigenen Site (selbst) laden. Sie haben dann versucht, ein Skript von einer anderen Website ( www.google.com ) zu laden, und können dies nicht, da Sie dies eingeschränkt haben. Das ist der springende Punkt der Content Security Policy (CSP).

Sie können Ihre erste Zeile ändern in:

<meta http-equiv="Content-Security-Policy" content="default-src *; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval' http://www.google.com">

Alternativ kann es sich lohnen, diese Zeile vollständig zu entfernen, bis Sie mehr über CSP erfahren. Ihre aktuellen CSP ist ziemlich lax sowieso (erlaubt unsafe-inline, unsafe-evalund ein default-srcvon *), so ist es wahrscheinlich nicht zu viel Wert hinzufügen, um ehrlich zu sein.

— Barry Pollard
quelle

5

Dies ist eine unsichere Problemumgehung. Der CSP-Checker von Google weist dieser Zeile mehrere schwerwiegende Fehler zu. (Leider ist die Implementierung eines guten CSP nicht trivial und muss pro Site angepasst werden.)

— Freewalker

6

Ich habe Probleme mit diesem Kommentar. Die Probleme mit dem CSP sind auf den ursprünglichen CSP zurückzuführen. Alles, was diese Antwort getan hat, war, das zu nehmen und die Domain www.google.com als Antwort auf die Frage hinzuzufügen. Könnte ich vorgeschlagen haben, den CSP gleichzeitig weiter zu straffen? Möglicherweise, aber ich würde sagen, dass dies für die Frage nicht möglich ist. Zumal bereits klar war, dass das OP mit CSP nicht vertraut war.

— Barry Pollard

3

Ist der CSP jetzt "unsicher"? Das ist fraglich. Das Zulassen von unsicherem Inline- und unsicherem Auswerten und einer Standardquelle von * macht einen Großteil des Zwecks eines CSP zunichte (daher habe ich auch vorgeschlagen, ihn zu entfernen), aber es sollte beachtet werden, dass CSP niemals Browser-Steuerelemente lockern kann, so dass selbst diese Richtlinie verloren geht Hinzufügen einer gewissen Kontrolle über eine Seite ohne CSP - wie die Tatsache zeigt, dass ein Google-Skript blockiert wird! "Unsicher" ist also wahrscheinlich kein guter Begriff. "Zu locker, um sich zu lohnen" ist vielleicht eine bessere Formulierung. Ja, dieser CSP lässt zu wünschen übrig, aber das Hinzufügen von Google ist keine "unsichere Problemumgehung".

— Barry Pollard

3

Fairer Punkt, dass jeder CSP (außer "alles ist in Ordnung) im Allgemeinen besser wäre als keiner.

— Freewalker

14

Wenn mein ASP.NET Core Angular- Projekt in Visual Studio 2019 ausgeführt wird, wird manchmal die folgende Fehlermeldung in der Firefox-Konsole angezeigt:

Inhaltssicherheitsrichtlinie: Die Einstellungen der Seite blockierten das Laden einer Ressource bei Inline ("default-src").

In Chrome lautet die Fehlermeldung stattdessen:

Ressource konnte nicht geladen werden: Der Server antwortete mit dem Status 404 ()

In meinem Fall hatte dies nichts mit meiner Inhaltssicherheitsrichtlinie zu tun, sondern war einfach das Ergebnis eines TypeScript-Fehlers meinerseits.

Überprüfen Sie Ihr IDE-Ausgabefenster auf einen TypeScript-Fehler wie:

> ERROR in src/app/shared/models/person.model.ts(8,20): error TS2304: Cannot find name 'bool'.
>
> i ｢wdm｣: Failed to compile.

_{Hinweis: Da diese Frage das erste Ergebnis bei Google für diese Fehlermeldung ist.}

— Daniel Congrove
quelle

11

Ich hatte einen ähnlichen Fehlertyp. Zuerst habe ich versucht, die Meta-Tags in den Code einzufügen, aber es hat nicht funktioniert.

Ich habe herausgefunden, dass Sie auf dem nginx-Webserver möglicherweise eine Sicherheitseinstellung haben, die die Ausführung von externem Code blockiert:

# Security directives
server_tokens off;
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'  https://ajax.googleapis.com  https://ssl.google-analytics.com https://assets.zendesk.com https://connect.facebook.net; img-src 'self' https://ssl.google-analytics.com https://s-static.ak.facebook.com https://assets.zendesk.com; style-src 'self' 'unsafe-inline' https://assets.zendesk.com; font-src 'self' https://fonts.gstatic.com  https://themes.googleusercontent.com; frame-src https://player.vimeo.com https://assets.zendesk.com https://www.facebook.com https://s-static.ak.facebook.com https://tautt.zendesk.com; object-src 'none'";

Überprüfen Sie die Content-Security-Policy. Möglicherweise müssen Sie die Quellreferenz hinzufügen.

— aCustica
quelle

3

Beachten Sie, dass dies nicht sicher ist. Diese Content-Security-Richtlinie weist vom CSP-Evaluator von Google Fehler mit hohem Schweregrad auf .

— Freewalker

1

Ich habe es geschafft, alle meine erforderlichen Sites mit diesem Header zuzulassen:

header("Content-Security-Policy: default-src *; style-src 'self' 'unsafe-inline'; font-src 'self' data:; script-src 'self' 'unsafe-inline' 'unsafe-eval' stackexchange.com");

— rubo77
quelle

0

Ich habe dies umgangen, indem ich sowohl die von mir verwendete Version von Angular (von Version 8 -> Version 9) als auch die Version von TypeScript (von Version 3.5.3 -> Version) aktualisiert habe.

— Scala Enthusiast
quelle

1

Was ist die Erklärung?

— Peter Mortensen

-9

Sie können sie in Ihrem Browser deaktivieren.

Feuerfuchs

Geben Sie about:configdie Firefox-Adressleiste ein und suchen Sie sie security.csp.enableund setzen Sie sie auf false.

Chrom

Sie können die aufgerufene Erweiterung installieren Disable Content-Security-Policy, um CSP zu deaktivieren.

— sendon1982
quelle

78

Tun Sie dies NIEMALS, abgesehen vom vorübergehenden Debuggen. Dies ist eine wichtige Sicherheitsfunktion Ihres Browsers.

— Hackel

4

Dadurch wird das Problem nur lokal behoben, und außerdem ist Ihr Browser viel anfälliger.

— Neil Chowdhury

3

Ist dies ein "Rat" zum Testen / Debuggen? Wenn ja, sollte dies als Antwort erwähnt werden, um zu vermeiden, dass gefährliche Schwachstellen in einer unbewussten Personengemeinschaft verbreitet werden. Übrigens, wie @NeilChowdhury sagte, wird dies das Problem auf Ihrem System beheben. Was ist mit den tatsächlichen Website-Besuchern?

— Fr0zenFyr

12

vorübergehende Lösung, aber hilfreich für das Debuggen (plus eins)

— NarendraR

4

@ Hackel Ich werde das tun. ICH WERDE.

— レック