Nous supposons ici que votre environnement d’hébergement est déjà sécurisé, qu’il s’agisse d’un environnement géré en interne ou administré par un prestataire externe.
Focalisons nous sur l’application. Quelles sont les étapes à effectuer afin d’améliorer la sécurité d’une application web ? Comment réduire la surface d’attaque et éliminer des risques facilement décelables ?
Cet article n’a pas la prétention de constituer le manuel du parfait défenseur d’applications web, mais rappelle des principes de bases et présente une liste d’éléments à prendre en compte et à appliquer.
1. Avoir une politique de sécurité d’entreprise forte
La première faille pouvant être exploitée est humaine, et facilite grandement le travail aux hackers : mots de passe faibles, données liées à la sécurité mal sécurisées (comme des mots de passes enregistrés dans un fichier texte sur un bureau, un post-it), niveau d’accès volontairement ou involontairement trop élevé… autant d’éléments qu’il faut éliminer afin de ne pas laisser des portes ouvertes.
Souvent rappelée, mais rarement prise en compte : la complexité des mots de passe. Inclure des chiffres, des majuscules et des caractères spéciaux. Ces règles devraient être appliquées partout et depuis longtemps, mais en observant des bases de données de mots de passe on se rend compte que les mots de passe les plus utilisés sont très faibles, et ce autant pour des comptes personnels que pour des accès à des interfaces donnant accès à des fonctions puissantes ou données confidentielles. “abc123″, “azerty », “password », “admin », voilà à quoi ressemblent les mots de passe les plus utilisés encore en 2013.
Des règles d’hygiène de sécurité informatique donc ; des process à définir et respecter.
2. Supprimer l’inutile
Une première étape à effectuer peut être avant de s’attaquer à la sécurité des applications : réduire la surface d’attaque en réduisant tout simplement l’arsenal d’applications en production ou même en environnements de recette. Toutes les sites web de votre entreprise sont-ils nécessaires ? N’y a-t-il pas une vieille application quasiment inutilisée exposant des données ou pouvant potentiellement constituer un risque pour votre environnement web global ?
Cette question se pose aussi bien pour un site web que pour les éventuels webservices ou APIs qui y sont liés. Un webservice non utilisé et mal sécurisé est une porte ouverte qui ne sert à personne, sauf peut être à une personne malveillante.
3. Mettre à jour ses librairies, et bien les choisir
On peut semble-il estimer le volume de code des applications web comme étant constitué à 80% de librairies, qui n’ont pas été développées par votre organisation.Il convient donc d’effectuer plusieurs opérations de maintenance sur ces librairies :
- Premièrement, s’assurer que les librairies présentes dans vos applications sont utilisées, et que leur utilisation justifie la maintenance qui en découlera.
- Deuxièmement, vous assurer que les librairies que vous utilisez sont reconnues, perçues comme fiables par la communauté. Qu’y aurait-il de pire que d’installer directement dans votre site web une librairie contenant du code malveillant ? Si celle-ci se permettait de voler vos données pour les envoyer vers un serveur pirate ? En 2011, 26% des librairies téléchargées étaient vulnérables, et clairement reconnues comme étant vulnérables (1). Il est certes très confortable lors d’un développement de s’appuyer sur du code existant afin de réduire la charge de travail, mais des précautions s’imposent!
- Troisièmement, maintenir ces librairies. L’open source c’est bien car c’est gratuit, mais il y a un coût de maintenance non négligeable et non négociable. Lorsque la communauté découvre des failles, celles-ci sont en général dévoilées, et donc exploitables par quiconque. Bien entendu, c’est encore pire lorsque la librairie est payante… Donc, surveillez ces librairies et leurs mises à jour : testez-les et installez-les dans vos applications web. Il existe même des outils permettant d’être notifié sur la disponibilité des mises à jour.
4. Ne pas laisser échapper des détails d’architecture
Toujours une faille directement humaine : la fuite d’informations confidentielles à propos de votre application elle-même. Un développeur sera facilement tenté et même incité à copier-coller un morceau de code sur un forum, afin d’obtenir une aide pour le développement d’un module. Les pirates cherchent en général des informations sur leur cible dans ces forums, pastebin et autres newsgroups. Ce sont ainsi des informations sur l’architecture de votre application (code, version de plugins, librairies, process, logique business) qui sont dévoilées.
A nettoyer à tout prix donc, et éviter de trop en dire.
5. Revoir la fiabilité des fonctionnalités critiques
Une revue des process internes à vos applications web (business logic) s’impose. Est-ce que votre process de récupération des mots de passe est fiable ? Ne peut-il pas être utilisé facilement pas un pirate pour modifier ou récupérer les mots de passe de vos utilisateurs ? A quoi sert une validation de paiement carte bleue en béton armé si l’utilisateur peut modifier le contenu de sa commande par la suite ?
Ces failles existent vraiment, et il ne s’agit ici pas toujours de technique ou de code, mais bien de logique de processus et de contrôles logiques. La sécurité web commence dès la conception fonctionnelle de l’application.
Il convient donc de lister les différentes fonctions critiques de votre application web, et de s’assurer que la logique ne peut être contournée ou détournée. Il ne s’agit pas de vérifier que tout fonctionne bien dans les use cases prévus, mais de chercher à abuser des logiques en place afin de déceler des failles et les corriger par la suite.
6. Protéger les données sensibles
Premièrement, dressez un inventaire de toutes les données traitées dans votre application web : emails, mots de passe, coordonnées personnelles de vos utilisateurs, données de paiements, données de transactions.
Si vous avez peu de choses à protéger sur votre site Internet, le simple fait de voler un mot de passe d’un de vos utilisateurs peut être un point de départ pour un attaquant, ce mot de passe pouvant potentiellement être valable sur un autre site. Que vous soyez une grande multinationale ou un e-commerçant agissant seul et ayant peu de données, vos utilisateurs méritent que vous protégiez leurs données.
“Less is more” : Ne collectez des données sensibles que si nécessaires! Plus vous collectez de données, plus vous exposez vos utilisateurs à des dangers. Limiter le volume de données s’impose donc.
Il en va de même pour la durée de conservation des données sensibles. Avez vous besoin de conserver toutes les données ? Pour quelle durée ?
Comment traitez vous ces données ? Sont-elles collectées de manière sécurisée (formulaires soumettant les données au serveur en HTTPS) ? Comment transitent-elles d’un point à un autre, que ce soit en interne, ou avec des partenaires connectés à votre site internet.
Nous ne nous étendrons pas plus sur le sujet ici, mais une véritable politique de sécurité des données doit être établie et appliquée. De nombreuses resources à ce sujet existent et des sociétés peuvent vous conseiller sur le traitement des données. Nos services incluent ce type de revue technique.
7. Effectuer des revues de code orientées sécurité
La sécurité doit être incluse dans votre processus de développement d’applications web (Software Development Life Cycle – SDLC), avec en particulier des revues de code orientées sécurité, et pas seulement orientées architecture du code. Afin de pouvoir effectuer ces revues de code, des notions de sécurité web sont bien évidemment requises. Repasser sur un code sans connaître les potentielles failles ne débouchera pas sur de bons résultats.
Un bon point de départ est de lire, ou relire l’Owasp Top 10, ainsi que les diverses Cheat sheets, ce qui rappellera aux développeurs les bonnes pratiques liées à la sécurité et aiguisera leur regard sur les problématique de sécurité web. Les revues de code doivent être effectuées en équipe, avec des personnes n’ayant pas développé le code à revoir.
On peut également prévoir une « security check-list”, différente suivant les langages de programmation employés.
8. Effectuer un test d’intrusion web
Afin de s’assurer de la robustesse d’une application, rien de tel qu’un test d’intrusion (pentest). Le pentest permettra de voir quelles sont les failles présentes, de réaliser comment celles-ci peuvent être exploitées, et de voir à quel point une simple faille peut ouvrir une porte vers d’autres failles, voir la compromission totale d’un environnement web.
Un tel audit de sécurité permet de dresser à un instant T le niveau de sécurité d’une application.
9. Se préparer au pire
Sécuriser une application à 100% n’est pas possible, à moins de supprimer l’application, mais nous n’en arriverons bien entendu pas jusque là. La sécurité est un compromis, et a un coût. Il s’agit d’évaluer les risques et de mettre en face de chaque risque une réponse appropriée, un niveau de sécurité adéquat.
Régulièrement, de nouvelles failles de sécurité sont mises à jour et les bonnes pratiques aussi doivent évoluer. Le monde du web n’étant pas parfait, il convient donc d’anticiper l’imprévu, et donc de mettre en place une réponse au risque : “si mon site se fait tout de même attaquer…”.
Un plan de restauration doit être établi, pour faire face au pire : planifier les étapes à effectuer en cas de piratage, back-ups, restauration des données, actions à effectuer dans le cas où le site est défiguré suite à une attaque, identification de la source de l’attaque et du mode opératoire ayant été employé afin de corriger la faille qui a été exploitée, plan de communication.
10. Appliquer les étapes précédentes régulièrement
Nous arrivons au point numéro 10 : retour à la case départ! Les étapes précédentes doivent être effectuées régulièrement, la sécurité n’est pas réglée une fois pour toutes. Non seulement vos applications évoluent et il convient donc d’inspecter régulièrement celles-ci afin de vérifier si elles répondent toujours à vos critères de sécurité, mais d’autre part, des mesures de sécurité efficaces à un moment donné ne le seront pas forcément à vie. Les technologies évoluent, les attaques également. L’encodage MD5 était longtemps considéré comme une bonne pratique et comme un moyen sûr de protéger des données en les hashant avec cet algorithme; c’est maintenant faux.