Facteurs à considérer en matière de cybersécurité pour votre site Web (ITSM.60.005)

1.1 Sensibilité des données

Avant de concevoir votre site Web, vous devez déterminer les données de grande valeur et sensibles (p. ex. des renseignements personnels, financiers, essentiels aux activités ou exclusifs) pour vous assurer de mettre en œuvre dans le cadre de la conception et de l’architecture de votre site Web les mesures nécessaires pour les protéger. La sensibilité des données se mesure en faisant une évaluation qui tient compte du préjudice possible qu’une incapacité de protéger la confidentialité, l’intégrité et la disponibilité des renseignements pourrait occasionner. La confidentialité permet de protéger les renseignements contre toute divulgation non autorisée. L’intégrité permet de protéger contre toute modification non autorisée. La disponibilité permet d’assurer que les renseignements sont disponibles au besoin.

Lorsque vous classez vos données par catégories, attribuez des niveaux de sensibilité à chacun de ces trois secteurs (confidentialité, intégrité, disponibilité) pour créer un profil de sécurité des données en trois parties. La sensibilité des données est classée comme étant élevée (E), moyenne (M) ou faible (F). Par exemple, envisagez un ensemble de données qui possède un profil de sécurité des données : E/M/F. Vous pouvez interpréter les trois parties du profil de sécurité des données de manières suivantes :

• Une compromission de confidentialité des données (E) a une incidence profonde ou un impact prohibitif;
• Une compromission d’intégrité des données (M) a des répercussions importantes;
• Une compromission de disponibilité des données (F) a un impact modéré.

La classification des données est une tâche qui peut s’avérer fastidieuse. Par exemple, la sensibilité des données liées aux résultats d’une élection est plus élevée le jour de l’élection que le lendemain de celle-ci. Vous devez classifier vos données en fonction du niveau le plus élevé de préjudice qui pourrait se produire si ces données étaient compromises. Voir l’Annexe 1 du document ITSG-33 IT – La gestion des risques liés à la sécurité des TI : Une méthode axée sur le cycle de vie ^{Note de bas de page 3} pour obtenir de plus amples renseignements sur la classification et l’établissement de catégories pour vos données.

3.1 Séparation des composants des services Web

Lorsque vous concevez vos services Web, vous devez distinguer ou séparer vos composants de services Web les uns des autres. Ce faisant, vous êtes assuré que si un composant est compromis, les autres composants seront protégés. Par exemple, si un auteur de menace réussit à accéder à une partie de votre infrastructure, il ne pourra pas avoir accès aux autres composants.

Un service Web simple comporte les composants suivants : un serveur Web, une application et une base de données. Le serveur Web accepte et formate les demandes du navigateur client sur Internet, puis il achemine ces demandes vers l’application pour qu’elles soient traitées. Le serveur Web reçoit également des réponses de l’application et il les présente au navigateur client (p. ex. la couche présentation). L’application effectue le traitement principal dans le service Web, appliquant ainsi la logique métier aux demandes (p. ex. la couche application). La base de données est votre référentiel de données persistant qui héberge vos données sensibles (p. ex. la couche persistante).

Une conception simple peut permettre que tous les composants soient réunis sur un seul serveur Web. Ce concept fonctionne d’un point de vue fonctionnalité, mais il laisse vos données vulnérables face à des menaces. Si le serveur Web est compromis, et que tout est stocké sur un serveur Web, vos données sont alors également compromises. Afin de sécuriser votre architecture, utilisez des techniques comme la séparation physique (lorsque la situation le permet), des coupe-feux, des politiques en matière de sécurité et des contrôles d’accès. Si vous faites affaire avec un fournisseur de services, c’est à vous à déterminer comment ce fournisseur doit séparer les composants de services Web.

3.2 Protéger les services Web connectés à Internet

• Insérez un serveur mandataire à l’avant de vos services Web;
• Utilisez un coupe-feu d’applications Web (WAF pour Web Application Firewall), qui permet de filtrer, de surveiller et de bloquer le trafic du protocole HTTP;
• Mettez en œuvre des contrôles d’accès et des méthodes d’authentification (voir les sections 4 et sections 5);
• Surveillez et utilisez un SDI ou un IPS (voir la section 9).

3.3 Mettre en œuvre des composants redondants

Vous devriez intégrer la redondance à votre concept afin d’éviter un point unique de défaillance pour vous aider à reprendre efficacement les activités et à minimiser les répercussions lorsque survient un problème. Tous les composants matériels peuvent, à un certain moment, s’exposer à un risque de défaillance. La redondance (c.-à-d. la reproduction) est un principe architectural qui fait en sorte que des ressources multiples remplissent la même fonction. En intégrant des redondances aux composants de vos services Web, vous pouvez assurer la disponibilité des systèmes et des services, et réduire le risque de perdre des données. De plus, la redondance permet de réduire l’incidence d’attaques DoS, qui peuvent cibler des composants du Web frontal dans le but de perturber intentionnellement des services. Il vous faudrait privilégier la création de redondances pour les composants du Web frontal.

Votre plan de redondance doit d’abord être axé sur les composants du Web frontal, comme les serveurs mandataires, mais il doit aussi tenir compte des composants internes, comme les serveurs Web, les équilibreurs de charge, les bases de données et les serveurs d’applications. Si un équilibrage de charge est nécessaire, vous devez déterminer les mécanismes de distribution d’équilibrage de charge mis à votre disposition (p. ex. source IP, port source, quintuple) et vous assurer que ces mécanismes sont compatibles avec vos serveurs Web et applications.

Veillez à sauvegarder régulièrement vos données. Il ne suffit pas de créer des composants redondants et des sauvegardes; vous devez les tester rigoureusement pour vous assurer de leur bon fonctionnement.

3.4 Séparer les interfaces administratives

Vous devez séparer l’interface administrative de votre site Web. Les utilisateurs administratifs ou privilégiés ont un niveau d’accès élevé à votre réseau. Lors de l’attribution de privilèges à des utilisateurs, vous devez toujours tenir compte de l’impact que pourrait avoir la compromission de leurs comptes. Vous devez également vous prémunir d’interfaces de connexion distinctes pour séparer les utilisateurs généraux des utilisateurs administratifs ou privilégiés. Les interfaces de connexion pour les applications Web sont connectées à Internet, ce qui en fait des cibles pour les attaques. Des problèmes liés à l’interface de connexion utilisateur peuvent rapidement dégénérés si un administrateur utilise cette même interface. S’il survient un problème avec votre site Web, c’est à votre administrateur que revient la tâche de le régler.

