CORS, CSP, HTTPS, HSTS: À propos des technologies de sécurité Web

L'auteur du document, dont nous publions la traduction aujourd'hui, affirme qu'il existe de nombreuses raisons d'étudier la sécurité Web. Par exemple, les utilisateurs de sites Web qui sont préoccupés par le vol de leurs données personnelles sont intéressés par les problèmes de sécurité. La sécurité concerne les développeurs web qui cherchent à augmenter le niveau de protection de leurs projets. La même chose peut être dite des programmeurs débutants qui recherchent du travail et se préparent pour des entretiens. Le but de cet article est de comprendre certaines technologies de sécurité Web importantes dans un langage compréhensible. Avant de commencer à parler de ces technologies, qui sont généralement appelées abréviations comme CORS, CSP et HSTS, nous allons examiner quelques concepts de sécurité de base.

Deux concepts de sécurité Web de base

La protection à 100% est un mythe

Dans le monde de la sécurité, il n'existe pas de «protection à 100% contre le piratage». Si quelqu'un vous parle de ce niveau de protection, sachez qu'il a tort.

▍Un niveau de protection ne suffit pas

Supposons que quelqu'un pense qu'en mettant en œuvre le CSP, il a entièrement protégé son projet contre les attaques XSS. Peut-être que quelqu'un perçoit que la protection absolue n'existe pas comme une donnée, mais des pensées comme celle décrite ci-dessus peuvent rendre visite à n'importe qui. Si nous parlons de programmeurs qui ont décidé de comprendre les problèmes de sécurité, la raison de ces réflexions est peut-être le fait que, lors de l'écriture de code de programme, ils fonctionnent principalement avec des concepts tels que "noir" et "blanc", 1 et 0, «vrai» et «faux». Mais la sécurité n'est pas si simple.

Technologies de sécurité Web

Commençons la discussion sur la sécurité Web avec la technologie, à laquelle les développeurs prêtent généralement attention très tôt, disons, au tout début de leur parcours professionnel. Soit dit en passant, si vous souhaitez contourner cette méthode de protection, vous pouvez trouver une tonne d'informations sur la façon de le faire sur StackOverflow. Il s'agit de CORS.

▍CORS

Avez-vous déjà vu une telle erreur:

No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access. 

Face à cela, vous pensez que vous n'êtes certainement pas le premier avec qui cela s'est produit. Googler, vous découvrez que pour résoudre ce problème, il suffit d'installer une sorte d'extension. Eh bien, n'est-ce pas merveilleux? Cependant, la technologie CORS (Cross-Origin Resource Sharing, partage de ressources entre différentes sources) n'existe pas pour interférer avec les développeurs, mais pour protéger leurs projets.

Afin de comprendre comment CORS protège les projets Web, nous parlerons d'abord des cookies, en particulier des cookies utilisés pour authentifier les utilisateurs. Ces cookies sont utilisés lorsque vous travaillez avec une certaine ressource Web afin d'informer le serveur que l'utilisateur est connecté. Ils sont automatiquement envoyés avec des requêtes en cours d'exécution sur le serveur correspondant.

Supposons que vous soyez connecté à votre compte Facebook et que Facebook utilise des cookies d'authentification. En travaillant sur Internet, vous cliquez sur le lien bit.ly/r43nugi , vous êtes redirigé vers un site Web malveillant, disons quelque chose comme superevilwebsite.rocks . Le script téléchargé avec la page de ce site effectue une demande client sur facebook.com aide de votre cookie d'authentification.

Dans un monde sans CORS, un script de superevilwebsite.rocks pourrait secrètement apporter des modifications à votre profil FB, il pourrait voler des informations, avec toutes les conséquences qui en découlent. Dans un tel monde, une «épidémie superevilwebsite.rocks» aurait pu facilement apparaître, lorsqu'un script capturant la gestion du compte de l'utilisateur publie un lien sur sa page, en cliquant sur lequel les amis de cet utilisateur «sont eux-mêmes infectés», et à travers les liens publiés sur leurs pages, une épidémie couvre finalement tout Facebook.

Cependant, dans un monde où CORS existe, Facebook n'autoriserait que les demandes de modification des données de compte à partir de facebook.com . En d'autres termes, l'administration du site limiterait le partage des ressources entre différentes sources.

