Les 7 dangers de cyber-sécurité à anticiper sur vos applications

1 - Les formulaires et URLs

En premier lieu, il faut s'assurer que les portes d'entrée sont bien verrouillées. Il faut contrôler que tous les formulaires et toutes les URLs (en particulier celles ayant des paramètres), filtrent correctement les données soumises par les utilisateurs. C'est le premier niveau de contrôle. Selon l'OWASP, les failles de sécurité les plus populaires exploitent l'une ou l'autre de ces "portes" (injection de code malicieux, XSS, CSRF...).

2 - Le code source de l'application

Il est primordial que l'application soit bien conçue, en adoptant l'ensemble des bonnes pratiques en termes de sécurité. Il est conseillé d'utiliser des frameworks proposant des APIs,  permettant aux développeurs de se focaliser sur le fonctionnel, tout en garantissant un très bon niveau de sécurité. Ces frameworks sont maintenus par des experts dans différents domaines (sécurité, performance...), ce qui nous permet de bénéficier d'outils fiables sur lesquels on peut se reposer.

Dans le cas où l'application utilise des librairies externes (librairies JS, librairies PHP...), il faut également s'assurer d'un bon niveau de sécurité pour chacune d'entre elles. La multiplication des librairies ne simplifie pas la maintenance du système. Dès lors qu'une des librairies est exploitable par un pirate, alors tout le site ou l'application est potentiellement impacté. Cette décentralisation des librairies augmente aussi la surface d'attaque.

3 - La gestion des connexions

Lorsque les utilisateurs sont connectés à un site, il est nécessaire de maintenir sa session, afin qu'il ne soit pas obligé de se reconnecter. La gestion des sessions utilisateurs est donc primordiale : une faille à ce niveau permettrait à un utilisateur de se connecter au site (ou l'application) sans avoir à connaître les identifiants de la cible (attention en particulier à la gestion des cookies et des identifiants de session). La gestion de l'authentification, du stockage des mots de passe et des sessions utilisateurs est critique et se doit de ne souffrir d'aucune faiblesse.

4 - Les sources embarquées et les CDNs

Depuis très longtemps maintenant, on a pris l'habitude d'afficher sur un site du contenu provenant d'un autre site. C'est le cas des vidéos provenant de YouTube, par exemple. Mais que se passe-t-il si cette source n'est pas fiable ou bien si elle-même est compromise par un piratage ? Nous risquons d'avoir également une faille de sécurité sur notre site ! Cependant il est impossible de contrôler ce type de contenus, et on doit faire confiance.

Le même type de problème peut arriver si l'on utilise des librairies en mode CDN. En particulier les ressources CSS et JS (Bootstrap ou autre) sont incluses depuis le serveur original. Si ce dernier subit une attaque réussie, rien ne garantit que les sources en partage ne soient modifiées volontairement. Par exemple, lorsque l'on fait appel à une librairie JavaScript externe hébergée sur un serveur, a-t-on la garantie que la ressource récupérée est bien celle attendue ? Le script a t-il été modifié dans le but de pirater les sites qui l'utilisent ? On met généralement en place les CSPs (Content Security Policy) pour limiter les sources utilisables par le site / l'application, et il est possible de vérifier l'empreinte de la source à chaque appel : avant d'inclure une ressource externe, on vérifie que son empreinte est toujours la même. Cela prouve que le fichier original n'a pas été altéré.

5 - Les échanges de données

Il est fondamental de bien sécuriser les échanges de données : la transmission des données est-elle fiable ? Quels protocoles sont utilisés ? Peut-on forcer une connexion non sécurisée ? Toutes ces questions doivent être adressées afin de garantir qu'aucun échange client/serveur ne peut être déchiffré. En pratique, cela nécessite l'installation d'un certificat SSL pour chiffrer les flux de données et la redirection du trafic HTTP vers HTTPS.

6 - Le serveur

Le serveur fonctionne également avec un certain nombre de logiciels. Cela peut être Linux, Kubernetes, Docker, PHP, système de gestion de base de données, Composer, Git, Java, NodeJS... Tous ont également potentiellement des failles en termes de sécurité. Même si ces dernières sont souvent plus difficilement exploitables, il ne faut pas les négliger. Tout logiciel comporte des failles et doit être régulièrement maintenu à jour.

La sécurité est essentielle également au niveau des accès au site et aux différents serveurs. Rien ne sert de sécuriser un site, si en même temps l'accès au serveur n'est lui-même pas sécurisé convenablement. Par exemple, on ne devrait pas pouvoir se connecter simplement avec un login et un mot de passe : utiliser plutôt une double authentification ou bien le protocole SSH (avec une clé unique).

7 - La gestion du code source

Le code source d'une application est systématiquement versionné, avec le plus souvent Git. Il est donc essentiel de limiter les accès aux différents repos et de vérifier qui est autorisé à récupérer ou mettre à jour le code source. Le système Git est très fiable et ne souffre d'aucune critique vis à vis de la sécurité (jusqu'à présent). Il est donc à privilégier. Tout le code applicatif versionné ne doit jamais contenir de données sensibles : login, mot de passe, clé d'API... Ces données sensibles doivent être hébergées sur les serveurs et rendues inaccessibles de l’extérieur. Elles ne doivent jamais transiter entre les différents environnements.

Sécuriser un site web va bien au-delà de l'application elle-même. Il faut prendre en compte tout l'environnement de travail : serveur, flux de données, sources de données, méthode de production, outils internes... L'empilement de technologies ne simplifie pas forcément le maintien d'un bon niveau de sécurité. Chaque brique doit être fiable et une seule défaillance peut mettre en danger le site. Il est donc nécessaire de s'assurer que tous les logiciels utilisés n'ont pas de failles de sécurité connues et qu'ils sont toujours maintenus. Des mises à jour régulières sont indispensables dans ce sens.