Vous devez séparer l’interface administrateur de votre site Web. Dans le cas des environnements de travail à distance, les utilisateurs administratifs ou privilégiés doivent utiliser un réseau privé virtuel (RPV) pour se connecter et avoir accès à votre réseau.

De plus, vous devriez stocker des justificatifs utilisateur administratifs distincts des justificatifs d’utilisateur général; par exemple, dans une instance de base de données différente.

4.1 Planifier et tester les contrôles d’accès

L’accès à une application ou à un réseau nécessite une planification du contrôle d’accès. Lorsque vous définissez les contrôles d’accès, songez à appliquer le principe du droit d’accès minimal et le principe du refus par défaut. Le principe du droit d’accès minimal s’assure que les entités ont l’accès minimal dont elles ont besoin pour effectuer les tâches qui leur sont autorisées. Dans le principe du refus par défaut, les demandes sont refusées à moins que la source d’une demande ait reçu l’autorisation de votre organisation conformément à la liste autorisée.

Le contrôle d’accès est compliqué dans le cadre d’une application Web. Il y a en jeu de nombreuses couches de mécanismes lorsqu’un accès est donné aux ressources ou aux données. Les couches de contrôle d’accès de votre application Web doivent comprendre ce qui suit :

• Contrôle d’accès par URL sur le serveur Web ou la plateforme Web : Refuser certains éléments URL. Si vous désirez que l’accès à votre site Web se fasse uniquement de certains emplacements géographiques, cela peut comprendre des protections de géolocalisation.
• Système de fichier et autorisation de serveur : Pour traverser un serveur Web, une autorisation de système de fichier et une autorisation de serveur Web doivent être examinées.
• Contrôle d’accès (logique métier) à l’application : Contrôle d’accès pour définir ce que l’utilisateur peut et ne peut pas faire dans les fonctions d’application.
• Contrôle d’accès à la couche de données : Complète le contrôle d’accès à l’application en contrôlant l’accès aux éléments de la base de données.
• Contrôle d’accès à l’application (couche de présentation) : Contrôle les limites de l’application qu’un utilisateur peut afficher.

Lorsque vous concevez des contrôles d’accès pour chacune des couches, vous devez toujours tenir compte de la défense en profondeur et de l’identité ainsi que du rôle de l’utilisateur. Définissez les rôles et les fonctions que chaque rôle peut effectuer. Pour chaque fonction, vous devez être aussi précis que possible en définissant ce que les entités peuvent faire et voir (p. ex. lecture, mise à jour ou suppression de données), et ce à quoi les entités peuvent accéder dans votre base de données. Vous devez créer une matrice de contrôle d’accès qui utilise des règles ou des rôles pour lier des ressources à des objets. Par exemple, créez un tableau qui permet de distinguer les rôles administratifs, comme les administrateurs de système et les administrateurs d’application. Un tableau supplémentaire devrait être préparé pour décrire les données qui peuvent être vues. Il est essentiel de vous assurer que vos contrôles d’accès sont correctement mis en œuvre.

Assurez-vous de définir les exigences permettant de passer en revue et de mettre à jour les privilèges régulièrement (p. ex. lorsqu’un utilisateur change de rôle ou quitte l’organisation).

5.1 Établir une politique en matière de mots de passe robustes

Establish a strong password policy that includes a minimum number of characters and the expiry dates of passwords. You should not enable password hints as they make it easier for threat actors to guess passwords. We find that the following standards produce the best deterrent effect:

• les phrases passe doivent comporter au moins 4 mots et 15 caractères;
• les mots de passe doivent comporter au moins 12 caractères;
• les codes secrets et les numéros d’identification personnelle (NIP) ne doivent être utilisés que si les phrases passe et les mots de passe ne peuvent pas être utilisés.
  • Dans la mesure du possible, utilisez des NIP générés de façon aléatoire.

Assurez-vous de bien tester la mise en œuvre de vos mots de passe. Pour obtenir de plus amples renseignements sur les pratiques exemplaires en matière de mots de passe, consultez le document Pratiques exemplaires de création de phrases de passe et de mots de passe (ITSAP.30.032) ^{Note de bas de page 5}.

Les attaques de bourrage de justificatifs deviennent plus fréquentes. Lors d’une attaque de bourrage de justificatifs, des auteurs de menace se sont servis de justificatifs volés pour tenter de se connecter à d’autres sites Web et systèmes jusqu’à ce que des correspondances soient trouvées. Les attaques de bourrage de justificatifs fonctionnent parce que les gens ont tendance à réutiliser leurs mots de passe pour plusieurs sites Web.

Dans le but de protéger vos clients contre des attaques de bourrage de justificatifs, encouragez-les à ne pas réutiliser leurs mots de passe et empêchez-les d’utiliser des mots de passe qui ont déjà fait l’objet d’une fuite. Ne permettez pas aux utilisateurs d’entrer leurs adresses de courriel comme noms d’utilisateur. Lorsque vous permettez que des adresses de courriel soient utilisées comme noms d’utilisateur, vous donnez aux auteurs de menace une combinaison plausible de nom d’utilisateur et de mot de passe.

Il existe des ressources en ligne qui permettent d’identifier des mots de passe compromis, dont le site Have I Been Pwned et son service Pwned Passwords. Par l’entremise de ce service, les utilisateurs peuvent voir si certaines de leurs informations ont fait l’objet d’une atteinte à la protection des données. Ce service a été créé après que le National Institute for Standards and Technology (NIST) ait formulé des directives recommandant spécifiquement que les mots de passe fournis par l’utilisateur soient vérifiés par rapport aux atteintes à la protection des données existantes.

En raison des exigences relatives aux mots de passe qui sont de plus en plus complexes, les utilisateurs peuvent avoir de la difficulté à se rappeler de mots de passe complexes sans les écrire, ce qui pose un risque à la sécurité des mots de passe. Les sites Web utilisent de plus en plus de services de gestion des mots de passe qui proviennent de fournisseurs qui peuvent non seulement stocker et gérer les mots de passe, mais aussi générer pour les utilisateurs des mots de passe complexes. Pour avoir des conseils de sécurité sur les gestionnaires de mots de passe, consultez le document Conseils de sécurité sur les gestionnaires de mots de passe (ITSAP.30.025) ^{Note de bas de page 6}.