Ici, vous pouvez avoir la question suivante: "Mais superevilwebsite.rocks peut simplement changer l'en-tête source dans ses demandes et ils sembleront provenir de facebook.com?"

Un site frauduleux peut essayer de le faire, mais il n'y parviendra pas, car le navigateur ignorera un tel en-tête et utilisera des données réelles.

"Et si superevilwebsite.rocks fait une requête similaire du serveur?", Demandez-vous.

Dans une situation similaire, CORS peut être contourné, mais cela ne servira à rien, car, en exécutant une demande du serveur, il ne sera pas possible de transmettre un cookie d'authentification à Facebook. Par conséquent, le script, pour mener à bien une telle demande, doit être exécuté côté client et avoir accès aux cookies stockés sur le client.

▍CSP

Afin de comprendre ce qu'est CSP (Content Security Policy, Content Protection Policy), vous devez d'abord parler de l'une des vulnérabilités Web les plus courantes. Il s'agit de XSS (cross-site scripting, cross-site scripting).

Lors de l'exécution d'une attaque XSS, l'attaquant injecte du code JavaScript spécial dans la partie client d'un certain site. Vous pourriez penser: «Eh bien, que fera ce script? Changer les couleurs des éléments de page? "

Supposons que quelqu'un ait réussi à intégrer son script JS dans les pages du site que vous visitez. Que pourrait faire un script similaire? En fait, beaucoup de choses:

• Il peut faire des requêtes HTTP à d'autres sites, en faisant semblant que vous les faites.
• Il peut vous rediriger vers un site qui ressemble exactement à celui auquel vous êtes connecté, mais qui est conçu, par exemple, pour voler des informations d'identification.
• Il est capable d'ajouter des balises <script> aux pages qui contiennent du code JavaScript ou sont conçues pour charger une sorte de fichiers JS.
• Il peut ajouter un élément <iframe> à la page, qui, par exemple, ressemblera exactement aux champs pour entrer le nom et le mot de passe pour entrer dans le site. Dans ce cas, ces champs de saisie de ces données seront masqués.

En fait, les possibilités qui s'ouvrent à un attaquant pour réussir à exécuter une attaque XSS sont infinies.

La stratégie de protection du contenu tente d'empêcher cela en appliquant les restrictions suivantes:

• Limitations sur ce qui peut être ouvert dans un <iframe> .
• Limitations sur lesquelles les feuilles de style peuvent être chargées.
• Limitations des requêtes pouvant être effectuées.

Comment fonctionne le CSP?

Lorsque vous cliquez sur le lien ou entrez l'URL du site Web dans la barre d'adresse du navigateur, le navigateur effectue une demande GET. La demande est envoyée au serveur, qui transmet du code HTML au navigateur avec les en-têtes HTTP. Si vous souhaitez consulter ces rubriques, ouvrez l'onglet Réseau dans les outils de développement du navigateur et visitez plusieurs sites. L'en-tête de réponse peut ressembler à ceci:

 content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm; 

Ceci est la politique de sécurité du contenu facebook.com . Convertissez-le en un aspect plus lisible:

 content-security-policy: default-src * data: blob:; script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self'; style-src data: blob: 'unsafe-inline' *; connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm; 

Considérez les directives CSP présentées ici:

• default-src - interdit tout ce qui n'est pas défini explicitement.
• script-src - introduit des restrictions sur les scripts téléchargeables.
• style-src - impose des restrictions sur les feuilles de style chargées.
• connect-src - introduit des restrictions sur les URL à partir desquelles les ressources peuvent être chargées à l'aide d'interfaces de script, telles que fetch , XHR , ajax , etc.

Notez qu'en fait, il existe de nombreuses directives de ce type. Le navigateur lit l'en-tête CSP et applique les règles appropriées dans le fichier HTML chargé. Des directives correctement configurées autorisent uniquement les actions nécessaires au bon fonctionnement de la page.

Si la page n'a pas d'en-tête CSP, aucune interdiction ne s'applique. Les caractères * dans l'en-tête CSP sont des caractères génériques. Un tel signe peut être remplacé par n'importe quoi, et ce qui se passera sera autorisé.

▍HTTPS

