Refus de charger le script car il enfreint la directive de politique de sécurité du contenu suivante

99

Lorsque j'ai essayé de déployer mon application sur des appareils avec un système Android supérieur à 5.0.0 ( Lollipop ), j'ai continué à recevoir ce type de messages d'erreur:

07-03 18: 39: 21.621: D / SystemWebChromeClient (9132): file: ///android_asset/www/index.html: Ligne 0: a refusé de charger le script 'http: // xxxxx' car il viole le contenu suivant Directive de politique de sécurité: "script-src 'self' 'unsafe-eval' 'unsafe-inline'". 07-03 18: 39: 21.621: I / chromium (9132): [INFO: CONSOLE (0)] "Refus de charger le script 'http: // xxx' car il enfreint la directive de politique de sécurité du contenu suivante:" script- src 'self' 'unsafe-eval' 'unsafe-inline' ".

Cependant, si je l'ai déployé sur un appareil mobile avec le système Android de 4.4.x ( KitKat ), la politique de sécurité fonctionne avec celles par défaut:

<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; media-src *">

Alors j'ai pensé, peut-être, je devrais changer pour quelque chose comme ceci:

<meta http-equiv="Content-Security-Policy" content="script-src 'self' 'unsafe-eval' 'unsafe-inline'; object-src 'self'; style-src 'self' 'unsafe-inline'; media-src *">

Fondamentalement, les deux options ne fonctionnent pas pour moi. Comment puis-je résoudre ce problème?

MangooSaSa
la source
Très similaire à mon problème. Je ne parviens pas à récupérer un fichier JSON, "car il enfreint la directive de politique de sécurité du contenu suivante:" connect-src 'self' ""
Michael R
1
@MichaelR Si vous souhaitez récupérer des informations JSON de l'API via JS comme l'addon tampermonkey ou tout le reste, vous pouvez utiliser ce plugin chrome.google.com/webstore/detail/disable-content-security/… et désactiver la vérification CSP pendant que vous voulez obtenir quelque chose. Ce n'est pas du tout sûr mais dans certains cas, cela peut fonctionner. Je poste cette réponse ici parce que je cherchais mon erreur et que ce sujet apparaît en premier dans Google.
Eryk Wróbel

Réponses:

65

Essayez de remplacer votre balise Meta par celle-ci ci-dessous:

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

Ou en plus de ce que vous avez, vous devez ajouter http://*les deux style-srcet script-srccomme vu ci-dessus ajouté après «soi».

Si votre serveur inclut l'en- Content-Security-Policytête, l'en-tête remplacera la méta.

Ashikodi
la source
6
Si je comprends bien, le CSP que vous définissez ici désactive tout type de sécurité pour éviter les attaques, autorisant les balises de script et chargeant également des scripts à partir de n'importe quel domaine et également via des connexions non sécurisées. voir developer.google.com/web/fundamentals/security/csp Ou est-ce que je reçois s.th. faux? Je suppose que dans la plupart des cas (à l'exception du développement et du débogage) ce n'est pas ce que vous voulez ... non?
Peter T.15
1
Voir aussi infosec.mozilla.org/guidelines/…
Peter T.
9
Je voterais contre cette réponse, car vous suggérez d'utiliser «unsafe-inline» «unsafe-eval», ce que vous ne devriez pas lors de l'utilisation de CSP!
HerTesla
39

La réponse personnelle donnée par MagngooSasa a fait l'affaire, mais pour quiconque essaie de comprendre la réponse, voici quelques détails supplémentaires:

Lors du développement d' applications Cordova avec Visual Studio, j'ai essayé d'importer un fichier JavaScript distant [situé ici http://Guess.What.com/MyScript.js], mais j'ai l'erreur mentionnée dans le titre.

Voici la balise meta avant , dans le fichier index.html du projet:

<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'; style-src 'self' 'unsafe-inline'; media-src *">

Voici la balise meta corrigée , pour permettre l'importation d'un script distant:

<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'; style-src 'self' 'unsafe-inline'; media-src *;**script-src 'self' http://onlineerp.solution.quebec 'unsafe-inline' 'unsafe-eval';** ">

Et plus d'erreur!

Simon
la source
14

Il a été résolu avec:

script-src 'self' http://xxxx 'unsafe-inline' 'unsafe-eval';
MangooSaSa
la source
46
pourriez-vous s'il vous plaît l'expliquer un peu plus? Pouvez-vous coller la méta complète?
Tony
1
Cela désactive efficacement CSP pour les scripts en permettant à tous les plugins / xss malveillants d'injecter des scripts en ligne et d'évaluation, ce qui va à l'encontre de l'objectif même de l'activation de CSP.
IncredibleHat
7

Nous avons utilisé ceci:

<meta http-equiv="Content-Security-Policy" content="default-src gap://ready file://* *; style-src 'self' http://* https://* 'unsafe-inline'; script-src 'self' http://* https://* 'unsafe-inline' 'unsafe-eval'">
Simprão
la source
7

Pour tous ceux qui recherchent une explication complète, je vous recommande de consulter la politique de sécurité du contenu: https://www.html5rocks.com/en/tutorials/security/content-security-policy/ .

« Code de https://mybank.com ne devrait avoir accès à https://mybank.com les données « , et https://evil.example.com devrait certainement jamais accès autorisé. Chaque origine est maintenue isolée de la reste du Web "

