Ce que les clients d'un site web devraient aussi savoir — Utiliser le guide de l'IPA « Comment créer un site web sécurisé » comme checklist

Interrogée sur « la sécurité de notre site web, est-ce que ça va ? », peu d’entreprises peuvent répondre « oui » avec de véritables arguments à l’appui.

On croit souvent que tout va bien parce qu’on en a confié la réalisation à un prestataire, ou qu’un site de simple présentation d’entreprise n’intéresse pas les attaquants. Mais dès qu’il existe un seul formulaire de contact, un programme traite les données saisies, et si vous utilisez un CMS comme WordPress, l’écran d’administration comme les extensions constituent des surfaces d’attaque. Qui plus est, la plupart des attaques ne visent pas une entreprise en particulier : elles recherchent mécaniquement les sites les plus fragiles.

Alors, sur quels critères vérifier que « tout va bien » ? La référence officielle utilisée de longue date à cet effet est le document Comment créer un site web sécurisé de l’IPA (Information-technology Promotion Agency, agence japonaise de promotion des technologies de l’information).

Cet article présente ce que nous enseigne ce document, dans un langage accessible aussi bien au client qui passe commande d’un site web qu’à celui qui l’exploite.

1. L’essentiel en bref

• « Comment créer un site web sécurisé » est un document qui rassemble, à partir des vulnérabilités réellement signalées à l’IPA, 11 catégories de faiblesses des sites web et leurs contre-mesures. Il est utile non seulement aux développeurs, mais aussi comme référence pour la commande et la recette
• Les contre-mesures se répartissent entre « solution fondamentale » (qui élimine la cause) et « mesure de secours » (qui atténue les dégâts). La base est la solution fondamentale, à laquelle s’ajoutent les mesures de secours
• La « checklist de mise en œuvre de la sécurité » fournie peut être utilisée telle quelle comme liste de vérification lors de la commande auprès d’un prestataire et lors de la recette
• Le volume complémentaire « Spécification du bilan de santé d’un site web » sert de référence pour les points de contrôle lors de l’inspection périodique d’un site en exploitation
• Dans la pratique d’un site d’entreprise, les deux principaux risques concernent les parties qui reçoivent des saisies (formulaires, etc.) et l’exploitation du CMS (WordPress, etc.). Il convient de définir, dès la commande, une organisation d’exploitation qui ne s’arrête pas une fois le site livré

2. Qu’est-ce que « Comment créer un site web sécurisé » ?

« Comment créer un site web sécurisé » est un document que l’IPA a compilé à l’intention des développeurs et exploitants de sites web, en retenant, parmi les informations relatives aux vulnérabilités qui lui ont été signalées, celles qui ont fait l’objet du plus grand nombre de signalements ou dont l’impact est le plus important en cas d’attaque, ainsi que les contre-mesures correspondantes. La version actuelle est la 7e édition révisée, publiée en mars 2021, et compte 115 pages au total. Outre le PDF, une page HTML est également publiée pour chaque vulnérabilité.

Il se compose de trois chapitres.

Par ailleurs, les documents suivants sont publiés indépendamment du corps principal.

• Checklist de mise en œuvre de la sécurité (format Excel) : un tableau permettant de vérifier si les contre-mesures du document principal ont été mises en œuvre
• Volume complémentaire « Comment appeler SQL en toute sécurité » : un document approfondissant les contre-mesures liées aux vulnérabilités autour des bases de données
• Volume complémentaire « Spécification du bilan de santé d’un site web » : une spécification regroupant 13 points de diagnostic pour évaluer un site en exploitation

Tous ces documents peuvent être téléchargés gratuitement depuis la page de l’IPA.

3. Lire les 11 vulnérabilités sous l’angle de « ce qui se produit »

Les 11 catégories de vulnérabilités traitées au chapitre 1 sont énoncées avec un vocabulaire technique destiné aux développeurs, mais si on les reformule en « ce qui se produit sur son propre site si on laisse faire », on comprend qu’elles ne concernent pas uniquement le prestataire, même du point de vue du client qui passe commande.

Par exemple, « l’injection d’en-têtes de courriel » s’applique directement au formulaire de contact d’un simple site de présentation d’entreprise. Un formulaire mal protégé est détourné comme source de spams, ce qui nuit même à la réputation du domaine de l’entreprise (la question de savoir si ses courriels parviennent réellement à leurs destinataires). Comme évoqué dans Pourquoi les courriels du formulaire de contact ne sont pas délivrés, un formulaire dont les courriels cessent d’arriver se traduit directement par une perte d’opportunités commerciales.

