Polityka bezpieczeństwa treści: ustawienia strony zablokowały ładowanie zasobu

104

Używam CAPTCHA podczas ładowania strony, ale blokuje się z jakichś powodów bezpieczeństwa.

Stoję przed tym problemem:

    Polityka bezpieczeństwa treści: ustawienia strony zablokowały ładowanie
    zasobu w
    http://www.google.com/recaptcha/api.js?onload=myCallBack&render=explicit
    („script-src http://test.com:8080 'unsafe-inline' 'unsafe-eval'”).

Użyłem następującego kodu JavaScript i metatagu:

<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>
Shakti Sharma
źródło
Na twoim miejscu spróbuję to zrobić za pomocą kodu po stronie serwera, a nie javascript. JS nie radzi sobie dobrze z CORSem i podobnymi rzeczami. Google ma na to opcje ...
Gogol
Dodałem javascripttag do tego pytania, ponieważ pytanie nie ma nic wspólnego z jQuery. Wpływa na każdy JavaScript. W rzeczywistości pytanie byłoby bardziej przydatne, gdybyś jQuerycałkowicie usunął tag, ale nie jest to moim zadaniem.
Manngo
2
Teraz usunięta odpowiedź jest poprawna. Jednym z powodów „Polityki bezpieczeństwa treści: ustawienia strony blokują ładowanie zasobu” jest to, że JavaScript nie jest włączony lub zablokowany (np. Przez NoScript ) w przeglądarce. W takim przypadku część wyniku błędu może mieć postać „Nie można przetworzyć dyrektywy nieznanej 'noscript-marker'” .
Peter Mortensen
Nie mogę skomentować innej sugestii użycia about: config, więc myślę, że dodam ją tutaj. Ktoś zalecił wejście w temat: config i ustawienie security.csp.enable na false. Wszyscy inni mówili, że to okropny pomysł. Chcę tylko powiedzieć, że jest to rozwiązanie, z którego również zdecydowałem się skorzystać. Bardzo wiele witryn właśnie całkowicie przestało działać dla mnie w przeglądarce Firefox, z mnóstwem tych błędów wszędzie. Chrome nadal je ładuje. Nie wiedząc więcej o tym, dlaczego tak jest, ustawienie wartości security.csp.enable na false umożliwiło tym witrynom ponowne załadowanie przy użyciu przeglądarki Firefox, a ja wolę przeglądarkę Firefox od Chrome. Jeśli
EliT

Odpowiedzi:

85

Powiedziałeś, że możesz ładować skrypty tylko z własnej witryny (siebie). Następnie próbowałeś załadować skrypt z innej witryny ( www.google.com ), ale ponieważ to ograniczyłeś, nie możesz. O to właśnie chodzi w polityce bezpieczeństwa treści (CSP).

Możesz zmienić swoją pierwszą linię na:

<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">

Lub, alternatywnie, warto całkowicie usunąć tę linię, dopóki nie dowiesz się więcej o CSP. Twój obecny CSP i tak jest dość luźny (co pozwala unsafe-inline, unsafe-evala default-srcz *), więc prawdopodobnie nie dodając zbyt wiele wartości, aby być uczciwym.

Barry Pollard
źródło
5
Jest to niebezpieczne obejście - narzędzie do sprawdzania CSP Google podaje w tym wierszu wiele poważnych awarii. (Niestety wdrożenie dobrego CSP nie jest trywialne i musi być dostosowane do każdej witryny.)
Freewalker
8
Nie zgadzam się z tym komentarzem. Problemy z dostawcą CSP wynikają z oryginalnego dostawcy CSP. Jedyną odpowiedzią było wzięcie tego i dodanie domeny www.google.com do tego w odpowiedzi na pytanie. Czy mogłem zasugerować dalsze zaostrzenie CSP w tym samym czasie? Możliwe, ale powiedziałbym, że to jest poza zakresem tego pytania. Zwłaszcza, że ​​było już widać, że OP nie był zaznajomiony z CSP.
Barry Pollard
3
Czy CSP jest „niebezpieczny”? To dyskusyjne. Zezwolenie na niebezpieczną i niebezpieczną ewaluację oraz domyślne źródło * podważa wiele z funkcji CSP (dlatego też zasugerowałem ich usunięcie), ale należy pamiętać, że CSP nigdy nie może poluzować kontroli przeglądarki, więc nawet ta polityka utraty jest dodanie kontroli nad stroną, która nie posiada CSP - o czym świadczy fakt, że blokuje ona skrypt Google! Zatem „niebezpieczne” prawdopodobnie nie jest dobrym określeniem. „Zbyt luźne, by było warte zachodu” to być może lepszy sposób wyrażenia tego. Więc tak, ten dostawca CSP pozostawia wiele do życzenia, ale dodanie do niego Google nie jest „niebezpiecznym obejściem”.
Barry Pollard
3
Słuszna uwaga, że ​​jakikolwiek CSP (inny niż „wszystko jest w porządku) byłby generalnie lepszy niż żaden.”
Freewalker
Jest z tym mały problem, otrzymuję ten błąd z chrome://global/content/elements/panel.js(Firefox), który wyłącza debugowanie na wszystkich stronach
AaA
14

Z moim ASP.NET Core Angular projektu działającego w programie Visual Studio 2019 czasami pojawia się ten komunikat o błędzie w konsoli Firefox:

Polityka bezpieczeństwa treści: ustawienia strony blokowały ładowanie zasobu w tekście („default-src”).

W Chrome zamiast tego komunikat o błędzie to:

Nie udało się załadować zasobu: serwer odpowiedział statusem 404 ()

W moim przypadku nie miało to nic wspólnego z moją polityką bezpieczeństwa treści, a zamiast tego było po prostu wynikiem błędu TypeScript z mojej strony.

Sprawdź okno wyjściowe IDE pod kątem błędu TypeScript, na przykład:

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

Uwaga: ponieważ to pytanie jest pierwszym wynikiem w Google dla tego komunikatu o błędzie.

Daniel Congrove
źródło
11

Miałem podobny typ błędu. Najpierw próbowałem dodać metatagi w kodzie, ale to nie zadziałało.

Dowiedziałem się, że na serwerze WWW nginx możesz mieć ustawienie bezpieczeństwa, które może blokować uruchamianie zewnętrznego kodu:

# 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'";

Sprawdź Content-Security-Policy. Może być konieczne dodanie odwołania do źródła.

aCustica
źródło
4
Zwróć uwagę, że jest to niebezpieczne - ta polityka bezpieczeństwa treści otrzymuje awarie o wysokim poziomie ważności od oceny CSP Google .
Freewalker
1

Udało mi się zezwolić na wszystkie moje wymagane witryny z tym nagłówkiem:

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
źródło
0

Poradziłem sobie z tym, aktualizując zarówno wersję Angulara, której używałem (z v8 -> v9), jak i wersję TypeScript (z 3.5.3 -> najnowszą).

Entuzjasta Scala
źródło
1
Jakie jest wyjaśnienie?
Peter Mortensen
-7

Możesz je wyłączyć w swojej przeglądarce.

Firefox

Wpisz about:configpasek adresu przeglądarki Firefox, znajdź security.csp.enablei ustaw na false.

Chrom

Możesz zainstalować rozszerzenie o nazwie, Disable Content-Security-Policyaby wyłączyć CSP.

sendon1982
źródło
83
Nie rób tego NIGDY, poza tymczasowym debugowaniem. Jest to krytyczna funkcja bezpieczeństwa Twojej przeglądarki.
hackel
4
Naprawi to tylko lokalnie, a poza tym znacznie bardziej naraża przeglądarkę.
Neil Chowdhury,
3
Czy to „rada” dotycząca testowania / debugowania? Jeśli tak, należy o tym wspomnieć w odpowiedzi, aby uniknąć rozprzestrzeniania niebezpiecznych luk w nieświadomej społeczności ludzi. Nawiasem mówiąc, jak powiedział @NeilChowdhury, to naprawi to w twoim systemie, a co z rzeczywistymi odwiedzającymi witrynę?
Fr0zenFyr
13
rozwiązanie tymczasowe, ale pomocne przy debugowaniu (plus jeden)
NarendraR,
5
@hackel Zrobię to. BĘDĘ.
ア レ ッ ク ス