5.2 Permettre une authentification multifacteur

Nous recommandons fortement de permettre l’authentification multifacteur (MFA pour multi-factor authentication) pour tous les types de comptes (p. ex. administrateurs, utilisateurs). La MFA oblige les utilisateurs à avoir au moins deux facteurs d’authentification différents pour se connecter à leurs comptes. Comme l’indique notre publication, Guide sur l’authentification des utilisateurs dans les systèmes de technologie de l’information (ITSP.30.031 v3) ^{Note de bas de page 7}, il existe trois principaux types de facteurs d’authentification :

1. Quelque chose que vous savez (p. ex. un NIP, un mot de passe ou une phrase passe);
2. Quelque chose que vous avez (p. ex. un jeton d’authentification matériel, une carte intelligente);
3. Quelque chose que vous êtes (p. ex. une biométrie telle une empreinte digitale).

Remarque : On reconnaît de plus en plus le besoin de facteurs d’authentification supplémentaires pour renforcer davantage l’authentification, comme pour ce qui touche votre emplacement ou le comportement des utilisateurs (p. ex. ce que vous faites).

Il est plus facile de mettre en œuvre un facteur d’authentification de type 2 (c.-à-d. quelque chose que vous avez), parce que cette mesure n’oblige pas l’utilisateur (ou composant de navigateur) de connaître le facteur ou de s’en souvenir (p. ex. un mot de passe ou un NIP), et vous pouvez intégrer l’entrée à un formulaire HTML. Toutefois, il n’est peut-être pas possible de fournir un jeton d’authentification matériel à tous les clients du site Web. Vous pourriez plutôt émettre des jetons d’authentification à des utilisateurs ou à des administrateurs spécifiques.

Beaucoup de fournisseurs offrent des solutions propriétaires pour les jetons d’authentification multifacteur. Dans la plupart des cas, le fournisseur donne l’interface de programmation d’applications pour différents langages de réalisation de programme que le développeur intègre à l’application d’authentification. Si vous utilisez une de ces solutions, assurez-vous qu’elle emploie au moins deux des types de facteurs d’authentification énumérés ci-dessus. Vous devez également vous assurer que le fournisseur puisse prendre en charge une distribution électronique du second facteur.

L’authentification multifacteur n’est pas une solution parfaite, mais cette mesure fait en sorte que les auteurs de menace doivent travailler plus forts pour arriver à pirater un compte. Il peut arriver que des auteurs de menace s’approprient des sessions utilisateur ou compromettent plus d’un support pour faire obstacle aux mécanismes d’authentification hors bande. Toutefois, en utilisant des jetons par utilisateur et des jetons sur le point d’expirer, vous serez en mesure de limiter ou d’éliminer le laps de temps au cours duquel un auteur de menace peut se servir des identifiants de connexion ciblés.

En outre, l’authentification multifacteur ne peut empêcher les attaques de l’intercepteur. Un auteur de menace peut également envoyer un message d’hameçonnage comportant un lien vers une page de connexion frauduleuse pour inciter le destinataire à entrer ses justificatifs d’ouverture de session.

5.3 Mettre en place un processus sécuritaire de récupération de compte

Il vous faut définir un processus de récupération de compte sécuritaire. Si un client perd un ou ses deux facteurs d’authentification, ce processus de récupération lui permet de réinitialiser ses mots de passe et de se connecter à ses comptes. Vous devez mettre en œuvre de manière rigoureuse le processus de récupération de compte afin de minimiser les risques que posent les auteurs de menace qui se font passer pour des clients légitimes. Vous pouvez également aviser le client chaque fois qu’une connexion anormale se produit (p. ex. à partir d’un nouveau dispositif ou d’un nouvel emplacement).

Votre processus de reprise de compte doit comprendre au minimum les étapes suivantes :

1. Demandez à l’utilisateur de s’identifier (p. ex. nom d’utilisateur, numéro de client, adresses de courriel);
2. Posez des questions de sécurité privée;
   • Choisissez avec soin ces questions et évitez de poser des questions qui reposent sur des réponses basées sur de l’information accessible au public. Utilisez plutôt des questions ayant trait à des transactions antérieures ou à des détails sur d’autres comptes;
3. Générez un courriel contenant un lien ponctuel périssable;
   • Ce courriel fournit un deuxième facteur d’authentification en communiquant avec l’utilisateur sur un autre support;
4. Permettez à l’utilisateur d’entrer un nouveau mot de passe;
   • L’utilisateur doit respecter les exigences en matière de complexité de mot de passe;
   • L’utilisateur entre le nouveau mot de passe deux fois pour valider le changement;
5. Avisez l’utilisateur que les détails du mot de passe ou du compte ont changé.

5.4 Utiliser des mesures pour protéger les mots de passe

En plus d’une politique en matière de mots de passe robustes, vous devriez appliquer des mesures supplémentaires pour protéger les mots de passe. Lorsque les utilisateurs se connectent à votre site Web, ne permettez pas l’envoi de mots de passe en texte clair. Exigez plutôt l’utilisation du protocole HTTPS et du hachage. Vous devez revoir vos pratiques de codage pour vous assurer que les justificatifs et les clés d’interface de programmation d’applications ne puissent jamais être codés en dur dans vos services Web.

5.5 Utiliser l’autorisation de verrouillage de compte, de délais de connexion et de tests CAPTCHA

Lors d’une attaque par force brute, un auteur de menace essaie à plusieurs reprises, par tâtonnement, de se connecter jusqu’à ce qu’il trouve la bonne combinaison de justificatifs. Pour empêcher les attaques par force brute, vous ne devriez pas permettre aux utilisateurs d’utiliser leur adresse de courriel comme nom d’utilisateur (voir la sous-section 5.3). Vous devez également mettre en œuvre des contrôles de sécurité complémentaires, notamment les verrouillages de compte, les délais de connexion et les tests CAPTCHA.