4. « Solution fondamentale » et « mesure de secours » — comment penser les contre-mesures

Ce qui fait la force de ce document, c’est qu’il présente les contre-mesures selon deux catégories.

• Solution fondamentale : une mise en œuvre qui élimine la cause même de la vulnérabilité. Pour l’injection SQL, par exemple, construire les requêtes SQL avec des marqueurs de position plutôt que par concaténation de chaînes
• Mesure de secours : une contre-mesure qui réduit le taux de réussite ou l’impact d’une attaque lorsqu’une vulnérabilité subsiste. Par exemple, ne pas afficher tel quel un message d’erreur dans le navigateur

Cette distinction donne au client un repère pour évaluer les explications qu’on lui fournit sur la sécurité. Une explication du type « nous mettons en place un WAF (un dispositif qui détecte et bloque les attaques), vous pouvez être rassuré » relève de la mesure de secours : ce n’est pas un substitut à une solution fondamentale au niveau de l’application elle-même. À l’inverse, mettre en œuvre une solution fondamentale puis y superposer un WAF constitue une architecture cohérente. Le simple fait de distinguer de quel niveau on parle permet déjà de mieux juger de la pertinence d’une proposition.

5. Comment l’utiliser lors de la commande et de la recette

« Comment créer un site web sécurisé » est un document destiné aux développeurs, mais son intérêt pratique pour le client est qu’il peut servir de référence pour formuler des exigences et effectuer des vérifications.

• Au stade du devis et des exigences : ajouter au cahier des charges ou à l’appel d’offres une phrase du type « mettre en œuvre les contre-mesures pour les vulnérabilités listées dans le document IPA “Comment créer un site web sécurisé” ». Citer une référence précise rend l’exigence bien plus concrète qu’une formule vague comme « prendre en compte la sécurité »
• Au stade de la recette : demander la remise des résultats de vérification pour les points correspondants de la checklist de mise en œuvre de la sécurité
• Au stade du contrat : préciser par écrit qui assurera la mise à jour du CMS, des extensions et du serveur après la mise en ligne, et si la réponse à une vulnérabilité découverte ultérieurement relève du contrat de maintenance ou d’un devis distinct

Le troisième point est particulièrement important. La sécurité d’un site web n’est pas acquise une fois pour toutes au moment de sa construction : elle se maintient en suivant les nouvelles vulnérabilités découvertes après la mise en ligne. Cette question de « qui continue à s’en occuper » relève de la même logique que le périmètre de maintenance évoqué dans notre article sur les contrats de développement externalisé et de maintenance.

6. Faire un « bilan de santé » d’un site en exploitation

Pour un site déjà en ligne, le volume complémentaire « Spécification du bilan de santé d’un site web » est utile. Il s’agit d’une spécification regroupant des points de diagnostic (13 au total) pour vérifier la sécurité d’un site web en exploitation, qui sert aussi de repère quant au contenu à attendre d’un service de diagnostic de vulnérabilités.

Pour le site web d’une PME, dans la pratique, le risque tend à se concentrer particulièrement sur deux points.

• Les parties qui reçoivent des saisies : formulaire de contact, champ de recherche, connexion des membres, etc. La plupart des vulnérabilités du chapitre 1 concernent cet aspect
• L’exploitation du CMS : sur un site où les mises à jour du cœur, du thème ou des extensions d’un CMS comme WordPress se sont arrêtées, le scénario type est celui d’une faiblesse connue exploitée pour falsifier le site. Il est très fréquent que personne n’ait déterminé à qui incombent les mises à jour, et que le site soit tout simplement laissé à l’abandon

Si vous souhaitez repenser la charge de mise à jour du CMS en même temps que l’ensemble de l’organisation d’exploitation, notre article sur la migration depuis WordPress peut également vous être utile. Il existe aussi le choix de conception consistant à réduire d’emblée le traitement dynamique au profit d’une structure de site statique, ce qui réduit la surface d’attaque elle-même. Notre propre adoption d’une structure statique fondée sur le système de design de l’Agence numérique pour la réalisation de sites s’inscrit dans le prolongement de cette même logique.

Notons par ailleurs que l’exploitation sécurisée d’un site web figure aussi parmi les points de contrôle du self-diagnostic de la 4.0e édition des « Directives de sécurité de l’information pour les PME » de l’IPA. Pour situer ce point dans l’ensemble des mesures de sécurité d’une entreprise, consultez notre article présentant la 4.0e édition des directives.

Résumé

Récapitulons les points clés du document IPA « Comment créer un site web sécurisé ».