Vous avez sûrement entendu parler de HTTPS (HTTP Secure). Peut-être avez-vous rencontré quelque chose comme ceci: "Pourquoi devrais-je m'inquiéter de HTTPS si je joue à un jeu sur le site?" Ou peut-être avez-vous eu l'idée suivante: «Si vous n'avez pas de HTTPS, alors c'est tout simplement fou. Dans la cour 2018 année! Ne croyez pas que quiconque dit que HTTPS peut être dispensé. »

Vous avez peut-être entendu dire que Chrome marque désormais le site comme dangereux s'il n'utilise pas HTTPS.

La principale différence entre HTTPS et HTTP est que, lors de la transmission de données via HTTPS, elles sont cryptées, mais lors de la transmission via HTTP, elles ne le sont pas.

Pourquoi vaut-il la peine de prêter attention lors du transfert de données précieuses? Le fait est que lors de l'organisation de l'échange de données via un canal de communication non sécurisé, il existe la possibilité d'une attaque MITM (Man In The Middle, une attaque intermédiaire ou un homme au milieu).

Si vous, assis dans un café, accédez à Internet via un point d'accès Wi-Fi ouvert, quelqu'un, tout simplement, peut prétendre être un routeur par lequel passent toutes vos demandes et réponses. Si vos données ne sont pas cryptées, l'intermédiaire peut en faire ce qu'il veut. Dites qu'il peut modifier le code HTML, CSS ou JavaScript avant qu'il n'arrive du serveur dans votre navigateur. Compte tenu de ce que nous savons déjà sur les attaques XSS, vous pouvez imaginer quelles pourraient être les conséquences.

"Comment est-ce possible: mon ordinateur et mon serveur savent chiffrer et déchiffrer les données que nous échangeons, mais pas l’intermédiaire malveillant?", Demandez-vous. Ceci est possible grâce à l'utilisation du protocole SSL (Secure Sockets Layer) et du protocole TLS (Transport Layer Security) plus récent. TLS a remplacé SSL en 1999 en tant que technologie de cryptage utilisée dans HTTPS. Une discussion sur les fonctionnalités TLS dépasse le cadre de cet article.

▍HSTS

La technologie HSTS (HTTP Strict-Transport-Security, le mécanisme d'activation forcée d'une connexion sécurisée via le protocole HTTPS) est assez simple. Par exemple, considérons à nouveau l'en-tête Facebook correspondant:

 strict-transport-security: max-age=15552000; preload 

Analysons-le:

• max-age définit la durée pendant laquelle le navigateur doit obliger l'utilisateur à travailler avec le site Web via HTTPS.
• preload - pour nos besoins, ce n'est pas important.

Cet en-tête ne s'applique que si vous accédez au site via HTTPS. Si vous travaillez avec le site via HTTP, cet en-tête est ignoré. La raison en est assez simple: la communication HTTP est si faible qu'un tel en-tête n'est pas fiable.

Reprenons l'exemple de Facebook pour démontrer l'utilité pratique du mécanisme HSTS. Supposons que vous vous connectiez à facebook.com pour la première fois et que vous savez que HTTPS est plus sûr que HTTP, vous utilisez donc ce lien: https://facebook.com . Lorsque votre navigateur reçoit le code HTML, il reçoit également un en-tête qui indique au navigateur qu'il doit vous forcer à passer en HTTPS lors de futures demandes. Après un mois, quelqu'un vous envoie un lien HTTP vers Facebook, http://facebook.com , et vous cliquez dessus. Comme le mois est inférieur à la période de 15552000 secondes spécifiée par la directive max-age , le navigateur enverra une demande via HTTPS, empêchant une éventuelle attaque MITM.

Résumé

Aujourd'hui, nous avons discuté de certaines technologies universellement utilisées pour assurer la sécurité des projets Web. Nous pensons que les questions de sécurité sont très importantes, car elles concernent absolument tous ceux qui sont connectés à Internet. Le sujet de la sécurité Web est énorme, vous ne pouvez donc pas dire qu'après avoir lu plusieurs articles, quelqu'un deviendra un expert dans ce domaine ou au moins en apprendra suffisamment pour protéger efficacement votre projet Web ou vos données personnelles. Mais, comme dans tout autre domaine, les connaissances dans le domaine de la sécurité, s'il y a un désir de les recevoir, s'accumulent et leur quantité se transforme progressivement en qualité. Nous espérons que ce matériel a contribué à votre connaissance de la sécurité Web.

Chers lecteurs! Avez-vous rencontré des problèmes de sécurité incohérents de la part des développeurs Web?