Comment protéger votre entreprise des cyber-attaques de base?
Cet article a pour but de sensibiliser les développeurs d'applications informatiques à "penser sécurité" à chaque phase du projet. Lors de mes missions de scrum master, je vois trop souvent, lors de mes revues de codes, des attributs en PUBLIC au lieu de PRIVATE non justifiés. La sécurité informatique, ça commence par là.
Ensuite, lorsqu'il est trop tard, que les applications Web sont corrompues, d'énormes quantités des données commerciales sensibles peuvent être perdues. Selon Verizon 2014 Data Breach Investigations Report, les attaques d'applications web ont plus que doublé en 2013 pour devenir la cause n ° 1 des incidents de sécurité.
Classement des incidents types:
Attaques à distance sur les transactions: 14%
Attaques des applications web: 35%
Mauvaise utilisation des ressources IT des collborateurs: 8%
Vol et pertes physiques: 1%
Erreurs diverses: 2%
Logiciel malveillant: 4%
Fraude à la carte de crédit: 9%
Attaque de déni de service: 1%
Cyber espionnage: 22%
Tout le reste: 6%
D'après l'enqupête de Verizon sur les failles de sécurité.
Pour les seuls printemps et été 2013, les incidents de sécurité Web d’envergure ont été nombreux. Les attaquants sont parvenus à dérober des mots de passe d’un site du NASDAQ, soit la deuxième attaque contre ce marché financier au cours de ces dernières années.
Peu de temps après, le site Web des développeurs Apple a été attaqué, ce qui a entraîné l’exposition des noms des développeurs enregistrés et de leurs adresses électroniques.
Les applications Web sont des cibles privilégiées car :
-Elles sont accessibles par presque tout le monde depuis n’importe où.
-Elles fournissent un accès à un volume énorme de précieuses données.
-Elles sont généralement truffées de failles.
Comme beaucoup d’entreprises, vos équipes informatique et de développement ont très peu de temps et de ressources pour les tests de sécurité, surtout pour ceux à réaliser manuellement. En outre, lorsqu’ils sont effectués, ces tests se concentrent généralement sur les applications Web les plus utilisées et délaissent donc la sécurité d’autres applications. Et même dans ce cas, les tests peuvent être aléatoires si bien que des vulnérabilités peuvent s’introduire incognito et ouvrir la porte à des exploits.
L’impact financier de ces exploits est non négligeable. En effet, selon une étude sur le coût des fuites de données réalisée par le Ponemon Institute en 2013, les failles identifiées aux seuls États-Unis ont coûté 188 dollars (138 euros) par enregistrement volé, soit un coût total moyen de 5,4 millions de dollars par incident. Heureusement, la plupart des attaques contre les applications Web sont lancées selon un scénario assez classique.
Une question? Posez-la ici
Les vulnérabilités des applications web les plus courantes
À l’instar d’autres failles applicatives, celles qui affectent la sécurité des applications Web surviennent lors du développement du logiciel. La liste des 10 principales vulnérabilités au sein des applications Web du classement OWASP (Open Web Application Security Project) fournit le standard de fait pour classer par catégorie les vulnérabilités affectant les applications Web (voir Annexe). Les types les plus courants sont notamment :
Le script intersite (Cross-Site Scripting - XSS)
C'est l’une des vulnérabilités les plus répandues et dangereuses au sein des applications Web. Le script XSS peut avoir un impact considérable sur votre entreprise dans la mesure où il permet à des attaquants d’envoyer du code malveillant aux navigateurs Web des utilisateurs en se faisant passer pour une application métier légitime. Ainsi, des scripts peuvent être exécutés sur les navigateurs ciblés afin de détourner une session ou de télécharger des programmes malveillants qui pourront prendre totalement le contrôle du système. Des chercheurs ont découvert des vulnérabilités XSS sur les sites Web de fournisseurs de sécurité, de places de marché, de fournisseurs de solutions de paiement, de commerçants et de réseaux sociaux.
Les injections de code
Les attaques par injection de codes se présentent sous de nombreuses et différentes formes, notamment des injections de codes SQL et de commandes (en insérant des commandes système dans un champ de formulaire). Les attaques par injection de codes SQL sont parmi les plus fréquentes. Les attaquants envoient du contenu mal formaté à votre application (par exemple en ajoutant des caractères supplémentaires aux extrémités d’un champ de saisie), lequel s’infiltre ensuite dans une base de données. L’entrée volontairement mal formatée trompe la base de données en renvoyant des informations excessives ou en exécutant des actions non souhaitées. Ce type d’attaque a été utilisé pour divulguer des centaines de millions d’enregistrements contenant des informations personnelles identifiables et des données de carte de crédit. Ces attaques peuvent aussi être utilisées pour modifier ou supprimer des données sensibles, parfois sans que l’entreprise compromise ne le sache jamais.
Heureusement, il est possible de combattre ces attaques et autres vulnérabilités en s’appuyant sur des meilleures pratiques efficaces et de nouvelles technologies automatisées. Six éléments essentiels pour la sécurité des applications.
Comme beaucoup d’entreprises, vos équipes informatique et de développement ont peu de temps et de ressources à consacrer pour réaliser des tests de sécurité.
7 trucs essentiels pour la sécurité des applications Web
1) Une sensibilisation de tous les acteurs
Un membre de la direction de l’entreprise (ou un scrum master indépendant) affichant clairement son soutien est indispensable au succès des initiatives de sécurité concernant les applications Web. La sécurité de ces applications exige une collaboration permanente entre les équipes concernées : Directeurs commerciaux, responsables informatique mais aussi les équipes chargées du développement, des opérations et de la sécurité. Un haut management investi facilite une telle collaboration et le déblocage des ressources nécessaires.
2) Une discipline de développement
La sécurité des applications ne peut pas être tout simplement mise en place d'un coup de baguette magique à la fin du projet. Elle doit être intégrée au processus de développement et appliquée à des phases clés. En effet, la sécurité devrait être prise en compte de manière explicite lors de la définition des spécifications techniques de l’application, de la programmation, de la phase d’assurance-qualité et du passage des applications en mode production.
3) La formation des développeurs
Pas moyen d’y échapper : un code informatique sécurisé est un atout intrinsèque qui exige la formation des développeurs. Lorsque notamment les développeurs et les administrateurs de serveurs créent et déploient des applications, il est vital que ces acteurs sachent d’où proviennent les failles de sécurité. Une récente étude du Ponemon Institute révèle que plus que la moitié des développeurs interrogés n’ont suivi aucune formation formelle en matière de sécurité applicative. Il est difficile de rendre les applications résilientes aux attaques si l’on ne sait pas quoi rechercher, même en étant équipé des bons outils, ce qui n’est pas encore le cas de la plupart des entreprises. Six éléments essentiels pour la sécurité des applications.
4) La modélisation des menaces
Cartographier les potentielles menaces. Avant de pouvoir protéger vos applications, données et autres actifs informatiques, il vous faut maîtriser les fondamentaux d’une attaque potentielle. Il est plus particulièrement crucial de savoir qui pourrait avoir la motivation, l’opportunité et les moyens d’attaquer. Par exemple, quelles données gérées par votre application pourraient intéresser des gouvernements étrangers, des concurrents ou encore des criminels appâtés par les gains financiers ? Il existe des équipes de pirates très puissantes, comme la "hacking team" Les membres sont très discrets, vous êtes peut-être en relation avec eux. sans le savoir. Gilles Giraud, Emmanuel Polonowski, Fabrice Mourlin, Samuel Dartiguepeyrou, Joan Le Goff, Delphine Adam, Bernard Marchal, vous demandent si votre application est accessible depuis des réseaux publics ou uniquement au sein d’environnements d’entreprise bien contrôlés ? Quelles technologies seront nécessaires (authentification, chiffrement, stockage de données et intégration à d’autres systèmes) et comment pourraient-elles être victimes d’exploits ? Les modèles de menace réunissent toutes ces informations pour que les développeurs puissent anticiper et concevoir une application plus sécurisée dès sa genèse.
"Le monde ne sera pas détruit par ceux qui font le mal, mais par ceux qui les regardent sans rien faire." Albert Einstein.
5) L’automatisation des tests
Même si un grand nombre de problèmes peuvent être évités en intégrant la sécurité dès la phase de développement, certaines vulnérabilités finiront inévitablement par s’introduire. D’où l’intérêt de disposer d’outils et d’une technologie pour sécuriser les applications. Chercher les problèmes de sécurité au sein des applications Web exige bien plus qu’une simple analyse du code. Grâce aux nouvelles générations d’outils manuels et automatisés, vos développeurs, testeurs ainsi que votre équipe d’exploitation peuvent plus que jamais renforcer la sécurité des applications :
Les outils de test statique de sécurité des applications (SAST)
Ils examinent le code applicatif « statique » de base pour y détecter des types spécifiques d’erreurs de programmation, notamment des bombes logiques, des injections de codes SQL, des dépassements de mémoire tampon et autres failles. C’est à un analyste qualifié et qui maîtrise le code et les processus métier à déployer qu’il incombe généralement d’examiner les résultats. Cette analyse interactive est particulièrement pertinente lors de la phase de développement et d’analyse des applications écrites dans un langage de support, ce qui permet de détecter des problèmes spécifiques.
Les technologies de test dynamique de sécurité des applications (DAST)
Elles analysent le retour des applications en cours d’exécution, c’est-à-dire de manière « dynamique » en interagissant avec les applications tout comme un attaquant le ferait. Ceci permet de tester les conditions qui ne peuvent être détectées que dans les cas d’utilisation réelle, notamment les problèmes liés au contrôle d’accès. Les tests DAST sont utilisés sur des applications écrites dans un quelconque langage et tout au long du cycle de vie de l’application : développement, assurance-qualité et production. De plus, ces tests permettent de tester l’infrastructure sous-jacente des applications Web et pas uniquement les parties pour lesquelles du code est disponible.
Les entreprises qui mettent en oeuvre ces deux stratégies utilisent souvent des outils SAST manuels pour vérifier la logique de leurs principales applications et des systèmes de test DAST automatisés pour tester le comportement de manière répétée. Désormais, de nouveaux systèmes DAST dans le Cloud vous permettent de tester un grand nombre d’applications rapidement, sans les coûts ni la complexité liés à l’installation de logiciels sur site. Ainsi, vous pouvez tester en permanence l’ensemble de vos applications, et non pas uniquement certaines, même dans des environnements de production.
Une question? Posez-la ici
6) Le blocage des attaques
Dans l’idéal, les applications devraient toujours être parfaitement sécurisées. Cependant, dans la réalité, des bogues se produisent et des vulnérabilités apparaissent de manière inévitable.
Mais résoudre et déployer des modifications sur des applications prend du temps, et dans l’hypothèse où cela reste possible.
Pendant ce temps, votre activité ou vos clients sont vulnérables aux attaques. C’est donc ici qu’interviennent les pare-feux pour applications Web (WAF). Ces derniers vous donnent du temps pour résoudre les problèmes en bloquant automatiquement certaines attaques contre les applications Web, notamment les scripts intersite (XSS).
Les pare-feux WAF se déploient en amont de vos applications Web pour examiner le trafic HTTP échangé entre le navigateur de l’utilisateur et votre application. Les requêtes et les réponses qui semblent inadéquates sont bloquées ou modifiées. Des caractéristiques inhabituelles, telles que des valeurs malveillantes présentes à l’extrémité de chaînes de saisie, peuvent être supprimées pour que les applications ne voient que l’entrée valide saisie par l’utilisateur. En outre, les pare-feux WAF permettent de limiter l’accès depuis des réseaux indésirables ou suspects et aussi de modifier le mode de communication entre les navigateurs et les applications, par exemple en ajoutant l’en-tête Strict-Transport-Security pour demander aux navigateurs de toujours se connecter via des sessions HTTPS chiffrées. Le tout sans devoir modifier l’application ni reconfigurer chaque serveur Web.
Qui plus est, les pare-feux WAF peuvent protéger votre entreprise contre les vulnérabilités hébergées au sein d’applications tierces le temps que les fournisseurs travaillent à leur résolution. Vous pouvez même utiliser des pare-feux WAF pour protéger votre activité lorsque vous utilisez des applications fournies sous la forme de service (SaaS), qui sont partagées et dont les conditions de service vous interdisent d’effectuer des scans de vulnérabilité. Et aussi lorsque les fournisseurs n’appliquent pas assez rapidement les correctifs de sécurité importants sur leur service.
7) Offrez un audit scrum-master à votre équipe de développeurs
Conclusion
La planification et l’automatisation dans le Cloud rendent possible la protection globale des applications Web.
Tout comme il n’existe aucune solution miracle pour la sécurité informatique, il n’y a pas qu’une seule façon d’atténuer toutes les vulnérabilités qui affectent les applications Web. Heureusement, la stratégie utilisée par nombre d’entreprises gagnantes peut vous mettre sur le bon chemin.
Commencez par poser les fondements pour obtenir le soutien des dirigeants de l’entreprise, impliquer la sécurité au sein des processus de développement, former les développeurs de logiciels pour éviter les problèmes de sécurité et identifier les sources possibles de menaces. Grâce à toutes ces informations, vous pourrez tirer parti de la nouvelle génération de technologies de test et de protection, notamment les outils de test SAST et DAST ainsi que les pare-feux WAF.
La simplicité et la rentabilité des solutions dans le Cloud assurent notamment une protection de haut niveau là où ce n’était jusqu’à maintenant pas envisageable. Désormais, vous pouvez lancer une évaluation automatisée des vulnérabilités et utiliser et administrer des pare-feux pour applications Web directement depuis le Cloud pour sécuriser toutes vos applications partout dans le monde.
Ensemble, ces pratiques et technologies essentielles peuvent vous aider ainsi que votre entreprise à réduire sensiblement le risque de sécurité des applications Web.
Pour plus d’informations sur Qualys et la manière dont la suite intégrée de solutions de sécurité et de conformité de la plate-forme QualysGuard dans le Cloud peut aider votre entreprise à sécuriser vos applications Web et à réduire les risques de failles ou pour tester le service QualysGuard Web Application Scanning (WAS) ou le pare-feu pour applications Web QualysGuard (WAF) avec vos propres applications, rendez-vous sur qualys.com/was ou sur qualys.com/waf
Une question? Posez-la ici
Bonus: classement OWASP des 10 principales vulnérabilités au sein des applications Web
Injection
Des failles liées à des injections notamment SQL, d’OS et LDAP se produisent lors de l’envoi de données non dignes de confiance à un interpréteur en tant qu’élément de commande ou de requête. Les données hostiles envoyées par l’attaquant peuvent duper l’interpréteur et lui faire exécuter des commandes inattendues ou accéder à des données sans autorisation appropriée.
Violation de la gestion de l’authentification et de la session
Des fonctions applicatives associées à la gestion de l’authentification et de la session sont souvent déployées de manière incorrecte. Les attaquants peuvent alors compromettre des mots de passe, des clés ou des jetons de session ou encore exploiter d’autres failles pour prendre l’identité d’autres utilisateurs.
Script intersite (XSS)
Des failles XSS se produisent chaque fois qu’une application envoie des données non dignes de confiance à un navigateur Web sans validation ou échappement de données approprié. Grâce à XSS, les attaquants peuvent exécuter des scripts dans le navigateur de la victime pour détourner des sessions utilisateur, défigurer des sites Web ou rediriger l’utilisateur vers des sites malveillants.
Référence directe non sécurisée à un objet
Il y a référence directe à un objet lorsqu’un développeur expose une référence à un objet de déploiement interne notamment un fichier, un répertoire ou une clé de base de données. Sans une vérification du contrôle d’accès ou une autre protection, les attaquants peuvent manipuler ces références pour accéder à des données non autorisées.
Mauvaise configuration de la sécurité
Une bonne sécurité impose de définir et de déployer une configuration sécurisée pour l’application, l’infrastructure, le serveur d’applications, le serveur Web, le serveur de bases de données et la plate-forme. Des paramètres sécurisés doivent être définis, déployés et mis à jour car ceux par défaut sont souvent non fiables. De plus, le logiciel doit être mis à jour.
Exposition de données sensibles
Nombreuses sont les applications Web qui ne protègent pas correctement les données sensibles, notamment celles des cartes de crédit, les identifiants fiscaux et les certificats d’authentification. Les attaquants peuvent dérober ou modifier ces données faiblement protégées pour utiliser des cartes bancaires de manière frauduleuse, usurper des identités ou perpétrer d’autres crimes. Les données sensibles méritent une protection supplémentaire telle que le chiffrement des données au repos ou en transit ainsi que des précautions particulières lorsque ces mêmes données sont échangées avec le navigateur.
Manque de contrôle d’accès au niveau fonctionnel
La plupart des applications Web vérifient les droits d’accès au niveau fonctionnel avant de rendre cette fonctionnalité visible dans l’interface utilisateur. Cependant, les applications doivent exécuter les mêmes vérifications de contrôle d’accès sur le serveur lors de l’accès à chaque fonction. Si les requêtes ne sont pas vérifiées, les attaquants pourront falsifier des requêtes pour accéder, sans autorisation appropriée, à des fonctionnalités.
Falsification de requête intersite (CSRF)
Une attaque CSRF contraint le navigateur de la victime connectée à envoyer vers une application Web vulnérable une requête HTTP falsifiée, y compris le cookie de session de la victime et toute autre information d’authentification automatiquement incluse. L’attaquant peut ainsi forcer le navigateur de la victime à générer des requêtes que l’application vulnérable considère comme envoyées légitimement par la victime.
Utilisation de composants avec des vulnérabilités connues
Les composants tels que les bibliothèques, les infrastructures et autres modules logiciels sont presque toujours exécutés à l’aide de privilèges complets. Si un composant vulnérable est exploité, une telle attaque peut entraîner une sérieuse perte de données ou une prise de contrôle du serveur. Les applications utilisant des composants avec des vulnérabilités connues peuvent fragiliser les défenses d’une application et ouvrir la porte à tout un éventail d’attaques et de conséquences.
Redirections et renvois non validés
Les applications Web redirigent et renvoient souvent les utilisateurs vers d’autres pages et sites Web. Elles utilisent des données non fiables pour déterminer les pages de destination. Sans validation adéquate, les attaquants peuvent rediriger les victimes vers des sites de phishing ou contenant des programmes malveillants ou encore utiliser des renvois pour accéder à des pages non autorisées.
Support Top 10 vulnérabilités web 2013 OWASP
Le document a été mis à jour avec la dernière version de 2017.
Merci à Qualys et Owasp sponsors de ce transcript.
Ce transcript reflète exclusivement l'opinion de ses auteurs et n’engage en aucune façon Consultingit.