Introduction à la sécurisation des applications web

La sécurisation des sites web est un sujet important dès lors que l’application que vous développez contient des données un tant soit peu sensibles, ayant trait à la vie privée, à des données bancaires ou encore à des données stratégiques (d’entreprise, gouvernementales, militaires …).

Le but de cet article est de sensibiliser les développeurs aux notions de sécurité des applications web. L’idée n’est pas de faire de vous des experts de la sécurité (le sujet est, comme vous vous en doutez probablement, plutôt vaste) mais de vous donner les bases qui vous permettront d’appréhender les principales problématiques de la sécurité informatique, et plus particulièrement de la sécurité des applications Web. Cet article n’a donc pas vocation à être un état de l’art des techniques de cryptographie et de sécurité informatique, mais d’en introduire les concepts.

Lorsque nous travaillons sur la sécurisation d’une application, nous nous attachons principalement aux aspects suivant :

• l’authentification,
• les autorisations,
• l’intégrité,
• la confidentialité,
• l’identité,
• la non répudiation.

Nous allons traiter dans la suite de cet article ces différents principes, en essayant de rester simple et pragmatique.

Principes de la cryptographie

Avant d’entrer dans le vif du sujet, je vous propose un petit rappel des principaux principes de la cryptographie.

Les fonctions de hachage

Ces fonctions permettent de calculer une empreinte (appelée aussi hash) d’une donnée informatique. Les fonctions de hachage implémentent quelques propriétés que nous allons définir maintenant :

• le grand nombre d’empreintes possibles (entre 2^128 à 2^256 bits) implique une probabilité extrêmement faible de collisions,
• la taille de l’empreinte est fixe, quelle que soit la taille de la donnée hachée. L’empreinte d’un mot de passe de huit caractères aura donc la même taille que l’empreinte d’un fichier de plusieurs centaines de Mo,
• un changement infime dans la donnée hachée entraîne un changement important dans l’empreinte correspondante (ce qui rend une recherche inverse par dichotomie impossible),
• le calcul d’une empreinte est très rapide (pratique pour le calcul de sommes de contrôle de fichiers de plusieurs centaines de Mo),
• il n’est pas possible, en connaissant l’empreinte et la fonction de hachage utilisée, de calculer la donnée d’origine.

Ces fonctions sont généralement utilisées pour les besoins suivant :

• vérification de l’intégrité d’une donnée : dans ce cas, le hash (généralement appelée somme de contrôle ou checksum) est utilisé pour s’assurer qu’une donnée informatique n’a pas été corrompue,
• stockage des mots de passes : le hachage du mot de passe permet d’éviter que ce dernier soit stocké en clair. Nous reviendrons sur ce cas d’utilisation dans la suite de cet article,
• la construction de jetons : comme les jetons remember me.

Il existe différents algorithmes de hachage :

• MD5 (Message Digest 5) : probablement le plus connu, il est souvent utilisé pour les sommes de contrôle ou le stockage de mot de passes (notamment dans sa version salée dans diverses distributions Linux). Son empreinte est représentée sur 128 bits. Actuellement, le MD5 est mis de côté au profit des algorithmes SHA1 et SHA256 réputés plus sûrs.
• SHA1 (Secure Hash Algorithm) : cette fonction de hachage crée des empreintes sur 160 bits. Cet algorithme est lui aussi progressivement remplacé par le SHA256, beaucoup moins facile a casser grâce à son empreinte sur 256 bits.

Le cassage d’un mot de passe haché ne peut se faire que par brute force (si l’on a beaucoup de puissance de calcul et de temps), par dictionnaire (on parcourt successivement les mots de passe les plus courants), en utilisant des dictionnaires inversés qui permettent de retrouver le mot de passe à partir du hash ou encore plus efficacement par l’utilisation de Rainbow Tables.
Cette dernière technique reste la plus efficace pour retrouver un mot de passe faible, à condition d’avoir accès au hash d’origine. On peut l’imaginer comme une grosse HashMap dont la clé serait l’empreinte et la valeur la donnée d’origine. Les mots de passe les plus simples ont donc de grandes chances de s’y retrouver.

Le salage du hash est une technique efficace permettant de se prémunir des attaques par dictionnaire inversé. Cette technique consiste à ajouter à la donnée à hacher un sel, qui peut être une valeur arbitraire, et qui rendra donc les attaques par dictionnaire inversé inefficaces :
empreinte = hachage(mot_de_passe + sel)
Il n’est pas nécessaire que le sel soit une information secrète, son utilité étant de rendre les dictionnaires inversés inefficaces.

