Logo Khaganat

Wikhan

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
Dernière révisionLes deux révisions suivantes
fr:securite_sysadmin [2020/10/25 18:54] – ↷ Liens modifiés en raison d'un déplacement. zatalyzfr:securite_sysadmin [2021/12/03 19:19] – modification externe 127.0.0.1
Ligne 176: Ligne 176:
 header set X-Clacks-Overhead "GNU Terry Pratchett" header set X-Clacks-Overhead "GNU Terry Pratchett"
 # Enfin, les CSP permettent de vérifier l'origine des éléments du site # Enfin, les CSP permettent de vérifier l'origine des éléments du site
-# CSP, pour eviter de charger des scripts d'ailleurs. +# CSP, pour eviter de charger des scripts d'ailleurs. /!\ partie complexe à gérer suivant vos CMS 
-Header set Content-Security-Policy "default-src 'self' "+Header set Content-Security-Policy "default-src 'self' *.monsite.org 'unsafe-eval' 'unsafe-inline' "
 </code> </code>
  
 Les explications : Les explications :
   * Header set X-Robots-Tag : http://robots-txt.com/x-robots-tag/   * Header set X-Robots-Tag : http://robots-txt.com/x-robots-tag/
-  * CSP : https://ole.michelsen.dk/blog/secure-your-website-with-content-security-policy.html . +  * CSP : https://ole.michelsen.dk/blog/secure-your-website-with-content-security-policy.html 
  
-<WRAP center round info 90%> +== Content Security Policy (CSP) == 
-Note à propos de CSP :+Les CSP améliorent grandement la sécurité d'une installation, en interdisant à certaines ressources de s'exécuter, par exemple des scripts malicieux injectés dans vos sites webs.
  
-Il est difficile de faire marcher les CMS tout en ayant une politique sécurisée sur les CSP. +Mais il est difficile de faire marcher les CMS tout en ayant une politique sécurisée sur les CSP. 
  
-L'option suivante permet à Dokuwiki et Simple Machine Forum de marcher, mais pas à Etherpad, et ne vaut rien aux yeux de [[https://observatory.mozilla.org/|l'Observatoire Mozilla]]. +Le site de référence est [[https://content-security-policy.com/]]. En anglais, mais il contient toute la documentation officielle sur le sujet. 
 + 
 +  * Premier cas : pas de politique CSP. Certains CMS permettent aux utilisateurs d'appeler "des bouts de web" venant d'ailleurs, généralement les images, mais dans certains cas aussi du code... Un attaquant peut se servir de ça pour appeler sur le serveur un code malicieux. Un CMS sécurisé réduit beaucoup les possibilités, mais le risque zéro n'existe pas, et la plupart des CMS ont des failles, c'est un fait. 
 +  * Second cas : une politique CSP stricte (paramétrée uniquement sur ''self''). Ici, plus moyen d'appeler un truc d'ailleurs. Par contre cela va bloquer le fonctionnement légitime de certains CMS, entre autre ce qui concerne les scripts (pourquoi, je n'ai pas pas encore bien compris, mais c'est un fait). 
 +  * Troisième cas : ajouter des règles comme ''unsafe-eval'' et ''unsafe-inline''. Cela va permettre aux scripts en question de fonctionner MAIS cela permet aussi à certains attaquant d'utiliser des failles : comme leur nom l'indique, cela est considéré comme "non sécurisé". Ils autorisent explicitement certains trucs à marcher, sans plus de vérification. Cela ouvre la porte à des injections. Cependant, d'après mes tests, les scripts ayant une adresse externe ne sont PAS exécutés sur le domaine. Ne vous sentez pas en confiance pour autant. 
 +  * Quatrième cas : exécuter localement uniquement les scripts validés explicitement. Cela demande de rajouter la variable ''nonce'' ou ''hash'', puis d'ajouter dans chacun des scripts de notre serveur la clé associée (un hash sur les scripts, ou bien une clé dans ces derniers). Cela veut donc dire : avoir la main sur tout... c'est assez irréaliste dans la majorité des cas, et entre autre pour les CMS qui embarquent trop de scripts et qui écraseront nos modifications à chaque mise à jour. Cela demande aussi un certain niveau de développement, or la plupart des sysadmin/webmestres sont surtout des bidouilleuses, pas des développeuses. 
 + 
 +== Quelques exemples == 
 + 
 +L'option suivante permet à Dokuwiki et Simple Machine Forum de marcher, mais pas à Etherpad, et ne vaut rien aux yeux de [[https://observatory.mozilla.org/|l'Observatoire Mozilla]]. Cependant, même l'etherpad de Mozilla ne fait pas mieux.
   Header set Content-Security-Policy "default-src 'self' *khaganat.net; script-src 'self' 'unsafe-inline' *khaganat.net; style-src 'self' 'unsafe-inline'; img-src * "   Header set Content-Security-Policy "default-src 'self' *khaganat.net; script-src 'self' 'unsafe-inline' *khaganat.net; style-src 'self' 'unsafe-inline'; img-src * "
      
