Sécuriser le Web (et aller de l’avant)

Nous avons pris l’habitude d’attendre un niveau raisonnable de protection de la vie privée et de sécurité lorsque nous utilisons des services et des applications Web. C’est parce que ces services touchent à tous les aspects de notre quotidien : l’argent et les finances, nos interactions avec les services publics, notre éducation ou celle de nos enfants, nos échanges avec nos proches, la santé, et même le simple fait d’acheter de quoi manger. Nous avons vu les conséquences dramatiques des défaillances de sécurité, des fuites de mots de passe à grande échelle à la propagation de logiciels malveillants, de logiciels espions et de rançongiciels. Depuis quelques années, j’ai consacré une bonne partie de mon temps à la question de la protection de la vie privée des utilisateurs. Lorsque nous utilisons tous ces services, nous devons savoir que des mesures adaptées de protection de la vie privée et de sécurité sont appliquées. Au niveau le plus élémentaire, cela signifie que les connexions sont chiffrées (par exemple, avec HTTPS). Cela implique également de protéger correctement les données stockées et d’utiliser les algorithmes de sécurité et de cryptographie appropriés. 

En 2014, j’ai organisé un atelier sectoriel sur le renforcement d’Internet face à la menace de la surveillance généralisée, qui préconisait notamment le passage à HTTPS. Aujourd’hui, grâce aux efforts d’entreprises, d’organisations et de nombreuses personnes, la grande majorité du trafic Web passe par HTTPS. Cet effort collectif du secteur reconnaît que la sécurité est une condition préalable à la protection de la vie privée. Vous pouvez concevoir une application qui protège la vie privée, mais si son développement et son déploiement ne se font pas dans un environnement sécurisé — et si ses canaux de communication ne sont pas correctement protégés jusqu’à l’interface utilisateur — elle reste vulnérable aux attaques. Cette surface d’attaque est de plus en plus exploitée par des acteurs malveillants. Il suffit de regarder la récente vague d’attaques par hameçonnage, de logiciels malveillants et de rançongiciels pour constater le problème.

Au-delà du transport sécurisé

Maintenant que nous avons « réglé » (ou que nous sommes en passe de régler) le problème du transport sécurisé, quelles sont les autres surfaces d’attaque ? Côté serveur, il existe des vulnérabilités comme log4j, que des acteurs malveillants ont exploitées pour attaquer des points de terminaison d’API Java. Des vulnérabilités côté client (par exemple, les failles de script intersites) menacent les interactions avec les utilisateurs dans les applications Web. Les failles de script intersites exploitent les interactions entre l’environnement JavaScript et le modèle objet de document (DOM) du navigateur Web (ou de la vue Web dans une application empaquetée). Ces attaques côté client peuvent exposer les données privées d’un utilisateur à un attaquant, ou pire, lui permettre d’agir à sa place. Ce risque découle du fonctionnement même du Web (et de nombreuses applications). Qu’on le veuille ou non, il suffit d’un clic pour télécharger et exécuter du code provenant de n’importe quel tiers. Même si vous connaissez le tiers concerné et lui faites confiance, son code peut quand même comporter des vulnérabilités, en particulier lorsqu’il est utilisé dans le monde réel, aux côtés de code écrit par bien d’autres personnes. Et dans le cas des attaques par hameçonnage, les acteurs malveillants peuvent facilement abuser de la confiance des utilisateurs.

Chaîne d’approvisionnement logicielle

La plupart des projets logiciels s’appuient sur des dépendances. Les gestionnaires de paquets comme npm facilitent leur gestion. Dans NPM, le fichier package.json décrit votre projet, dépendances comprises. Mais comme il ne répertorie que les dépendances directes, il ne permet que partiellement d’analyser l’ensemble de la chaîne d’approvisionnement logicielle. Les développeurs n’ont pas toujours l’habitude de considérer le développement logiciel sous l’angle d’une chaîne d’approvisionnement — un concept emprunté à l’économie. (Et comme je l’ai déjà écrit, ce terme peut en agacer certains.) Vous vous demandez peut-être : « Chaque développeur logiciel doit-il désormais devenir un expert en sécurité ? » La réponse est oui, en quelque sorte. À tout le moins, les développeurs qui travaillent avec différents langages et sur l’ensemble de la pile doivent connaître les principes fondamentaux de la sécurité et commencer à se former.