Les commandes unix md5pass et sha1pass permettent de générer des mots de passes salés :

% sha1pass password dupont@example.com
$4$dupont@example.com$hJLyOpYbVayE1Iq/ZY03Rx/r5Sk$
% sha1pass password martin@example.com
$4$martin@example.com$+LoO8eRzXhH23ozwXIDDpNE7ag4$

On voit ici que le salage d’un même mot de passe donne une empreinte totalement différente.

Nous reviendrons dans un prochain article sur la manière d’utiliser les algorithmes de hachage pour le stockage des mots de passe.

Le chiffrement symétrique

Les algorithmes de chiffrement symétriques reposent sur un secret (clé de chiffrement) partagé qui est utilisé pour chiffrer une donnée. Ils sont généralement utilisés pour sécuriser des informations ou des communications. Ses caractéristiques sont :

• un chiffrement rapide des données, nécessaire au chiffrement des communications ou d’un important volume de données,
• la même clé est utilisée pour chiffrer et déchiffrer.

Les algorithmes les plus couramment utilisés sont l’AES et le Blowfish. Il existe un grand nombre d’algorithme disponibles en Java (cf la documentation du projet Bouncycastle et la page de Wikipedia)

Le chiffrement asymétrique

Ce chiffrement repose sur une bi-clé, l’une publique et l’autre privée, dont l’une permet de chiffrer ce que l’autre va déchiffrer. Si la clé publique est utilisée pour chiffrer, la clé privée permettra le déchiffrement et inversement.
La clé publique est librement diffusée et peut être utilisée pour chiffrer une donnée à l’intention du détenteur de la clé privée.
La clé privée peut aussi être utiliser pour chiffrer et dans ce cas, seule la clé publique pourra déchiffrer le contenu. Ce type d’utilisation permet au détenteur de la clé privée de prouver son identité en signant une donnée. Nous y reviendrons dans la suite de cet article.

Le chiffrement asymétrique est principalement utilisé pour chiffrer des clés de chiffrement symétriques ou des hash pour une raison toute simple : les algorithmes de chiffrement asymétriques sont excessivement lents et ne peuvent pas être utilisés pour chiffrer des données dépassant quelques centaines d’octets. Son usage est donc principalement réservé au chiffrement de clés ou d’une empreinte (hash).

Un cas typique d’utilisation du chiffrement asymétrique est l’échange de clés de session (clé secrète) permettant le chiffrement d’une communication entre deux systèmes.
Un autre cas d’utilisation du chiffrement asymétrique est la signature d’un document. Dans ce cas, l’empreinte du document à signer est chiffrée à l’aide de la clé privée et déchiffrée avec la clé publique. Nous reviendrons plus tard sur ces types d’utilisation.

Les algorithmes asymétriques les plus connus sont le RSA (Rivest Shamir Adleman), le DSA (Digital Signature Algorithm) et le protocole d’échange de clés Diffie-Hellman.

Enfin, le chiffrement asymétrique est utilisé dans les certificats numériques X509 dont nous reparlerons bientôt.

Nous en avons fini avec les principes de base de la cryptographie. Un petit tour sur Wikipedia vous donnera de plus amples informations sur le sujet.

L’authentification

L’authentification est probablement la notion la plus simple à comprendre, mais en tant que développeur, c’est une de celles qui vous demandera le plus de travail d’implémentation.
Comme vous pouvez vous en douter, l’authentification consiste à fournir un moyen d’accès à une application.

Authentification par identifiant et mot de passe

Elle prend le plus souvent la forme d’un formulaire d’authentification où un identifiant unique ainsi qu’un secret (mot de passe secret que seul l’utilisateur rattaché à l’identifiant unique est sensé connaître) vous est demandé.
Dans ce cas de figure, le mot de passe est généralement stocké sous forme hachée le plus souvent dans un annuaire LDAP ou dans une base de donnée. La version salée de la fonction de hachage est chaudement recommandée afin d’éviter la découverte du mot de passe à l’aide d’un dictionnaire inversé.

Des techniques de durcissement de l’authentification par mot de passe, comme l’envoi de SMS, l’utilisation de Captchas ou encore l’utilisation de RSA SecurID, peuvent être employé avec des résultats plus ou moins satisfaisants.

Dans un prochain article, nous verrons qu’il est assez simple de mettre en œuvre ces bonnes pratiques d’authentification à l’aide du framework Spring Security.

Authentification par certificat

