La sécurisation des applications web (2/3)

Dans le précédent article sur la sécurisation des applications web nous avons vu comment sécuriser le code de vos applications. Maintenant nous allons voir comment sécuriser les middlewares. NOTE : cet article ne prétend pas être exhaustif mais uniquement vous donner des points de départ dans vos démarches. Aussi, si vous désirez approfondir, vous pouvez lire cet ouvrage.

Débloque les + belles offres tech en 10 mins

De la même manière que le code que vous écrivez peut contenir des failles de sécurité, les middlewares peuvent en contenir. Et ceux-ci affectent votre application directement. Par exemple, un bug du framework Spring Security permettait de prendre le contrôle de toutes les applications qui l’utilisaient ! Plutôt gênant, non ?

De l’importance d’avoir toujours des versions de middlewares supportées

Quand une faille de sécurité est découverte et publiée sur un logiciel ou un middleware, le premier réflexe de nombreux pirates est de tester si par hasard les anciennes versions de ce logiciel sont aussi impactées. Si c’est le cas, certains ne se priveront pas pour l’exploiter, même si la loi punit sévèrement une telle action.

Par ailleurs, pour certains composants, il est particulièrement aisé de connaître la version utilisée. Par exemple, les serveurs web envoient généralement leur version utilisée dans les headers. Il suffit des lors au pirate de consulter les alertes de sécurité relatives à la version dans des bases comme celle du CERT pour savoir quelles vulnérabilités alertent la version détectée et de chercher quelques exploits pour savoir comment utiliser ces failles à leur avantage.

Par conséquent, il convient d’avoir toujours une version supportée de vos middlewares. Par exemple, à l’heure actuelle, les versions supportées de Spring Framework sont la 4.0.2 et la 3.2.8.

Mais c’est dangereux de mettre à jour ! Je risque de casser mon appli !

Exact ! A première vue il est très difficile de garantir la non-régression d’une application quand on fait évoluer une des librairies qu’elle exploite. Et les alertes concernant ces dernières peuvent être fréquentes, parfois plusieurs par mois en fonction des middlewares utilisés. D’autant que Java a aussi ses propres failles, parfois critiques, et donc qu’il faut aussi tenir la JVM à jour.

Par conséquent, il est important d’automatiser au maximum les tests de votre application. Tout d’abord, le code de votre application doit avoir une couverture correcte en terme de tests unitaires, au minimum 80%. Ceci permettra de garantir au niveau du code que la mise à jour d’une librairie n’a rien cassé. Ensuite, il convient d’avoir des tests d’intégration, là encore automatisés, ainsi que des tests de charge pour assurer une non régression.

Par ailleurs, les tests d’intégration et de charge doivent être menés sur une plateforme de préproduction en tout point analogue à la production, afin de réduire au maximum les risques, et être testée pendant quelques jours pour s’assurer de la stabilité du nouvel ensemble.

Mais tout ça coûte cher !!!

Oui ça coûte cher, mais c’est un investissement. En effet, la qualité d’une application, tout comme sa sécurisation, représente un investissement qui sera toujours inférieur à la réparations des dégâts en cas de bug majeur ou de piratage de votre plateforme.

Pour donner un exemple, une ancienne entreprise où j’étais a commandé un jour un audit de sécurité sur une de leurs applications en production. Il se trouve que les middlewares de cette application n’étaient pas tenus à jour, et que l’application en elle-même n’était pas sécurisée. Eh bien… les hackers ont pu utiliser l’application, pourtant hébergée à l’extérieur de l’entreprise, pour aller jusqu’à pénétrer le réseau interne de l’entreprise ! Forcément, ça fait réfléchir…

Débloque les + belles offres tech en 10 mins

Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.

Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.

Son Twitter – Son LinkedIn