Les attaques XSS sont basées sur l'incapacité du navigateur à distinguer le code de votre application du code téléchargé à partir d'un autre site Web. Vous devez donc mettre sur liste blanche les origines de contenu que vous considérez comme sûres pour télécharger du contenu, à l'aide de l' Content-Security-Policyen-tête HTTP.

Cette stratégie est décrite à l'aide d'une série de directives de stratégie, chacune décrivant la stratégie pour un certain type de ressource ou domaine de stratégie. Votre stratégie doit inclure une directive de stratégie default-src, qui est une solution de secours pour les autres types de ressources lorsqu'ils n'ont pas de stratégies qui leur sont propres.

Donc, si vous modifiez votre balise pour:

<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'; style-src 'self' 'unsafe-inline'; media-src *;**script-src 'self' http://onlineerp.solution.quebec 'unsafe-inline' 'unsafe-eval';** ">

Vous dites que vous autorisez l'exécution de code Javacsript ( script-src) des origines 'self', http://onlineerp.solution.quebec, 'unsafe-inline', 'unsafe-eval'.

Je suppose que les deux premiers sont parfaitement valables pour votre cas d'utilisation, je ne suis pas sûr des autres. 'unsafe-line'et 'unsafe-eval'posent un problème de sécurité, vous ne devriez donc pas les utiliser sauf si vous en avez un besoin très spécifique:

"Si eval et ses frères text-to-JavaScript sont absolument essentiels à votre application, vous pouvez les activer en ajoutant 'unsafe-eval' comme source autorisée dans une directive script-src. Mais, encore une fois, ne le faites pas. la possibilité d'exécuter des chaînes rend beaucoup plus difficile pour un attaquant d'exécuter du code non autorisé sur votre site. " (Mike West, Google)

Rocío García Luque
la source
Pourquoi dans ma page localhost je peux ajouter un autre script hôte?
mqliutie
Il n'est pas rare de réutiliser des scripts tiers qui ne sont pas hébergés sur votre serveur mais dans lesquels vous "faites confiance"
Rocío García Luque
6

Chaîne d'autorisation complète

Les réponses précédentes n'ont pas résolu mon problème, car elles n'incluent pas de blob: data: gap:mots clés en même temps; voici donc une chaîne qui fait:

<meta http-equiv="Content-Security-Policy" content="default-src * self blob: data: gap:; style-src * self 'unsafe-inline' blob: data: gap:; script-src * 'self' 'unsafe-eval' 'unsafe-inline' blob: data: gap:; object-src * 'self' blob: data: gap:; img-src * self 'unsafe-inline' blob: data: gap:; connect-src self * 'unsafe-inline' blob: data: gap:; frame-src * self blob: data: gap:;">

Attention: cela expose le document à de nombreux exploits. Veillez à empêcher les utilisateurs d'exécuter du code dans la console ou de se trouver dans un environnement fermé comme une application Cordova .

Alexandre Daubricourt
la source
1
C'est la bonne réponse si vous essayez de charger par exemple JQuery dans la console comme ceci: stackoverflow.com/a/31912495/137948
Will Sheppard
4

Pour en dire plus à ce sujet, ajoutez

script-src 'self' http://somedomain 'unsafe-inline' 'unsafe-eval';

à la balise meta comme ça,

<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'; style-src 'self' 'unsafe-inline'; script-src 'self' https://somedomain.com/ 'unsafe-inline' 'unsafe-eval';  media-src *">

corrige l'erreur.

James Nicholson
la source
2

L'ajout de la balise meta pour ignorer cette politique ne nous a pas aidés, car notre serveur Web injectait l'en- Content-Security-Policytête dans la réponse.

Dans notre cas, nous utilisons Ngnix comme serveur Web pour une application Tomcat 9 Java. Depuis le serveur Web, il ordonne au navigateur de ne pas autoriser inline scripts, donc pour un test temporaire, nous avons désactivé Content-Security-Policyen commentant.

Comment le désactiver dans ngnix

  • Par défaut, le fichier ngnix ssl.conf aura ceci en ajoutant un en-tête à la réponse:

    #> grep 'Content-Security' -ir /etc/nginx/global/ssl.conf add_header Content-Security-Policy "default-src 'none'; frame-ancestors 'none'; script-src 'self'; img-src 'self'; style-src 'self'; base-uri 'self'; form-action 'self';";

  • Si vous commentez simplement cette ligne et redémarrez ngnix, cela ne devrait pas ajouter l'en-tête à la réponse.

Si vous êtes préoccupé par la sécurité ou en production, veuillez ne pas suivre cette procédure, utilisez ces étapes uniquement à des fins de test et pour passer à autre chose.

prem
la source
-1

La raison probable pour laquelle vous obtenez cette erreur est probablement parce que vous avez ajouté le dossier / build à votre fichier .gitignore ou que vous ne l'avez généralement pas archivé dans Git.

Ainsi, lorsque vous appuyez sur le maître Heroku par Git , le dossier de construction que vous référencez n'est pas poussé vers Heroku. Et c'est pourquoi il montre cette erreur.

C'est la raison pour laquelle cela fonctionne correctement localement, mais pas lorsque vous avez déployé sur Heroku.

Sachin
la source
J'ai le même problème. alors suggérez-vous de supprimer / construire le dossier du .gitignore?
Hoang Minh