Vous devez surveiller les tentatives de connexion manquées pour identifier les attaques par force brute potentielles et aviser votre administrateur de la situation le plus rapidement possible. Le recours à un coupe-feu WAF peut vous aider dans le cadre de vos activités de détection et d’intervention.

Avec la fonction de verrouillage de compte, les utilisateurs se voient fixer un nombre maximal de tentatives de connexion avant que leurs comptes soient verrouillés. Ce seuil donne aux utilisateurs ou aux auteurs de menace un nombre limité d’occasions de se connecter avant que le compte soit gelé, les forçant automatiquement à suivre la procédure de récupération de compte. Vos développeurs doivent passer en revue les mécanismes d’authentification en place. Si vous utilisez un mécanisme d’authentification de base ou condensé, vous devez le personnaliser de façon à prendre en charge le verrouillage de compte. Quelques fournisseurs offrent des serveurs d’authentification d’arrière-plan dotés d’une fonctionnalité de verrouillage de compte intégrée, dont le protocole Lightweight Directory Access Protocol (LDAP), le système d’exploitation Active Directory (AD) et le serveur SQL.

Ajoutez un délai à chaque tentative de connexion. Lors d’attaques par force brute, beaucoup d’auteurs de menace utilisent des outils automatisés. Un délai de 0,5 seconde suffit habituellement pour interrompre ses outils.

Vous devriez également ajouter un test CAPTCHA ou un mécanisme similaire pour confirmer qu’un utilisateur n’est pas un robot après un ou deux échecs de tentatives de connexion. Par exemple, un mécanisme CAPTCHA peut demander à l’utilisateur d’observer une image et d’entrer les caractères qu’il voit. Vous n’avez pas à développer ce mécanisme. Il est possible de l’acheter sur le marché et de l’intégrer à votre interface. Vous pouvez vous procurer la famille de tests CAPTCHA et contacter des fournisseurs de solutions de rechange pour discuter de la possibilité d’utiliser les mécanismes CAPTCHA.

6.1 Utiliser des boîtes à outils de gestion de session

De langages de programmation comme Hypertext Preprocessor (PHP), .NET et Active Server Pages (ASP) sont dotés de fonctions de gestion de session intégrées. Il n’est donc pas nécessaire de réinventer des mécanismes de gestion de session à moins de disposer d’un spécialiste interne qui se charge de cette tâche. L’utilisation de produits déjà établis vous permet de tester et de mettre à jour plus facilement ces mécanismes. Il est recommandé de passer en revue ces boîtes à outils pour vous assurer qu’elles répondent aux objectifs de votre application et qu’elles sont en mesure de prendre en charge d’éventuelles améliorations de service. Si vous optez pour une boîte à outils, prenez sois de consigner les configurations de sécurité pour la répétabilité.

Remarque : Étant donné que les boîtes à outils ne sont pas par nature sécurisées, vous devez suivre les directives données dans les sous-sections 6.2 à 6.6 pour sécuriser les sessions.

6.2 Utiliser des identifiants de session aléatoires qui respectent une longueur minimale

Vous devriez utiliser des identifiants de session aléatoires pour empêcher que les auteurs de menace extrapolent le prochain jeton de session. Si les jetons de session sont basés sur des valeurs séquentielles ou utilisent des données comme des horodateurs lors de leur création, ils peuvent alors être extrapolés.

Vous devriez également mettre en place une longueur minimale pour les identifiants de session afin d’empêcher les attaques par force brute. L’OWASP recommande une longueur minimale de 128 bits.

6.3 Utiliser des indicateurs de sécurité sur les témoins

Pour assurer la sécurité des témoins, utilisez les indicateurs de témoin suivants :

• Secure : L’indicateur Secure fait savoir au navigateur que ce témoin doit être envoyé uniquement dans des connexions sécurisées, comme une connexion TLS. L’utilisation du protocole TLS permet de chiffrer l’en-tête du témoin pour qu’il ne puisse pas être lu.
• HTTPOnly : L’indicateur HTTPOnly demande au navigateur de refuser d’accorder un accès au témoin à partir d’une composante JavaScript. Certaines attaques, comme le script intersites, peuvent arriver à contrôler le langage JavaScript du navigateur de la victime et à envoyer le témoin à des sites malveillants.
• SAME-SITE : L’indicateur SAME-SITE permet aux témoins d’être envoyés uniquement au même domaine d’où provenaient les témoins.

6.4 Stocker les données de témoin sur un serveur

Lors de l’authentification de l’utilisateur, votre serveur Web génère un identifiant de session qu’il envoie au navigateur de l’utilisateur. Toutes les demandes subséquentes au serveur Web seront comprises dans cette valeur, ce qui permet au serveur de reconnaître l’utilisateur sans avoir à l’authentifier à nouveau. Toutefois, beaucoup de services Web font également le suivi des sessions, y compris des préférences d’un utilisateur. Vous devrez stocker les données de session sensibles sur vos serveurs de services Web et ne stocker qu’une quantité minimale des données stockées dans le navigateur de l’utilisateur. Le navigateur d’un utilisateur est moins sécurisé. Cela est souvent dû aux vulnérabilités (p. ex. un logiciel périmé), que les auteurs de menace peuvent exploiter par des attaques XSS et CSRF. De plus, il est possible que des ordinateurs portables et des dispositifs mobiles soient volés ou perdus.

6.5 Mettre un terme aux données de session

Les auteurs de menace peuvent utiliser des données de jetons supprimés pour se faire passer pour des utilisateurs par l’entremise d’une attaque CSRF. Il est recommandé d’appliquer des mécanismes de temporisation pour limiter le laps de temps au cours duquel les auteurs de menace peuvent utiliser les justificatifs de session. De plus, il arrive que les utilisateurs ne se déconnectent pas après leurs sessions. Vous devriez mettre en œuvre un mécanisme d’expiration de session qui se produit après une période définie (p. ex. après 15 minutes) d’inactivité de la part de l’utilisateur.

6.6 Ajouter des couches d’authentification de session