Pour commencer à réfléchir à la sécurité des dépendances open source, les développeurs peuvent consulter le guide concis de l’OpenSSF pour développer des logiciels plus sécurisés. Cette liste de contrôle couvre des mesures d’hygiène élémentaires, comme s’assurer que tous les développeurs utilisent l’authentification multifacteur lorsqu’ils valident du code, ou recourir à des outils d’analyse et de surveillance des vulnérabilités qui proposent des correctifs, comme celui que Snyk fournit.

Spécifications de sécurité avancées

Un autre domaine émergent de la sécurité des applications Web est celui des API Web, qui activent des fonctionnalités avancées tout en offrant des niveaux de sécurité supplémentaires. Par exemple, la vulnérabilité « Spectre » a exposé les applications Web utilisant un SharedArrayBuffer à des attaques au niveau du processeur, susceptibles de provoquer des fuites de données entre des contextes normalement considérés comme sécurisés (inter-origines). En réponse, la communauté des standards du Web a créé les politiques cross-origin-opener-policy et cross-origin-embedder-policy. C’est un exemple parmi de nombreuses nouvelles spécifications et API élaborées à différents endroits pour renforcer la sécurité des API Web avancées et atténuer ces types d’attaques. Mais en raison de la complexité inhérente au problème et de la sophistication de certaines approches (par exemple, la configuration des en-têtes HTTP dans le cas de COOP et COEP), les développeurs connaissent encore mal ces spécifications. 

Cette citation d’un développeur, tirée de l’enquête MDN Web DNA de 2020, résume bien la situation :

Je débute peut-être encore dans le domaine du code, mais la sécurité sur Internet reste ma principale préoccupation. Personnellement, je trouve que le jargon complexe utilisé pour décrire le fonctionnement de la sécurité Web à l’heure actuelle rend l’apprentissage et la mise en œuvre des meilleures pratiques de sécurité particulièrement difficiles quand on débute en programmation, même si l’on choisit des solutions tierces.

Nous devons mieux aider les développeurs Web à mettre en œuvre les meilleures pratiques de sécurité.

Où en sommes-nous ?

Après avoir évolué à la fois dans la communauté des développeurs Web et dans celle du DevSecOps, une chose m’est apparue clairement : nous avons grand besoin de mieux communiquer. Les développeurs Web doivent adopter le discours et l’état d’esprit autour de la chaîne d’approvisionnement logicielle (et de ses dépendances), et placer l’analyse de sécurité au premier plan. La communauté des développeurs déjà sensibilisés aux enjeux de sécurité doit faire passer ce message à davantage de développeurs et s’intéresser aux risques de sécurité pour les utilisateurs finaux (comme ceux qui menacent leur vie privée), afin de mieux expliquer l’importance du DevSecOps.

Les développeurs Web doivent prendre part aux discussions sur la sécurité, et pas seulement en tant qu’utilisateurs. J’aimerais voir davantage de développeurs Web collaborer avec nous au sein de l’OpenSSF. Par exemple, dans le groupe de travail OpenSSF Best Practices, nous élaborons des recommandations de bonnes pratiques pour configurer les plateformes de gestion du code source (par exemple, GitHub et GitLab), entre autres sujets. Les cartes de score OpeSSF constituent un autre exemple : elles évaluent les aspects liés à la sécurité des dépôts open source. Les développeurs Web ont été trop peu nombreux à participer à ces discussions. Et comme cette communauté est particulièrement attentive aux questions de protection de la vie privée des utilisateurs, ces enjeux ont été moins présents dans les travaux de l’OpenSSF qu’ils ne devraient l’être, à mon avis. C’est l’une des raisons pour lesquelles j’ai contribué à organiser un atelier sectoriel afin de réunir ces communautés et de « faire avancer la sécurité du Web ».

Cet atelier ouvert au secteur se tiendra à Londres les 7 et 8 juin. Il réunira certaines de ces voix et, nous l’espérons, donnera un nouvel élan aux travaux. L’appel à propositions de l’atelier est ouvert jusqu’au 24 avril. Les développeurs Web soucieux de sécurité pourront également y participer.