Chaque jour, de nombreux sites sont la cible d'attaques XSS, CSRF, clickjacking ou d'autres joyeusetés. Les conséquences sont souvent bénignes mais peuvent être autrement plus graves quand il s'agit de vol de données, de diffusion de malware ou de defacing de site.
Heureusement, de nouveaux mécanismes de sécurité proposés par les navigateurs Web offrent aux développeurs des moyens de (mieux) protéger leurs applications. Dans le cadre de cette présentation, nous verrons comment les mettre en œuvre progressivement et sans douleur.
_ Merci beaucoup. Je vais vous présenter comment protéger une application correctement avec la mise en place de Content Security Policy.
Je m'appelle Laurent Brunet, je suis développeur. Je travaille depuis quelque temps chez JoliCode. On peut le retrouver sur les réseaux sociaux.
Content Security Policy. CSP. Qui connaît ce concept ? Il y en a quand même pas mal. Qui l'utilise ? Super.
Pour expliquer ce que c'est, c'est une stratégie de sécurité qui va permettre d'améliorer ou d'empêcher certaines attaques. Mais ça nous permet aussi de pouvoir contrôler les ressources que nous chargeons sur notre application. Nous associons souvent les CSP à une protection contre les attaques XSS. Mais on fait vachement plus de choses.
Côté compatibilité, je vous ai envoyé sur les CSP niveau deux. Il y a trois niveaux. Le niveau un qui a été publié en 2012. Le niveau deux qui a été publié en 2015. Ça date déjà depuis pas mal de temps. Le niveau trois qui est en draft. C'est plutôt bien supporté. Il ne faut pas avoir peur de les utiliser.
Évidemment, la partie CSP trois qui est en draft, on peut utiliser des directives ou des mots-clés en production sans problème. On va le voir.
Alors, comment activer les CSP ? C'est simple. C'est un en-tête HTTP qu'on peut définir avec du nginx, du Apache. PHP, JavaScript, comme vous voulez. C'est un en-tête HTTP qui va s'appeler Content Security Policy. On lui définit une directive, des valeurs. Le tout séparé par un espace, un point-virgule. De nouvelles directives. Des valeurs séparées par des espaces.
Qu'est-ce qui va se passer ? J'ai défini une règle. J'ai une ressource qui est chargée. Cette ressource n'a pas été autorisée dans mes règles définies. Nous allons avoir une violation. C'est ce qu'on peut voir dans le navigateur. On va avoir une violation qui indique qu'il y a une ressource qui a été chargée, mais qui n'a pas été autorisée. Ça va empêcher la ressource d'être chargée.
En revanche, nous avons une version, un header qui s'appelle Content Security Policy report only, ça fait la même chose. Des directives et des valeurs séparées par des points-virgules. Il y a une violation. Si la ressource est censée ne pas être dans la liste blanche, mais elle n'est pas bloquée. C'est intéressant. Ça permet de mettre en place des CSP facilement. Si nous n'avons pas de CSP sur le site. On peut partir sur cette version qui sera plus sereine pour notre site.
Je vous ai fait un petit contenu rapide d'une mise en place d'un CSP sur plusieurs directives. Le but, c'est de ne pas comprendre toutes les directives. Il y en a beaucoup. On peut voir rapidement que nous avons des style-src, on va toucher sur tout ce qui concerne les styles. Les scripts, les images, les fonts, etc. Il y a un lien pour lisser les directives. Il y en a beaucoup. Beaucoup de mots-clés. Ce n'est pas le but de la conférence.
Le but de la conférence, ce qu'on a pu voir déjà, à quoi ça servait. Ça sert à sécuriser son site. Pour éviter certaines menaces. Nous avons vu la prise en charge. C'est plutôt bien supporté. Nous avons du CSP un jusqu'au CSP trois. Ça date de 2012. Nous sommes rassurés sur ce côté-là. Nous avons vu pour le header HTTP, nous avons une version avec la violation bloquante par le navigateur et une autre version avec une violation non bloquante. Le but, c'est de savoir : Quelle menace je peux empêcher ?
Les menaces qu'on va voir avec cette conférence. Les attaques XSS. Le clickjacking. La mise en place de protocoles sécurisés. Les attaques de type Magecart.
Les attaques XSS avec des chiffres. Toujours plus intéressant. J'ai récupéré, il y a un site Internet qui s'appelle hackerreport2021, ils ont des magazines. Ils sont des stats sur quoi travaillent les hackers. On peut voir sur ce schéma que nous sommes complètement la cible, les applications sur lesquelles nous travaillons et les sites Internet. Nous sommes à 95 %. À côté, nous pouvons voir le top 10 des attaques et la vulnérabilité. On peut voir les attaques XSS en première position. Nous sommes en augmentation par rapport à l'année dernière. Cette attaque est première depuis plusieurs années. Nous allons voir pourquoi.
Sur les attaques XSS, on va se focaliser sur la directive script-src. Nous sommes sur la partie JavaScript. Dans cet exemple, nous avons un mot-clé qui s'appelle "self". En gros, ça veut dire que je t'arrive* moi-même. Mon nom de domaine. Nous avons une liste blanche. Parce que typiquement, dans le Web, si je veux loader un module Twitter. Une étymologie, peu importe. Je veux le charger. J'ai mis en place des CSP, mais je me rends compte que j'ai autorisé Twitter de base, mais il appelle peut-être forcément d'autres scripts derrière. Je vais les ajouter dans la liste. Liste blanche. Malheureusement, la gestion de liste blanche, je n'ai pas forcément tout affiché. Nous pouvons en avoir sur certains sites, c'est énorme. On peut vite se mélanger les pinceaux. On ne sait pas trop ce qu'on fait. Ça peut devenir compliqué. En plus, durant ma première conférence en 2019, je suis tombé sur une étude de Google, en 2016, ils ont publié un article. J'ai mis le lien. Ça explique que la liste blanche aujourd'hui est cassée. Elle est contournable. Avec cette étude, ils ont montré... ils ont creusé Internet au complet. Ils ont pu identifier tous les sites auxquelles ils avaient activé les CSP. Ils se sont rendus compte que 95 % des sites qui avaient activé l'en-tête HTTP étaient contournables. Parce que c'était mal spécifié ou qu'ils avaient une attaque de Json P. sur les directives script-src.
Sur certains modules comme Twitter, il y a une terminaison Json P. On peut ajouter une balise script. Le fait qu'on ait autorisé la liste blanche, le script qui sera injecté sera lu sur notre site Internet.
Par rapport à cette étude, Google a créé un valideur CSP qu'on retrouvera à la fin de ma conférence. Nous avons juste à mettre dedans le lien de trouver tester ou les directives CSP. Ils n'ont pu identifier tous les sites auxquels en by-pass. On écrit by-pass, json P, on recommande de ne pas utiliser la liste blanche. C'est déjà cassé sur certains liens.
Ils ont inventé un mot-clé qui s'appelle strict-dynamic qu'ils ont présenté dans leur document en 2016. Il est utilisé seulement sur les scripts SRC, ça vient du CSP trois. On peut le mettre en production déjà.
Si on se souvient rapidement ce qu'on avait en liste blanche. Si je prends la version mode script, ça ne fait que ça. Ce bout de code fait exactement la même chose. Mais je suis sécurisé. Comment ça marche ? On va les décortiquer. Quand on ajoute la balise script-dynamic, ce mot-clé nous dit : autorise tout ce qui est en ligne sur nos codes. Unsafe-incline. C'est ignoré. Vous pouvez bloquer instantanément. Il va interdire le mot-clé self. On va perdre tout ce qui est HTTP et https. Et on va perdre tout ce qui est une liste blanche. En ajoutant le mot strict-dynamic, tout est bloqué. C'est bizarre. Mais ce qu'il attend, c'est une gestion de nonce ou H.
Je veux reprendre l'exemple de Twitter par rapport à cette version. Comme je le disais, quand on charge Module Twitter, derrière, on va peut-être charger d'autres domaines. Pour faire fonctionner le module. L'avantage avec strict-dynamic, si tu veux changer le fichier, derrière, il a besoin de cela. Je pars du principe que cela, tu l'autorises. Ce qu'il va changer, tu vas l'autoriser. Le fait de le faire déjà en liste blanche, on va l'ajouter, il considère que tu l'autorises de base. Ça va réduire le système de liste blanche.
Il a besoin de nonce ou de hashes. Ça permet d'autoriser un site en ligne ou en externe. Si on part sur nonce, c'est un numéro qui est censé être généré chaque fois, unique et secret. On ne peut pas l'anticiper. Si je veux rafraîchir ma page, j'ai le nom qui s'appelle random et après, ça peut être toto. On ne peut pas le prévenir. Si je prends l'exemple avec la directive. Sur chaque balise écrite, je vais mettre un attribut qui s'appelle nonce avec son numéro. Si on part sur une version PHP avec header, on le met avec le nonce et son nom. On le met dans une balise script avec son nom.
Même si la personne attaque via une liste blanche, elle va l'injecter, elle ne pourra pas attaquer. Il faut qu'elle puisse connaître le nonce. C'est la méthode la plus ultime pour se protéger sur les attaques XSS.
Sinon, c'est plus simple. On va prendre sur la partie alert, à partir du nom. Je suis parti sur du sha256, les navigateurs nous envoient seulement du sha256 en général. Le script, quand la page va voir qu'on a du CSP, je prends la balise script, le sha, est-ce que je l'ai dans mes règles ?
Si on récapitule sur la mise en place d'un mode script. C'est recommandé. Parce que les balises blanches peuvent être dépassées. Il faut mettre des nonces sur toutes nos balises écrites, ce sont des codes statiques. Ce qui est important, c'est les gestionnaires d'événements. On peut avoir du code... Le on-click sur le span.
La vraie solution serait d'avoir un span avec un ID, nous avons inscrit avec le nonce, assez basique, nous sommes bons. Si nous voulons mettre en place un script, il faut penser à réécrire cela.
Je vous disais que le mot-clé script dynamic, c'est pris en compte à partir de Firefox 52 ou Chrome 52. soit nous considérons que nous ne voulons pas aller sur d'anciens navigateurs. Nous restons sur cette première version. Nous mettons un nonce et un script dynamic. Mais si on a un navigateur plus ancien et que Safari ne prend pas en compte le mot-clé, je suis obligé de faire un mode en rétrocompatibilité. Ce n'est pas grave. Cette solution que je propose, c'est de mettre un nonce et un script dynamic. Ça va désactiver https.
On passe en CSP 2. Sur Safari. Si on a un nonce défini, le unsafe inline est dépassé. Cet attribut, je ne le prends pas en compte. Vous avez la liste blanche éventuellement.
Pour les très vieux sites, CSP1, vous restez sur du https. Vous autorisez tout le monde. Vous avez votre liste blanche. C'est si vous voulez avoir des navigateurs très récents. Je prends l'exemple sur un Framework grid layout. Si vous savez que vous voulez en faire sur votre site. Mais si vous avez certains navigateurs roulants qui sont sur cela, que vous ne pouvez pas partir sur ça. C'est selon votre site. Mais restez que sur du nonce et du hashe. c'est le plus simple. Vous éviterez tous les problèmes de liste blanche.
Nous en avons fini pour tout ce qui est attaques XSS. Nous allons partir sur du clickjacking. Je vous explique à quoi ça ressemble. Je suis tombé sur un article de Google. Il y a un petit GIF sympathique. Nous allons avoir uniframe. C'est qu'en opacité. On veut cliquer sur une vidéo, on se retrouve sur un site malveillant qui est désigné similaire. Mais ce n'est plus sécurisé. C'est du clickjacking.
Comment éviter cela ? Nous avons HTTP qu'on prénomme X-Frame option. Nous avons Deny ou SAMEORIGIN. J'autorise tout ou j'autorise moi-même. Nous avons une directive CSP qui s'appelle frame-ancestors. Nous avons la version None où on refuse tout. Self, j'autorise chez moi. Ça évite que malencontreusement, j'aie une eFrame avec une URL que je ne connais pas. Elle est bloquée. Violation. C'est simple.
On va entrer dans la simplicité.
Les protocoles simplifiés. On peut définir avec les CSP. Une directive pour les images. On peut définir des protocoles sécurisés. Mon premier exemple. Https. Il n'y a pas de guillemets. C'est https : le mot-clé. En mettant cette configuration, j'autorise tout ce qui est sur mon site à avoir des images en https. Si pour le test, je mets une image en https, elle sera bloquée. Violation.
Le deuxième exemple, c'est une recommandation. N'hésitez pas à partir sur default-src, c'est une directive quand vous n'avez pas défini d'autres directives, on fallback sur cette directive. Si je prends l'exemple des deux, si j'ai default-src et image-src, tout ce qui concerne les autres directives, je passe sur mon nom de domaine. Je suis sur le protocole sécurisé. Je suis obligé de redéfinir https pour une image. On ne conserve pas ce qu'il y a dans le default-src.
Mais malheureusement, sur cette partie, c'est dommage. Je me dis : J'ai des images, j'en ai oublié quelques-unes. Ça m'embête que mes images soient bloquées. Ce n'est pas grave, nous avons une directive en CSP qui s'appelle upgrade secure request. Il n'y a pas de value. C'est magique. Si j'ai mon image, qui n'est pas en https, elle est dans mon site avant même de faire la requête, il voit qu'elle n'est pas en https, mais j'ai mis cette directive, il va la mettre en https. N'hésitez pas à le mettre. Si vous voulez identifier les requêtes non sécurisées, typiquement, selon mon premier exemple, j'ai mon Content Security Policy qui dit de rediriger tout en https.
La deuxième ligne, c'est sur du report only : tu concernes https, mais tu ne peux pas la redirection. J'ajoute une direction qui s'appelle report query. Ce que ça fait, sur mon site en prod, ça va rediriger tout. Je veux les identifier. Le fait d'avoir un report only, ça va faire la violation. Mais ça va faire un reporting, ça va m'envoyer des données sur cette URL.
Ce que nous avons de report URI, nous allons parler de reporting. Nous ne voulons pas toujours regarder les consoles log. Nous avons des outils pour identifier tout cela.
Il y a une erreur. Concrètement, nous avons une directive qui s'appelle report-uri. Dans cet exemple, on met une URL propre chez nous. On s'attend à avoir une URL qui va recevoir un poste. On récupère les données et on stocke dans une base de données. Ou on part sur des sites qui peuvent récupérer les informations. Je suis parti sur le site uri report. C'est une URL qu'ils fournissent. On va renvoyer un poste sur cette URL. Je vais avoir des données au fur et à mesure. Malheureusement, cette directive report-uri est obsolète. Mais nos navigateurs ne se mettent pas encore à la page. Ils recommandent de le mettre. On devrait utiliser la consigne report 2.
J'ai un deuxième exemple. Report 2 default. Nous avons max_age. Endpoints avec la même URL. Ça va déjà fallback sur le report 2. Si vous voyez les deux des fois, c'est normal. C'est une recommandation de la documentation.
J'ai pu tester... quelques applications. J'ai déjà testé chez moi les données, les récupérer, les stocker. C'est beaucoup de bruit. Quand vous avez cinq violations sur le site, vous rafraîchissez, vous en avez cinq. Vous rafraîchissez, vous enlevez cinq ! Ça va très vite. Ça fait beaucoup de bruit. Il faut abréger les données selon le navigateur. Je me suis dit : quand même. Il y a sans doute des outils et des gens qui ont développé des choses pour pouvoir gérer cela. J'en ai trouvé quelques-uns que je vais vous présenter. Il y a report-uri. C'est pas mal. La personne qui gère cela est très ciblée dans ce domaine. Il le connaît très bien, il fait des conférences, des articles. C'est sympathique. C'est le seul qui est gratuit. De 10 000 reportings par mois.
J'ai pu tester uri-port. C'était en beta quand je l'ai testé. C'est un plan payant maintenant. Je vais mettre ma carte bleue. Mais c'est assez similaire. Ce sont des graphiques. Il y a plein d'outils qui existent pour pouvoir gérer cela à notre place.
J'ai aussi découvert un nouveau. En 2019, il n'existait pas. Ils sont arrivés en début 2020. Csper.io. Ça ressemble à Casper. C'est un logo de fantôme. C'est un plan gratuit de 14 jours. On part sur 100 000 reportings par mois. 50 $ par mois. C'est bien si on veut tester rapidement un site client. Nous n'avons pas forcément l'outil. La possibilité d'avoir un plan gratuit. J'ai laissé le report-uri en premier. Même si on part sur du 100 000, il reste moins cher sur la facturation. Mais nous pouvons aussi utiliser d'autres outils. Sentry, ça marche très bien. Ça fait des logs sur la partie CSP. C'est bien documenté et facile à mettre en place. Datadog aussi le fait. Raygun. Je ne connais pas le reporting sur ces outils. Les autres, ce sont des outils spécifiques à cela. Pour les trois derniers, je n'en sais pas plus. Peut-être que vous en savez plus.
Nous avons quand même pas mal d'outils sur le sujet. C'est plutôt cool.
Alors, sur la partie magecart. Qui connaît magecart ? Je suis content.
Il y a un autre nom. Et maintenant, on l'appelle magecart. C'est du formjacking. Mais qu'est-ce que c'est ? Si vous tapez cela sur Internet, il y a pas mal de résultats. C'est une attaque qui date de 2018. C'est récent, mais encore d'actualité. C'est un groupe de hackers qui s'appellent magecart. Ils ont un peu d'humour. Potentiellement, ils ont ciblé Majento. Sur le formjacking, ils sont axés sur la partie panier. La carte bleue. Nous allons nous appeler Magecart. C'est vraiment devenu le type d'attaque. On récupère des données de formulaires qu'on va stocker dans un autre serveur malveillant. Les données bancaires. C'est le type d'attaque Magecart.
Ils sont plutôt forts. J'ai donné plein d'exemples, si on prend l'exemple du site cigarpage.com, ils ont fait défaut domaine. Plutôt que d'utiliser les scripts, ils ont utilisé... ils ont changé le "g" avec le "q". Ils ont pu récupérer beaucoup de sites. La première attaque qui date de 2018. Il y a une grosse compagnie qui s'était fait attaquer. Une compagnie aérienne. British Airways. C'est une compagnie de vols aériens. Ils se sont fait voler 400 000 comptes clients de cartes bancaires. Ils ont été attaqués, la compagnie a été attaquée au tribunal, elle a une amende de 230 millions de livres sterling dans le cadre du RGPD. Ça s'est réglé à 20 millions de livres sterling. Ça a fait le buzz. Recherche sur ce sujet, j'ai découvert cela en 2019, quand j'ai commencé à bosser sur mon ancienne conf, je n'étais pas assez bien pour pouvoir la composer. Et j'ai cherché. Il y a énormément d'attaques. Quand ils sont découverts, l'agence, ils changent. Ils vont voir d'autres trucs. Il y a toute une liste de la version 2019. 2020. En préparant cette conf, j'ai même vu un poste du FBI qui recommande de faire attention et de mettre de la sécurité sur votre site. Il y a des solutions. Vous allez voir, il y a une seule solution pour éviter cela, c'est bête de ne pas le faire. Le problème, c'est qu'on a pu voir juste avant qu'on utilise peu les CSP. Ou on les utilise mal. Comme l'étude de Google en 18, 95 % de ceux qui sont mis en place sont bypassés. C'est dommage.
J'ai pu récupérer ce qu'ils ont fait. C'est intéressant. C'est 20 lignes de code. Pas plus. L'incident de la compagnie aérienne, ils ont attaqué la bibliothèque modernizer. Ils ont injecté 20 lignes de code. Ils récupèrent les données du formulaire. Tous les sites sont faits pareils. les mêmes ID. Ils ont récupéré cela. Ils font un appel ajax et ils envoient sur le faux nom de domaine. Ça se ressemble. C'est un truc sur le paiement. OK. On ne fait pas spécialement attention. Ils ont fait ça sur tous les sites. Vous taperez sur Internet. Vous verrez. Ils ont changé et ça marche pas.
Comme nous ne sommes pas des lapins de trois semaines, je vais vous montrer comment éviter ce genre d'attaques.
Il y a une directive qui s'appelle connect SRC. Restreindre les URL qui utilisent les API. Fetch, WebSocket, etc. Je vous recommande d'utiliser ces directives. Pour ce type d'attaque. Ce serait dommage. Je ne sais pas comment ça se gère pour les sites. La personne qui a fait le site ? Je n'imagine pas. C'est simple. La première directive : tu bloques tous les appels Ajax. Nous n'avons pas du tout d'appels Ajax sur le site. Nous pouvons en avoir, ce n'est pas grave. Tu autorises. On peut en avoir sur du paiement en Ajax, les mettre en liste blanche. Si on fait cela, notre exemple qu'on vient d'avoir, le nom de domaine qu'on ne connaît pas, qu'est-ce qu'on en fait ? Il y a un appel Ajax, il n'est pas dans la liste blanche. Reporting, et on voit qu'il y a 400 000 violations sur le sujet. Mais vous êtes protégés. Il n'y a pas de perte de données.
Sur Twitter, car il y a eu ce type d'attaque, plein de gens disaient : je ne comprends pas, si on peut éviter cela avec le CSP, pourquoi on ne les utilise pas ?
Je suis vachement en avance. J'espère que vous avez plein de questions.
Un petit récapitulatif. Vous ne connaissez peut-être pas les CSP. Je vous ai peut-être peur. On me dit : J'ai peur de casser la prod. Je peux comprendre. Mais ce sont des ressources que vous bloquez. Vous pouvez rapidement le changer. C'est un header à modifier. C'est instantané. Je préfère casser la prod sur une ressource plutôt que d'avoir des trucs d'attaque qu'on a vus qui peuvent être basiques à réduire pour le coup. Utiliser Content Security Policy report only. Utilisez report-uri et report-to. Utilisez strict-dynamic.Avec les listes blanches, je récupère les sites et je regarde ceux qui peuvent avoir du CSP. C'est bypassé de partout. C'est peu connu. C'est facile à mettre en place. Je l'ai mis sur le site en production. Ça marche bien. Utilisez des nonces cdh. Vous le faites une fois, vous avez une fonction à faire, c'est tout. Activez les protocoles sécurisés. C'est con, mais vous obligez, on a vu qu'on pouvait les identifier. On peut avoir des ressources. Pas en https. Mais on peut avoir la ressource qui va bien. On peut checker tout ce qui n'est pas en https. N'hésitez pas à le mettre. Sur la partie clickjacking, il y a un seul mot-clé à mettre. Ça marche. Évitez l'écrémage de données de carte bancaire. Connect-src. Nous sommes en 2022. Ils font encore ce type d'attaque et ça marche. C'est dommage. C'est un mot-clé à mettre.
Évidemment, le but de ma conf, c'était de ne pas lister et de ne pas parler de chaque directive. Nous en avons énormément. CSP1 de 2012. Jusqu'à CSP3. Il y a beaucoup de directives. Je n'ai pas tout affiché. Il y a des trucs sympas. Les CSP ont l'air de faire peur, mais c'est sympa. Une fois qu'on l'a mis, on est plus sécurisé. On se sent mieux.
Merci beaucoup de votre attention, j'espère que vous avez apprécié cette présentation, vous pouvez me retrouver sur Twitter ou github. J'ai mis des liens de choses sur lesquelles j'ai travaillé. Csp.withgoogle.com. N'hésitez pas à commenter si vous avez aimé cette conférence. Si vous avez des questions. S'il y a des choses que vous auriez voulu apprendre sur un domaine spécifique. Je serais peut-être ravi de donner une conf sur cela. N'hésitez pas. C'est toujours intéressant d'avoir votre retour sur ce sujet. Merci beaucoup.
(applaudissements)
_ Nous avons du temps pour une question.
_ Merci pour ta conf. Je ne connaissais pas du tout. C'était bien expliqué. J'ai une question. Nous avons l'impression que c'est des choses que tout le monde devrait faire, qui sont dans les bonnes pratiques. Est-ce que tu connais des sites qui répertorient ce genre de bonnes pratiques ? CSP ou d'autres politiques ? Ce que fait Opquast ?
_ Malheureusement, il y a beaucoup la doc de Mozilla. C'est W3C. C'est eux qui publient. Nous sommes très peu informés. Je ne sais pas si c'est l'infogérance qui doit gérer cela ou les DEV. C'est un sujet important. Il y a des trucs assez simples à mettre. C'est dommage que nous ne sommes pas assez sensibilisés sur le sujet.
_ Merci beaucoup. N'hésitez pas à aller sur Open Feedback pour donner vos remarques. Vous pouvez passer à la pause. Merci beaucoup.
(applaudissements)
Tweets