Vous devriez créer des couches d’authentification de session. L’authentification n’est pas une activité unique dans les applications Web sécuritaires et modernes. Elle devrait être prise en compte au-delà de la page d’accueil et tout au long de la session au cours de laquelle l’utilisateur interagit avec l’application. Une forme d’authentification peut être effectuée à chaque demande en utilisant une combinaison de comportements de l’utilisateur, d’attributs, de minutage des demandes, d’adresses IP et de détails de navigateur pour déterminer la légitimité des demandes. Vous devriez envisager d’ajouter un mécanisme d’authentification complémentaire lorsque des fonctions à risque élevé sont effectuées, ainsi que les principes de l’authentification multifacteur qui ont été présentés à la section 5.2.

Vous devriez mettre en œuvre des jetons anti-CRSF chaque fois qu’une forme d’authentification est soumise. Vous devez également vous assurer que l’application authentifie de nouveau l’utilisateur lorsqu’il effectue des opérations à risque élevé (p. ex. des demandes de réinitialisation d’un mot de passe). Ce type d’activité permet d’atténuer les attaques XSS et CSRF. Pour obtenir de plus amples renseignements sur la validation d’entrée, consultez la section 7 ci-dessous.

7.1 Valider tôt, mais coordonner

Une pratique exemplaire veut que vous validiez les entrées le plus tôt possible dans le cadre du processus de traitement pour réduire les contraintes que doivent subir vos serveurs. Tenez compte de tous les secteurs où peut se produire une validation. Par exemple, pensez aux numéros de carte de crédit. Si vous acceptez que les numéros de carte de crédit soient une entrée, la validation débute au navigateur de l’utilisateur, au lieu d’attendre l’application de la logique métier (comme une longueur prévue). La validation à partir du navigateur de l’utilisateur évite qu’un bruit inutile passe par votre infrastructure Web. Toutefois, la validation au niveau du navigateur de l’utilisateur est limitée, et elle peut être contournée du côté de l’utilisateur.

Vous devriez compléter la validation du navigateur à l’aide de méthodes de validations plus fortes. Par exemple, le filtrage fournit un complément flexible permettant d’ignorer les demandes non valides. Règle générale, la validation de l’application Web est plus sécuritaire. Vous devriez valider la partie frontale (comme un formulaire) et la partie en arrière-plan (comme les données transmises par un service), et surtout, ne vous fiez pas uniquement à un de ces deux éléments.

7.2 Confirmer les longueurs d’entrée prévues

Le dépassement de la mémoire tampon se produit lorsque les entrées pour une fonction dépassent la mémoire tampon allouée pour les données, ce qui affecte de façon imprévue l’application Web. Vos services Web peuvent également s’en ressentir par une exposition potentielle de données sensibles. Consultez le référentiel National Vulnerability Database du NIST pour obtenir de plus amples renseignements dans la section CVE-2014-0160 Detail ^{Note de bas de page 10}, qui décrit l’exposition à la vulnérabilité Heartbleed découverte en 2014.

Vous pouvez minimiser le dépassement de la mémoire tampon en imposant des limites d’entrée conformes aux longueurs d’entrée prévues et à la capacité de la mémoire tampon. Testez la prévention du dépassement de la mémoire tampon à l’exécution ou dans le cadre des révisions de code. Assurez-vous que votre application Web est en mesure de bien prendre en charge le dépassement de la mémoire tampon et qu’aucune modification inattendue ne se produit dans la base de données. Vous pouvez également utiliser les langages Java, Perl et PHP, qui sont dotés de protections intégrées contre le dépassement de la mémoire tampon.

7.3 S’assurer que le code de validation est central

La validation d’entrée est courante et peut se produire presque n’importe où dans votre code. Ainsi, cette validation peut s’avérer passablement difficile à tester efficacement. Centralisez votre code de validation dans les fonctions au lieu de l’éparpiller sur l’ensemble du code. Identifiez clairement dans votre code l’endroit où se produit la validation. Ceci permet de réutiliser la validation d’entrée pour des entrées semblables et de faciliter une analyse efficace de votre code. Cette précision doit se faire à même vos normes de codage, avant que ne débute le développement. Il faut en outre que les révisions de code vérifient l’efficacité de la validation d’entrée.

7.4 Restreindre le format des entrées autant que possible

Dans un champ à structure libre, l’utilisateur peut entrer le texte qu’il désire. Ce type d’entrée nécessite la validation d’entrée la plus complexe en raison du risque accru de voir un élément malveillant s’infiltrer. Pour éviter ce risque, vous devriez limiter le plus possible le format et restreindre les entrées client à structure libre lorsque cela est possible. Utilisez plutôt, si vous le pouvez, des champs à options limitées, comme des listes déroulantes, des boutons radio ou des cases à cocher, qui sont plus faciles à tester. Ne demandez pas les mêmes données plus d’une fois. Confirmez les entrées pour vous assurer d’obtenir le type d’entrée prévue.

7.5 Filtrer les caractères spéciaux

Le filtrage de combinaisons de caractères spéciaux peut permettre de vous protéger contre différents types de cybermenaces et d’attaques, comme l’injection d’entrées malveillantes. Lorsque cela est possible, utilisez les cadres et les bibliothèques qui existent depuis un certain temps et auxquels la communauté a contribué, au lieu de créer des filtres à partir de rien.

L’injection de ligne de commande d’un système d’exploitation se produit lorsque des applications permettent aux utilisateurs d’envoyer des arguments de ligne de commande dans le système d’exploitation avec des privilèges de service. Cette façon de faire est particulièrement risquée étant donné que les auteurs de menace peuvent utiliser une injection de code de système d’exploitation malveillante pour élever les privilèges ou mener des attaques DoS. Afin d’atténuer cette attaque, vous devez valider les contraintes d’entrée en bloquant des caractères spéciaux comme les points-virgules (;), les barres obliques (/), les barres verticales (|) et les mots-clés d’application ou de base de données.

Lors d’attaques par injection d’en-tête HTTP, l’utilisateur de l’application est ciblé contrairement à l’application Web elle-même. Lorsque l’utilisateur se connecte à l’application Web, la réponse HTTP réagit en fonction de qui est l’utilisateur. Par exemple, lors d’une connexion à un site bancaire, la réponse HTTP accepte les entrées comme l’ID utilisateur, et redirige celui-ci vers une page déterminée qui contient ses renseignements bancaires. Toutefois, un auteur de menace peut se servir de caractères spéciaux pour créer de nouveaux éléments en-têtes, qui peuvent être utilisés pour usurper les témoins d’un utilisateur ou rediriger cet utilisateur vers un site non valide. Ce moyen est souvent utilisé pour faciliter les attaques XSS et CSRF. Afin d’atténuer ce type d’attaque, vous devriez valider les contraintes d’entrée en bloquant les caractères spéciaux, comme « \r » « \n » et d’autres commandes d’édition d’en-tête HTTP.

