TOP 10 D’OWASP
1- Attaques contre le control d’accès
a. L’attaque par découverte d’URL
Il faut toujours être conscient que l’attaquant peut accéder à n’importe quelle page en modifiant
l’URL par le bon identifiant
Exemple : /client-login.php il modifie avec /employee-login.php
b. L’attaque par références directes d’objets non sécurisées
Permet à l’attaquant toujours depuis l’URL d’accéder à une page dont il n’a pas le droit d’y accéder
par exemple
/employee ?id=23 il remplace par /employee ?id=1 et il a accès à la page d’administration
c. L’attaque CSRF (Cross-Site Request Forgery)
Transmettre une requête falsifiée à un utilisateur authentifié
Quelques recommandations :
Principes de moindre privilège
Vérifications d'accès côté serveur : Ne comptez jamais uniquement sur les contrôles côté
client
Utiliser des URL non prédictibles
Utiliser des jetons CSRF
Configurer le serveur pour le sécuriser
2- Défaillances cryptographiques
a. L’attaque par interception des requêtes http (Man in The Middle)
Les requêtes http ne sont pas chiffrées privilégier HTTPS, utiliser les algo de hachage, utiliser les aglo
de salage
3- Injection SQL
a. SQLi
Consiste à envoyer du code SQL dans un formulaire de l’application
b. Attaque cross-site-scripting (XSS)
Consiste à envoyer un script dans un formulaire pour qu’il se stocke dans le serveur
Quelques recommandations :
Validation stricte des entrées utilisateurs
Échappement des caractères spécifiques
Utiliser la validation des cookies http-only
Utiliser des ORM
4- Conception non sécurisée
Quelques recommandations :
Mettre en place un cycle de vie de développement : des frameworks, comme OpenSAMM (en
anglais) existent pour formuler des stratégies de sécurité des applications adaptées aux
risques spécifiques auxquels elles sont confrontées.
Mettre en place des tests unitaires et d’intégration automatisés : une couverture de code
complète, avec des tests automatisés, couplée à une logique de DevSecOps permettent de
réduire les risques.
Gérer de façon granulaire des ressources : Lors des phases de récupération des besoins
métier, il est important de bien recueillir et évaluer les exigences techniques et
fonctionnelles, dont la confidentialité des données de l’application. Ensuite, bien mettre en
place et appliquer une gestion sécurisée des droits d’accès.
Séparer les couches systèmes et réseau de l’application : en divisant le déploiement en sous-
systèmes modulaires ou en réseaux virtuels, il est plus facile de restreindre le niveau d'accès
à des données et des ressources spécifiques. Ainsi, il est difficile pour les pirates d'étendre
leur champ d'accès en cas d'attaque.
5- Utilisez des composants durcis et à jour
6- Empêchez le piratage de session
Quelques recommandations :
Authentification multifacteur (MFA)
Informations d'identification par défaut : Évitez d'utiliser des informations d'identification par
défaut, surtout pour les comptes privilégiés.
Gestion des mots de passe : Encouragez l'utilisation de mots de passe forts en intégrant des
tests lors de la création ou du changement de mot de passe. Comparez les mots de passe
saisis avec les listes de mots de passe faibles couramment utilisées pour prévenir les accès
non autorisés.
Gestion de session : Utilisez un gestionnaire de session côté serveur qui génère un nouvel
identifiant de session aléatoire avec une entropie élevée après la connexion. C’est-à-dire que
l’identifiant est très aléatoire et donc difficile à deviner pour les attaquants.
Assurez-vous que les identifiants de session ne soient pas exposés dans l'URL et qu'ils soient
invalidés après la déconnexion ou une période d'inactivité.
Protection contre les attaques d'énumération de compte : Durcissez les processus
d'inscription et de récupération des informations d'identification contre les attaques
d'énumération de compte, en utilisant des messages génériques pour tous les résultats afin
de ne pas révéler si un compte existe ou non.
Attributs Secure et HttpOnly : Utilisez l'attribut Secure pour s'assurer que les cookies sont
envoyés uniquement sur des connexions sécurisées (HTTPS).
Attribut SameSite : Cet attribut permet de contrôler l'envoi de cookies avec les requêtes inter-
sites, offrant une protection contre les attaques de type cross-site request forgery (CSRF).
Durée de vie limitée : Configurez une durée de vie limitée pour les cookies de session afin de
réduire la fenêtre d'opportunité pour les attaquants en cas de vol de cookie.
Utilisez des Frameworks de Sécurité Pour l'authentification, il est conseillé de s'appuyer sur
des frameworks éprouvés plutôt que de développer son propre système. Des solutions
offrent des méthodes d’authentification sécurisées et testées, telles que :
ASP.NET Core Identity Framework pour les applications .NET ;
Ruby Omniauth pour Ruby ;
Java JAAS pour Java ;
PHP PHPSec pour PHP.
7- Garantissez l’intégrité de vos données et logiciels
Il est important que vous effectuez systématiquement des vérifications sur les bibliothèques ou les
plug-ins avant la mise en place dans le code ou dans l’application.
Date de la dernière mise à jour : Il n’est pas impossible qu’un plug-in, ou une bibliothèque, ait
son développement abandonné, laissant des vulnérabilités potentiellement présentes.
Qui fournit l’élément ? Qui en est l’auteur ? Est-ce une entreprise reconnue, un indépendant
qui au contraire n’est pas connu pour ses contributions ? L’auteur a-t-il une activité régulière
autour de son code ?
La bibliothèque ou le plug-in est-il nécessaire ? Il serait dommage d’augmenter le risque de
vulnérabilité en installant une bibliothèque ou un plug-in alors que des mécanismes gérant la
même fonctionnalité sont déjà présents, dans un framework utilisé ou via un autre
composant déjà en place.
Le code source est-il disponible ? Y a-t-il une possibilité d’analyser le code pour être sûr de ne
pas créer d’effet de bord ?
À quelles ressources le composant a-t-il accès ? Les permissions demandées sont-elles
cohérentes avec la fonction ?
8- Carence des systèmes de contrôle et de journalisation
Il faut activer les logs
9- Falsification de Requête Côté Serveur (Server-Side Request Forgery, ou SSRF)