Les certificats numériques X509 sont généralement connus pour leur utilité dans le chiffrement des connexions SSL (utilisé avec le protocole HTTPS) et peuvent aussi être utilisés pour l’authentification à une application. Ils sont constitués d’une partie privée, généralement protégée par un mot de passe, qui est conservée par l’utilisateur et d’une partie publique qui est stockée sur le système hébergeant l’application à laquelle nous souhaitons accéder.

Là encore, un durcissement de cette technique d’authentification peut être réalisé à l’aide de tokens cryptographiques (clés USB, cartes à puce). Ces tokens cryptographiques ont la capacité de générer la bi-clé du certificat numérique et d’effectuer des opérations de chiffrement/déchiffrement asymétriques. L’intérêt majeur réside dans le fait que la clé privée ne sortira jamais du token et ne pourra donc pas être dupliquée (en cas de vol, le certificat sera simplement révoqué et deviendra inutilisable). La sécurité est donc assurée par une possession physique (le token) et par un secret (le mot de passe permettant l’utilisation du token).

Les certificats numériques sont un moyen de contrôle d’accès efficace mais potentiellement complexes à mettre en œuvre. Nous reviendrons sur le détail de leur fonctionnement et de leur utilisation dans un prochain article.

Authentification par Single Sign On (SSO)

Le Single Sign On permet la délégation de l’authentification à une application tierce qui va permettre aux utilisateurs d’accéder à toutes les applications du Système d’Information en ne s’authentifiant qu’une unique fois, pour la durée de la session d’authentification.

L’authentification par SSO peut être mise en place en interne, au sein du Système d’Information d’entreprise utilisant le Central Authenticate Service (CAS) par exemple, ainsi qu’en externe à l’aide de sites implémentant des protocoles tels qu’OpenID.

Là encore, un prochain article entrera dans les détails de l’utilisation du SSO dans vos applications web, ainsi que diverses bonnes pratiques et mises en garde sur leur utilisation (notamment en ce qui concerne OpenID).

Les autorisations

Une fois authentifié, l’utilisateur souhaite utiliser l’application et pour cela, il lui faut des droits ou autorisations. Chaque utilisateur aura donc un rôle lui accordant un ensemble de droits permettant d’effectuer des opérations ou d’accéder à certaines données.
Les rôles les plus communs sont « utilisateur » ou encore « administrateur » mais il est possible d’imaginer tous types de rôles en fonction des besoins de l’application.

L’intégrité

Les fonctions de hachage sont utilisées pour s’assurer de l’intégrité (la non altération) d’une donnée. Le calcul des sommes de contrôle est un élément important permettant de s’assurer qu’une donnée n’a pas été corrompue, frauduleusement ou non.

La confidentialité

L’un des enjeux de la sécurisation des sites web est de garantir la confidentialité des données. Cette confidentialité repose sur les mécanismes de chiffrement symétriques et asymétriques qui permettent de protéger des données locales (avec TrueCrypt par exemple) ou bien des communications.

L’un des mécanismes les plus connus est probablement le protocole Secured Socket Layer (SSL) (remplacé par Transport Layer Security normalisé par l’IETF) qui permet entre autre, le chiffrement des communications entre deux tiers. Le protocole utilise les algorithmes asymétrique pour chiffrer une clé de session (symétrique) qui est ensuite utilisée pour le chiffrement symétrique de la communication.

La confidentialité est d’une importance capitale dans tout mécanisme d’échange de données un tant soit peu sensibles (mot de passes, données bancaires …).

L’identité

Prouver son identité est probablement la tâche la plus complexe, et en même temps un des aspects fondamentaux de la sécurité. Lors d’une communication entre deux tiers, au hasard un client et un serveur, nous avons vu que certains mécanismes permettent de s’authentifier ou encore d’assurer la confidentialité.

Nous avons aussi vu que les algorithmes de chiffrement asymétriques, reposant sur une bi-clé dont l’une est privée et l’autre est publique, permettent l’échange de données sécurisé ou encore de prouver son identité.

Dans le premier cas de figure, nous utilisons la clé publique de notre interlocuteur afin de chiffrer une clé de session qui elle même a permis le chiffrement du document que nous souhaitons faire parvenir, en toute confidentialité, au possesseur de la clé privée. Dans ce cas, la seule chose dont nous sommes certains est que seul le possesseur de la clé privée sera à même de déchiffrer le contenu du document.

Dans un second cas de figure, nous souhaitons prouver que nous sommes à l’origine d’une donnée (une demande de congés par exemple). Une fois encore, le mécanisme de chiffrement asymétrique va venir à notre rescousse en nous permettant de chiffrer une empreinte du document que nous souhaitons envoyer à l’aide de notre clé privée. Ainsi, en déchiffrant l’empreinte à l’aide de la clé publique, nous nous assurons que la donnée provient bien du possesseur de la clé privée, mais aussi que cette donnée n’a pas été altérée, en recalculant l’empreinte du document et en la comparant à celle que nous venons de déchiffrer.