L’injection de code SQL se produit lorsqu’un auteur de menace ajoute un code SQL dans le champ d’entrée pour afficher ou modifier des données de la base de données. Grâce à cette méthode d’attaque, un auteur de menace peut modifier ou détruire une base de données. L’auteur de menace n’a besoin que de compétences SQL de base pour exécuter l’attaque. Pour atténuer ce type d’attaque, il vous faut bloquer les mécanismes d’échappement (p. ex. les guillemets ou les guillemets doubles) et les caractères spéciaux associés au code SQL (p. ex. SUPPRIMER, METTRE À JOUR) lorsque cela est possible et selon les autorisations de l’application Web.

7.6 Cacher aux utilisateurs les messages d’erreur SQL

Les messages d’erreur SQL peuvent fournir de nombreuses données relatives à votre base de données, notamment des demandes d’information pour des champs et des bases de données spécifiques. Ne permettez pas aux utilisateurs de voir les messages d’erreur, car cela peut donner des indications aux auteurs de menace quant à savoir à quoi ressemble votre base de données.

7.7 Bloquer les instances à plusieurs paramètres

Dans la mesure du possible, veuillez bloquer les instances à plusieurs paramètres afin de filtrer les demandes avant que le serveur d’applications les traite. La mise en œuvre dans le code dépend de la plateforme d’application que vous utilisez. Certaines plateformes ont une protection implicite contre les paramètres multiples du même nom. Vous pouvez également limiter vos entrées de la partie frontale et utiliser un coupe-feu WAF pour bloquer certains mots-clés propres à des instructions SQL.

Le protocole HTTP permet l’utilisation de plusieurs paramètres ayant le même nom; ainsi, des valeurs multiples du même nom de paramètre peuvent se retrouver dans une seule demande. Cette procédure est gérée différemment selon les plateformes de serveur (p. ex. ASP.NET, JSP, PHP), en utilisant les deux valeurs ou simplement la première valeur ou la seconde valeur, ce qui peut prêter à confusion. Le comportement des applications peut changer, et la validation d’entrée peut être contournée.

Il est recommandé de tester ces validations durant la phase de développement au moyen de révisions de code et d’essais de développement.

7.8 Valider après l’encodage

Vous devriez définir l’encodage sur les pages Web et vous assurer que toutes les pages prennent en charge le même encodage. Si possible, désactivez le mappage ajusté et normalisez les données par encodage avant de valider les données. Vos clients et vos plateformes logicielles peuvent se trouver à travers le monde. Ainsi, il peut y avoir confusion entre des caractères appartenant à des langues différentes qui peuvent se ressembler beaucoup, mais dont la signification est complètement différente pour votre application.

Utilisez, si possible, le format transformé d’Unicode 8 (UTF-8) de la convention Unicode Standard. Le codage UTF-8 est le plus répandu dans le monde pour les pages Web, et il prend en charge la compatibilité descendante. Actuellement, la plus récente version du codage UTF-8 est la version v.12.1. Utilisez des bibliothèques à normalisation standard. La plupart des fournisseurs de logiciels modernes utilisent Unicode comme langage universel pour identifier clairement les caractères, pendant que les données sont traitées dans différentes plateformes et divers dispositifs, pour empêcher l’altération des données.

Effectuez des essais dans le cadre du processus de développement, en utilisant les révisions de code et les essais à l’exécution.

7.9 Sécuriser le téléversement de fichiers

Le téléversement de fichiers est une forme d’entrée dans votre application Web. Dans de nombreux cas, le téléversement de fichiers peut s’inscrire dans le cadre du contenu de votre site Web. Il y a un risque que le téléversement puisse comporter un contenu exécutable ou un certain type de maliciel. De plus, un téléversement plus volumineux que prévu peut entraîner des problèmes de disponibilité pour votre application Web.

Vous devez chercher à savoir pourquoi le téléversement du fichier est nécessaire et s’il existe d’autres formats pouvant prendre en charge ces données, comme des champs textes et zones de texte. Bien que ces formats de rechange nécessitent plus d’entrées de l’utilisateur final, ils assurent un stockage plus sécuritaire. De plus, il est plus facile d’effectuer des recherches sur des données lorsqu’elles sont entrées dans ces formats, car le contenu demeure conforme (p. ex. en mode texte). Vous pourriez par exemple songer à une demande d’emploi. L’entrée par formulaire offre plus d’avantages à l’examinateur, car il peut effectuer des recherches sur des mots-clés, et au candidat, car il n’a pas à s’inquiéter que le logiciel de lecture ne soit pas en mesure d’analyser le contenu de son CV.

S’il est nécessaire de téléverser un fichier, vous devriez filtrer le téléchargement de ce fichier en fonction de l’extension de fichier et des limites de taille, et analyser le contenu. Vous pouvez utiliser la commande « fichier », qui vérifie les types de fichiers et permet de comprendre le type de contenu. Pour extraire les métadonnées ou le contenu pour effectuer une inspection plus approfondie, vous pouvez également utiliser des outils et des bibliothèques complémentaires pour l’extraction du fichier en format texte ou Extensible Markup Language (XML). Pour ce qui est des graphiques, vous pouvez utiliser des outils pour supprimer des métadonnées et détecter des anomalies.

7.10 Tester la logique métier

La logique métier fait référence aux décisions opérationnelles de votre organisation et à la façon selon laquelle ces décisions sont traduites en logique de codage sur le serveur d’applications. Des risques peuvent être engendrés si les décisions opérationnelles ne sont pas claires ou ne sont pas traduites adéquatement pour la logique de codage. Des failles dans la logique métier peuvent donner accès à des entrées erronées dans votre espace, ce qui peut occasionner bon nombre de problèmes.

Vous devez bien définir vos exigences et cas d’utilisation, y compris les cas d’utilisation malveillante. Lorsque vous définissez des exigences liées à la sécurité, analysez le processus opérationnel dans son ensemble. Testez la logique métier pendant et après la phase de développement pour régler les cas d’utilisation et d’utilisation malveillante. Vous devez vous assurer que les cas d’utilisation règlent toutes occurrences d’accès simultanés, qui se produisent lorsque plusieurs processus doivent avoir accès à la même ressource au même moment.

