La sécurité Web, vue via les entêtes du navigateur – Episode 1 – Le Content-Security Policy

Pour lutter contre l’insécurité du Web il est répété régulièrement de ne pas faire confiance au contenu venant des navigateurs. Mais il n’est jamais dit que le navigateur ne peut être d’une certaine utilité dans cette lutte.

Dans cette lutte implacable, Madame Michu dispose d’un navigateur qu’elle a téléchargée sur Internet, ou qui lui a été livré avec son ordinateur PC ou Mac (il est loin le temps des Kit FAI avec le navigateur moisi fourni).

Récemment(tout est relatif, car cela bouge pas mal)  un certain nombre de fonctionnalités sont apparues (sous forme de draft/RFC IETF ) permettant d’améliorer la sécurité globale dans un monde Web.

Voici donc quelques une de ces fonctionnalités que vous allez pouvoir utiliser pour « aider » le navigateur et la sécurité de votre application Web :

Ce billet parle du Content Security Policy. Pas que les autres ne sont pas intéressants, mais nous les traiterons par ailleurs chacun.

Donc le CSP, avant de l’utiliser il est bon de savoir si il est possible de l’utiliser dans son navigateur. Pour cela vous pouvez vous retourner vers le superbe site anglais CanIUse.com qui vous indiquera si votre navigateur est compatible ou pas avec la directive.

Content Security Policy 

Il existe plusieurs versions (en fait 2) du CSP, la v2.0 étant très peu supportée actuellement

Actuellement les navigateurs ont tous un niveau de support plutôt différent (IE est encore une fois a la traine), comme on peut le voir sur le graphique suivant pour la V1.0:

NewImage

Le principe du CSP est de donner  le contrôle sur le contenu dit « sur ». En effet aujourd’hui il existe peu de sites Web qui contiennent tout le code à exécuter et les exécutions de JavaScript ne sont la plupart du temps uniquement possible que via le site d’ou provient le .JS. Cela peut poser des problèmes via AJAX car il est possible d’avoir besoin de contenu se trouvant sur un autre site Web. Dans ce cas il est nécessaire de pouvoir limiter le téléchargement, voir l’exécution du code en fonction de ce que souhaite le développeur. Cela permettra de limiter les attaques de type XSS, et autres joyeusetés que nous pourrions avoir dans le site Web.

Le site http://content-security-policy.com résume bien tout ce qu’il est possible d’utiliser.

D’un point de vue très simple nous pourrions dire qu’il y en a 3 d’importants :

  • default-src : tous les contenus peuvent venir de cette zone
  • script-src : les Javascripts ne peuvent venir que de cette zone
  • img-src : Les images elles sont ici.

Il suffit alors de spécifier la ligne suivante pour donner une politique de contenu au navigateur

Content-Security-Policy: default-src 'self'; img-src img.example.com; script-src api.example.com

Dans ce cas, cela veut donc dire :

  • Les images ne sont possibles que depuis img.example.com
  • Les scripts depuis api.example.com

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s