• Un document de référence (7e édition révisée, 115 pages) couvrant 11 catégories de faiblesses des sites web et leurs contre-mesures, fondé sur des vulnérabilités réellement signalées à l’IPA
• Les contre-mesures se répartissent en deux niveaux : solution fondamentale et mesure de secours. Une mesure de secours comme un WAF ne remplace pas une solution fondamentale
• Le client peut l’utiliser en citant nommément ce document dans ses exigences, en vérifiant la livraison à l’aide de la checklist, et en fixant contractuellement l’organisation des mises à jour après la mise en ligne
• Pour un site en exploitation, effectuer des contrôles périodiques en s’appuyant sur la « Spécification du bilan de santé d’un site web » comme référence
• Le risque réaliste pour le site d’une entreprise tend à se concentrer sur le traitement des saisies (formulaires, etc.) et sur un CMS laissé à l’abandon

La sécurité tend à se réduire à un choix binaire entre « dépenser ce que le prestataire recommande » ou « ne rien faire du tout ». Mais le simple fait de connaître des références publiques permet de formuler ses exigences et d’effectuer ses vérifications avec ses propres mots.

Vous envisagez de créer ou de refondre votre site web ?

Chez Komura Software LLC, lors de la création ou de la refonte d’un site web, nous formulons nos propositions en suivant la logique présentée dans cet article : mise en œuvre des formulaires, structure statique ne dépendant pas excessivement d’un CMS, et organisation des mises à jour après la mise en ligne. Nous pouvons également vous accompagner dès l’étape d’un simple état des lieux, si vous ne savez pas exactement où en est votre site actuel.

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Qu'est-ce que le document « Comment créer un site web sécurisé » ?

Il s'agit d'un document de sécurité publié par l'IPA (Information-technology Promotion Agency, agence japonaise de promotion des technologies de l'information), destiné aux développeurs et exploitants de sites web. Parmi les informations relatives aux vulnérabilités signalées à l'IPA, il retient celles qui ont fait l'objet du plus grand nombre de signalements ou dont l'impact potentiel est le plus important, et en explique les menaces et les contre-mesures. La 7e édition révisée, la plus récente, a été publiée en mars 2021 et compte 115 pages. Outre le document principal, une checklist de mise en œuvre de la sécurité ainsi que deux volumes complémentaires — « Comment appeler SQL en toute sécurité » et « Spécification du bilan de santé d'un site web » — sont mis à disposition gratuitement.

Un simple site vitrine de présentation d'entreprise a-t-il aussi besoin de mesures de sécurité ?

Oui. Dès qu'il existe un formulaire de contact, un programme traite les données saisies ; si vous utilisez un CMS comme WordPress, l'écran d'administration et les extensions constituent autant de surfaces d'attaque. Les attaquants ne choisissent pas nécessairement leurs cibles selon la taille de l'entreprise : ils recherchent mécaniquement les sites vulnérables et les détournent comme tremplins pour de la falsification, de la diffusion de virus ou de l'envoi de spams. Ce qui rend un site web dangereux, c'est que l'on peut être à la fois victime et, en même temps, causer du tort à ses partenaires commerciaux et à ses visiteurs.

Quelle est la différence entre une solution fondamentale et une mesure de secours ?

« Comment créer un site web sécurisé » présente les contre-mesures selon deux catégories. La solution fondamentale est une méthode de mise en œuvre qui élimine la cause même de la vulnérabilité (par exemple, utiliser des marqueurs de position plutôt que la concaténation de chaînes pour construire une requête SQL). La mesure de secours est une contre-mesure qui réduit le taux de réussite ou l'impact d'une attaque lorsqu'une vulnérabilité subsiste (par exemple, ne pas afficher tel quel un message d'erreur). Comme les mesures de secours seules laissent subsister la cause du problème, l'ordre correct consiste à considérer la solution fondamentale comme la base, et à y ajouter des mesures de secours.

Que faut-il vérifier en matière de sécurité lors de la commande auprès d'un prestataire ?

Nous recommandons de vérifier au minimum trois points dès l'étape du devis : (1) si les contre-mesures listées dans « Comment créer un site web sécurisé » sont mises en œuvre, (2) si les résultats de vérification peuvent être présentés à l'aide de la checklist de mise en œuvre de la sécurité ou d'un document équivalent, et (3) qui assurera la mise à jour du CMS et des extensions après la mise en ligne (autrement dit, si cela relève du périmètre du contrat d'exploitation et de maintenance). Ajouter des exigences de sécurité après coup entraîne souvent des reprises coûteuses ; il est donc important de les préciser par écrit avant la signature du contrat.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.