7.11 Effectuer des tests de pénétration

Les tests de pénétration sont nécessaires pour déterminer jusqu’à quel point votre validation d’entrée est résiliente face à des activités malveillantes. Les tests de pénétration, ou le piratage contrôlé, impliquent des testeurs qui sont autorisés à tenter de trouver et d’exploiter les vulnérabilités de sécurité. Il existe différents types de tests de pénétration (p. ex. les testeurs reçoivent plus ou moins d’informations sur vos systèmes); toutefois, vos testeurs ne devraient pas faire partie de votre équipe de développement pour qu’ils puissent simuler les comportements des auteurs de menace.

8.1 Désactiver l’exploration des répertoires

Pour éviter de couler de l’information potentiellement sensible aux utilisateurs, désactivez l’option d’exploration des répertoires qui se trouve sur votre serveur Web. L’exploration de répertoires se produit lorsque vous pouvez voir et accéder aux dossiers ainsi qu’aux fichiers qui composent le site Web plutôt que de le voir comme il devrait être présenté aux utilisateurs. Ces dossiers contiennent de l’information qui n’est pas censée être vue par le public, notamment des images, des scripts ou des sauvegardes. L’exploration des répertoires est habituellement mise en œuvre par répertoire, et vous devez désactiver cette fonction pour chacun des répertoires.

Il vous faut également créer un fichier index.htm vide dans chaque répertoire. Si le fichier de base, comme index.htm ou index.php n’est pas disponible, alors par défaut, n’importe qui peut voir tous les fichiers et les sous-répertoires énumérés dans le navigateur. Testez chaque répertoire et sous-répertoire.

8.2 Supprimer les fichiers du répertoire Web inutiles

Dans le cadre de votre politique en matière de déploiement sécurisé, vous devez passer en revue vos répertoires Web avant et après le déploiement de votre site Web afin d’atténuer les risques associés aux fuites de données. Les répertoires Web peuvent contenir de l’information qui n’est pas censée être vue par le public, notamment des images, des scripts ou des sauvegardes.

Il vous faut également définir des exigences pour établir le cycle de vie des fichiers répertoires Web. Et vous devez aussi supprimer des répertoires Web les fichiers d’opérations Web inutiles. Ciblez les anciennes versions des fichiers (multiples fichiers default.asp), code source (.bak), fichiers de sauvegarde (pouvant contenir des mots de passe) et fichiers de contrôle de source (.svn et .git). Afin de faciliter l’identification de ces fichiers, vous pouvez activer l’option Heure du dernier accès sur le système de fichiers, ce qui vous donne un accès visuel aux fichiers rarement utilisés, voire jamais. Faites une vérification lors de vos révisions de code.

8.3 Verrouiller les composants de services Web

Afin de réduire votre exposition aux menaces, vous devez verrouiller différents composants de vos services Web.

Vous devriez privilégier le verrouillage, ou le renforcement, de vos hôtes de service Web en supprimant les ports, les fichiers et les codes inutilisés, ainsi que les comptes inutilisés à cycle de vie. Si vos serveurs Web restent exposés, il y a un risque accru que les auteurs de menace puissent exploiter ces ports et services. Ces mesures peuvent améliorer les protections offertes par les coupe-feux et les politiques de sécurité.

Vous devriez également supprimer tout module d’extension dans vos systèmes de gestion de la configuration (CMS pour Configuration Management System). Plus vous avez des modules d’extension, plus grande est votre surface d’attaque, plus particulièrement si les modules d’extension ne constituent pas des modules officiels.

De plus, renforcez le serveur SQL et supprimez toutes les procédures stockées qui sont inutilisées ainsi que les comptes par défaut qui se trouvent dans votre base de données. Surveillez la connexion sortante du serveur SQL pour détecter une intrusion.

8.4 Désactiver la mise en cache des justificatifs d’identité

Les navigateurs donnent la possibilité d’enregistrer les mots de passe des utilisateurs pour des raisons de commodité. Il faut toutefois noter que le stockage de mots de passe sur le navigateur de l’utilisateur n’est pas sécuritaire. En cas de vol du dispositif mobile ou de l’ordinateur portable d’un utilisateur, et si un auteur de menace arrive à accéder au site Web, les justificatifs de cet utilisateur seront automatiquement affichés. Lors du codage en format HTML, assurez-vous de désactiver l’élément Remplissage autom. (autocomplete), qui indique au navigateur de désactiver la mise en cache des informations d’identification pour ce formulaire.

8.5 Utiliser des scanneurs de vulnérabilité

Vous devriez intégrer l’analyse des vulnérabilités à votre processus de déploiement sécurisé. Des outils tels que Zed Attack Proxy (ZAP) de source ouverte de l’OWASP sont couramment utilisés pour identifier des vulnérabilités propres aux applications Web. Vous pouvez donc avoir recours à ces outils pour trouver des vulnérabilités, qui peuvent également servir aux testeurs de pénétration pour déterminer les points d’entrée dans vos services Web.

8.6 Automatiser le déploiement

Il peut s’avérer compliquer de gérer les configurations sécuritaires de toutes les sections mobiles de votre site Web. Une pratique exemplaire consiste à automatiser les environnements. Cette pratique permet de s’assurer que les environnements sont conçus de façon répétable (p. ex. ils peuvent être redéployés au besoin) et automatisée (p. ex. Sans intervention humaine). C’est à vous que revient la tâche de définir les rôles et les responsabilités quant à l’exécution de la gestion de la configuration et de la vérification.

Vous pouvez utiliser des conteneurs et des modèles de configurations de sécurité. Pour restreindre la surface d’attaque, vous devriez créer un conteneur dans lequel on met uniquement une image basée sur un serveur Web. En utilisant des modèles et des conteneurs, vous pouvez vous assurer que les nouvelles versions de serveur Web ne comportent pas de bogues du jour zéro. Lors du déploiement, rappelez-vous de désactiver les fonctionnalités de connexion à distance pour que le protocole SSH ne soit pas autorisé en production.

9.1 Effectuer des activités de surveillance