-En effet, le paramètre ''unsafe-inline'' est, comme son nom l'indique, pas vraiment sécurisé, sans parler de ''img-src *'' qui accepte tout (mais sans ça, bonjour pour accepter les images en lien...).  +''img-src *'' ici accepte tout, mais sans ça, on n'affiche plus les images en lien, par exemple dans le forum, ce qui demande une solution interne pour les héberger.
-</WRAP> +
-<WRAP center round todo 60%> +
-Travail en cours, on va trouver l'option ultime pour CSP, qui permette sécurité, A+ et fonctionnalités :-)+
  
-Pour le moment, cependant, etherpad bloque un csp de qualité. Même l'etherpad de Mozilla ne fait pas mieux.</WRAP> +Pour onlyoffice, après de nombreuses galères : la solution a été la CSP frame-ancestors pour permettre l'accès à une autre instance Onlyoffice par plusieurs instances nextcloud. Dans ce cas sur nginx avec le module more_headers, ça a donné ça :
-<WRAP center round info 60%> +
-J'ai pas mal galéré ces derniers avec onlyoffice. Ma solution a été la CSP frame-ancestors pour permettre l'accès à mon instance onlyoffice par plusieurs instances nextcloud. Dans mon cas sur nginx avec le module more_headers, ça a donné ça :+
   more_set_headers "Content-Security-Policy : frame-ancestors https://site1.example.com/nextcloud https://site2.example.com/ https://site3.example.com/nextcloud ";   more_set_headers "Content-Security-Policy : frame-ancestors https://site1.example.com/nextcloud https://site2.example.com/ https://site3.example.com/nextcloud ";
-</WRAP>+ 
 +La règle suivante, assez générique, va "fonctionner" pour la plupart des CMS. La mettre dans une règle sur le proxy, appelée par les diverses configurations : 
 +  add_header Content-Security-Policy "default-src 'self' *.monsite.org 'unsafe-eval' 'unsafe-inline'; "; 
  
  
Ligne 242: Ligne 249:
 Ce qui suit est extrait d'une conversation avec TychoBrahe ; j'ai conservé son style fleuri si savoureux.  Ce qui suit est extrait d'une conversation avec TychoBrahe ; j'ai conservé son style fleuri si savoureux. 
  
- --- //[[fr:wikitools:user:zatalyz|zatalyz]] 2016/12/30 13:27//+ --- //[[user:zatalyz|zatalyz]] 2016/12/30 13:27//
 </WRAP> </WRAP>
  
Ligne 337: Ligne 344:
 Je n'ai sans doute pas tout compris, ou alors ce n'est pas compatible avec ma version d'apache, mais si je l'ajoute ça me fait une erreur. Je n'ai sans doute pas tout compris, ou alors ce n'est pas compatible avec ma version d'apache, mais si je l'ajoute ça me fait une erreur.
  
- --- //[[fr:wikitools:user:zatalyz|zatalyz]] 2017/01/01 18:33//+ --- //[[user:zatalyz|zatalyz]] 2017/01/01 18:33//
 </WRAP> </WRAP>
  
CC Attribution-Share Alike 4.0 International Driven by DokuWiki
fr/securite_sysadmin.txt · Dernière modification : 2023/06/21 08:30 de zatalyz
Licences Mentions légales Accueil du site Contact