L’Open Web Application Security Project (OWASP) est une organisation axée sur la communauté qui tente d’améliorer la sécurité de la programmation. La Fondation OWASP est le point d’accès pour les technologues et les développeurs Web pour protéger le Web contre les cyberattaques.
L’une des caractéristiques essentielles de l’OWASP est que ses programmes sont librement accessibles sur leur site, ce qui permet à quiconque de sécuriser son application Web. Le matériel qu’ils proposent comprend de la documentation, des appareils, des enregistrements et des forums. Cependant, leur projet le plus célèbre est le Top 10 de l’OWASP.
Principes fondamentaux du Top 10 de l’OWASP
Le Top 10 de l’OWASP est un rapport régulièrement mis à jour illustrant les problèmes de sécurité pour la sécurité des applications Web, traitant des dix dangers les plus élémentaires. Un groupe de spécialistes de la sécurité rassemble des informations de partout dans le monde. OWASP fait allusion au Top 10 comme un «record de sensibilisation» et ils suggèrent que toutes les organisations consolident le rapport dans leurs systèmes pour limiter et soulager les attaques de sécurité.
Vous trouverez ci-dessous les vulnérabilités applicatives du Top 10 de l’OWASP et proposent des solutions et des bonnes pratiques pour les arrêter ou les corriger.
1. Injection
Défauts d’injection, par exemple, SQL l’injection, l’injection LDAP et l’injection CRLF se produisent lorsqu’un pirate informatique envoie des informations non fiables à un médiateur qui sont exécutées en tant qu’ordre sans l’approbation appropriée. Les tests de sécurité des applications peuvent identifier rapidement les défauts d’injection.
2. Authentification et gestion de session interrompues
La vérification du client et de la session choisie par erreur pourrait permettre aux pirates de pirater des mots de passe, des clés ou des jetons de réunion ou prendre le contrôle des comptes Web du client pour voler leurs informations confidentielles. La vérification multiforme, par exemple, FIDO ou les applications validées, diminue le risque de vulnérabilités des applications.
3. Exposition des données sensibles
Les applications et les API qui ne sécurisent pas de manière appropriée les informations sensibles, par exemple, les informations budgétaires, les noms d’utilisateur et les mots de passe, pourraient permettre aux attaquants d’accéder à ces données pour soumettre une fausse déclaration ou prétendre l’identité de quelqu’un. Le cryptage des informations à l’arrêt et en cours de processus peut vous aider à accepter les directives de protection des informations.
4. Entité externe XML
Des processeurs XML mal conçus évaluent les références d’entités externes dans les archives XML. Les attaquants peuvent utiliser des éléments externes pour des attaques, y compris l’exécution de code à distance, et pour découvrir des données et des partages de documents SMB. Les tests de sécurité d’application statique (SAST) peuvent trouver ce problème en examinant les conditions et la conception.
5. Contrôle d’accès interrompu
Des limitations mal organisées ou manquantes sur les clients validés leur permettent d’accéder à une utilité ou à des informations non approuvées, par exemple, accéder aux dossiers d’autres clients, consulter des rapports confidentiels et modifier les informations et les droits d’accès. Les tests de pénétration sont fondamentaux pour distinguer les contrôles d’accès non utiles.
6. Mauvaise configuration de la sécurité
Ce danger fait allusion à une exécution inappropriée des contrôles proposés pour protéger les informations de l’application, par exemple, une mauvaise configuration des en-têtes de sécurité, des messages de spam contenant des informations d’importation (fuite de données), et ne pas réparer ou mettre à jour les cadres, les systèmes et les segments. Les tests de sécurité dynamique des applications (DAST) peuvent distinguer les erreurs de configuration, par exemple les API défectueuses.
7. Scripts intersites
Imperfections de script inter-pages Web (XSS) donner aux assaillants la possibilité d’injecter du contenu côté client dans l’application, par exemple, pour détourner les clients vers des sites nocifs. Développeur préparant des tests de sécurité supplémentaires pour aider les ingénieurs logiciels à empêcher les scripts intersites avec les meilleures procédures de codage prescrites, telles que le codage des informations et l’approbation des informations.
8. Désérialisation peu fiable
Des erreurs de désérialisation non fiables peuvent permettre à un attaquant d’exécuter du code dans l’application à distance, de modifier ou d’effacer des objets sérialisés (écrits dans un cercle), des attaques directes par infusion et d’augmenter les avantages. Les dispositifs de sécurité des applications peuvent reconnaître les défauts de désérialisation, mais les tests d’entrée sont la plupart du temps censés approuver le problème.
9. Utilisation de composants présentant des vulnérabilités connues
Aussi souvent que possible, les ingénieurs ne réalisent pas quelles parties open source et externes se trouvent dans leurs applications, ce qui rend difficile l’actualisation des composants lorsque de nouvelles faiblesses sont découvertes. Les pirates peuvent profiter d’un élément incertain pour prendre le contrôle du travailleur ou prendre des informations privées. L’examen de l’organisation logicielle conduit en même temps que l’enquête statique permet de distinguer les formes douteuses de composants.
10. Manque de journalisation et de surveillance
Une opportunité de distinguer une pause est habituellement estimée en semaines ou en mois. Une journalisation inadéquate et un mélange inefficace avec les cadres de réaction aux épisodes de sécurité permettent aux pirates de se tourner vers différents cadres et de faire des attaques fréquentes. Pensez comme un hacker et utilisez des tests au stylo pour voir si vous avez une observation adéquate; inspectez vos journaux après le test du stylo.