Définissez votre stratégie de surveillance de façon à identifier des attaques potentielles et des anomalies propres aux risques liés aux applications Web mentionnés dans le projet OWASP Top 10 ^{Note de bas de page 4}. Dans le cadre des activités de surveillance pour votre application Web, tenez compte des composants de l’architecture Web mentionnés à la Section 3 du présent document. Surveillez le trafic sur votre réseau ainsi que toutes tentatives infructueuses de connexion. Analysez les registres et avisez les parties concernées de toutes activités inhabituelles en temps opportun pour ainsi assurer d’une intervention efficace.

9.2 Élaborer un plan d’intervention en cas d’incident

Élaborez un plan d’intervention en cas d’incident, qui comprend des guides opérationnels sur les incidents, afin de définir les interventions que votre organisation dot mettre en œuvre lors de la détection d’un incident. Par exemple, vous devriez inclure des étapes permettant d’identifier, de communiquer, de contenir et de corriger les incidents. Il vous faut bien définir les rôles et les responsabilités pour être en mesure d’intervenir en cas d’incident, plus particulièrement si plusieurs équipes ou organisations sont impliquées dans la prise en charge de vos exigences de surveillance. Ce plan doit être rigoureusement testé pour assurer son efficacité.

Si vous faites appel à un FSG ou à un FSI, travaillez de concert avec votre fournisseur de services pour établir un plan commun d’intervention en cas d’incident et assurez-vous d’avoir accès aux données appropriées et d’être avisé adéquatement. Assurez-vous de coordonner les essais avec votre fournisseur de services. Identifiez l’information reçue et déterminez des délais raisonnables pour vous permettre d’intervenir judicieusement.

Pour obtenir une liste complète des fonctionnalités de surveillance de la sécurité, consultez le catalogue de contrôle de la sécurité à l’Annexe 3a du guide ITSG-33 ^{Note de bas de page 3}, et plus particulièrement les familles de contrôle de la sécurité : vérification et imputabilité (AU pour auditing and accountability) et intervention en cas d’incident (IR pour incident response).

9.3 Établir une stratégie d’application de correctifs

La gestion des correctifs est le processus qui permet d’acquérir, de tester et d’installer des correctifs et des mises à niveau pour vos systèmes. La stratégie de gestion des correctifs pour vos applications Web sera semblable à la stratégie d’application de correctifs du reste de votre infrastructure. Toutefois, vous devez tenir compte et établir l’ordre de priorité des composants de l’architecture qui sont exposés à Internet.

Il est recommandé de s’abonner à des publications sur les vulnérabilités et les applications (p. ex. la liste Common Vulnerabilities and Exposures [CVE pour vulnérabilités et expositions courantes] de MITRE) pour que vous puissiez identifier les vulnérabilités à mesure que celles-ci deviennent connues. Il existe plusieurs outils reconnus et à faible coût que vous pouvez utiliser pour analyser les vulnérabilités dans votre réseau. Tenez aussi compte des vulnérabilités dans les dépendances et les conteneurs de bibliothèque. Une autre option est de faire un balayage des composants logiciels anciens et désuets à mettre à jour. Si votre organisation n’est pas en mesure de mettre rapidement en œuvre des correctifs, réexaminez vos règles de coupe-feu pour réduire les risques.

Si vous utilisez des services gérés ou des services infonuagiques, travaillez en collaboration avec votre fournisseur de services pour appliquer des correctifs de sécurité et des mises à jour, et ce, en temps opportun pour respecter vos exigences. Pour ce qui est des services infonuagiques, l’entité responsable de l’application des correctifs dépend de votre modèle de service infonuagique (p. ex. dans un modèle de logiciel en tant que service, le FSG est chargé des mises à jour et de l’application des correctifs).

9.4 Promouvoir la sensibilisation à la sécurité

Malgré l’évolution des technologies et des cybermenaces, vous pouvez continuer de protéger vos systèmes, vos renseignements et vos clients contre des compromissions en insistant sur la promotion de la sensibilisation à la sécurité. Il vous faut promouvoir les pratiques exemplaires comme le fait de ne pas cliquer sur des liens ou de ne pas télécharger des fichiers. Ces pratiques se font en changeant votre façon de communiquer avec vos clients. Par exemple, si vous devez communiquer avec un client pour discuter de son compte, ne joignez pas de lien ou de fichier téléchargeable dans votre communication. Demandez plutôt au client de se connecter à votre site Web ou de vous contacter à l’aide des coordonnées qui se trouvent sur votre site. Vous pouvez aussi lui suggérer de vérifier les communications que vous lui avez envoyées et de vous signaler toutes activités suspectes.

Vous pouvez également diriger les clients vers nos documents de la campagne Pensez cybersécurité qui sont conçus pour sensibiliser les Canadiens à la sécurité en ligne.

10.1 Parler avec des pairs

Quel que soit le secteur de l’industrie, les problèmes et les préoccupations auxquels vous êtes confrontés ne sont pas nécessairement uniques. On comprend bien qu’il n’est pas facile de discuter d’enjeux relatifs à la sécurité avec des concurrents. Cependant, il faut demeurer à l’affût des occasions qui se présentent pour discuter d’options de produits ou de fournisseurs, ainsi que des défis que pose le développement. Vous pourriez être agréablement surpris de constater à quel point vous pourriez en apprendre de l’expérience des autres.

10.2 OWASP

L’OWASP Foundation est une fondation sans but lucratif qui vise à améliorer la sécurité des logiciels. Vous êtes invité à consulter le projet OWASP Top 10 ^{Note de bas de page 4} pour connaître la liste des risques critiques de sécurité touchant les applications Web.

10.3 Centre antifraude du Canada

Si votre organisation a été victime de fraude, par exemple si un auteur de menace s’est fait passer pour votre organisation, communiquez avec le service de police le plus près de chez vous et faites un signalement en ligne en passant par le Système de signalement de cas de fraude au Centre antifraude du Canada.

10.4 Contactez-nous

Pour obtenir de plus amples renseignements sur la cybersécurité, visitez notre site Web (cyber.gc.ca) ou communiquez avec notre équipe des Services à la clientèle du Centre :

Centre d’appel
contact@cyber.gc.ca
613-949-7048 ou 1-833-CYBER-88