C’est plutôt pas mal, nous avons un mécanisme nous permettant d’envoyer un document de manière confidentielle à un tiers, mais aussi de prouver notre identité, juste à l’aide d’un mécanisme de clé publique que l’on distribue à ceux avec qui l’on souhaite communiquer. C’est malheureusement sur ce dernier point, « la distribution de la clé publique », que les choses se compliquent. Est-il toujours possible de remettre en main propre sa clé publique ? Comment puis-je m’assurer que la clé publique dont je dispose correspond bien à l’émetteur dont je crois connaître l’identité ?

Les certificats numérique dont le standard X509 est le plus répandu, apporte des réponses à nos questions. Ces certificats contiennent un certain nombre d’informations sur son propriétaire, sa clé publique ainsi qu’une empreinte signée du contenu du certificat.

Concernant la signature de l’empreinte nous avons deux cas de figure. Dans le premier cas, l’empreinte est signée à l’aide de la clé privée correspondant à la clé publique du certificat, c’est ce que l’on appelle un certificat auto-signé. Dans le second cas, une demande de certification est envoyée à une Autorité de Certification (AC), qui va ajouter sa propre identité dans le certificat (clé publique + informations sur l’Autorité de Certification) et signer l’empreinte du certificat.

L’Autorité de Certification peut être une entreprise dont les certificats sont reconnus dans la plupart des Systèmes d’Exploitation, Navigateurs, JVM…, comme Verisign par exemple, mais peut aussi être une DSI qui crée son propre certificat racine et l’implante dans les différentes postes de son SI.

Lorsque le navigateur, par exemple, recevra un certificat X509, celui-ci vérifiera qu’il est bien signé par une Autorité de Certification reconnue et le reconnaîtra comme valide. Dans le cas d’un certificat auto-signé et non reconnu, le système pourra proposer de l’accepter à ses risques et périls.

Afin d’augmenter la sécurité des certificats, les clés privées (qui sont sensées ne jamais être exposées), sont généralement protégées par un mot de passe. Le principe est que notre identité soit protégée par quelque chose que l’on possède (une clé privée) et un secret. Des mécanismes plus « durs » de sécurisation reposent sur des tokens cryptographiques qui contiennent le générateur de la bi-clé et l’espace mémoire pour stocker la clé privée. Dans ce cas, la clé privée peut être volée mais pas dupliquée. En cas de vol, le certificat numérique peut être révoqué ce qui empêche une utilisation délictueuse.

Nous n’entrerons pas plus dans les détails sur les certificats numériques dans cet article. Nous en reparlerons lorsque nous aborderons l’authentification X509 dans un prochain article. Sachez simplement que les certificats numériques sont mis en œuvre dans beaucoup de mécanismes tels que les connections HTTPS qui sécurisent nos communications sur le web, dans le protocole SSH ou encore dans les réseaux privés virtuels (VPN).

La non répudiation

La non répudiation consiste à s’assurer que l’émetteur d’une donnée ne puisse pas nier son implication en cas de litige. La non répudiation repose généralement sur des certificats numériques, qui restent le moyen le plus efficace pour s’assurer de l’identité d’une personne.

D’un point de vue légal, la non répudiation est particulièrement difficile à mettre en œuvre. Il est en effet difficile de remettre en cause la bonne foi d’une personne pouvant prétexter le vol de son identité numérique pour se défausser de sa responsabilité. Il peut par exemple être nécessaire de mettre en place des mécanismes de co ou de contre signature et de l’horodatage en fonction des besoins.

Ce sujet est particulièrement complexe, nous ne nous y attarderons pas plus. Vous pourrez trouver de plus amples informations sur internet, ici par exemple.

Conclusion

Cette introduction nous à permis de faire un tour des principes liés à la sécurisation des sites web. Les principes cryptographiques que sont le hachage et les algorithmes de chiffrement symétriques et asymétriques sont à la base de toute infrastructure web sécurisée.

Comme vous l’aurez compris, cet article est le prélude à une série d’articles sur la sécurisation des sites web, où nous utiliserons le très répandu framework Spring Security pour illustrer nos propos et quelques bonnes pratiques. Nous nous efforcerons par la même occasion d’aborder les failles les plus communes, référencées par l’OWASP Top Ten, et de montrer comment les traiter.