OWASP ou Open Web Security Project est une organisation caritative à but non lucratif axée sur l'amélioration de la sécurité des logiciels et des applications Web.
L'organisation publie une liste des principales vulnérabilités de sécurité Web sur la base des données de diverses organisations de sécurité.
Les vulnérabilités de sécurité Web sont classées par ordre de priorité en fonction de leur exploitabilité, de leur détectabilité et de leur impact sur les logiciels.
- Exploitabilité -
Que faut-il pour exploiter la vulnérabilité de sécurité? Exploitabilité la plus élevée lorsque l'attaque n'a besoin que d'un navigateur Web et la plus basse étant une programmation et des outils avancés.
- Détectabilité -
Est-il facile de détecter la menace? Le plus élevé étant les informations affichées sur l'URL, le formulaire ou le message d'erreur et le plus bas étant le code source.
- Impact ou dommage -
Combien de dommages seront causés si la vulnérabilité de sécurité est exposée ou attaquée? Le plus élevé étant un crash système complet et le plus bas n'étant rien du tout.
L'objectif principal de OWASP Top 10 est de sensibiliser les développeurs, concepteurs, gestionnaires, architectes et organisations aux vulnérabilités de sécurité les plus importantes.
Les 10 principales vulnérabilités de sécurité selon le Top 10 de l'OWASP sont:
- Injection SQL
- Scripts intersites
- Authentification et gestion de session interrompues
- Références directes d'objets non sécurisées
- Falsification de demande intersite
- Mauvaise configuration de la sécurité
- Stockage cryptographique non sécurisé
- Échec de la restriction de l'accès à l'URL
- Protection insuffisante de la couche de transport
- Redirections et transferts non validés
Injection SQL
Description
L'injection est une vulnérabilité de sécurité qui permet à un attaquant de modifier les instructions SQL du backend en manipulant les données fournies par l'utilisateur.
L'injection se produit lorsque l'entrée de l'utilisateur est envoyée à un interpréteur dans le cadre d'une commande ou d'une requête et incite l'interpréteur à exécuter des commandes involontaires et donne accès à des données non autorisées.
La commande SQL qui, lorsqu'elle est exécutée par une application Web, peut également exposer la base de données principale.
Implication
- Un attaquant peut injecter du contenu malveillant dans les champs vulnérables.
- Les données sensibles telles que les noms d'utilisateur, les mots de passe, etc. peuvent être lues à partir de la base de données.
- Les données de la base de données peuvent être modifiées (Insérer / Mettre à jour / Supprimer).
- Les opérations d'administration peuvent être exécutées sur la base de données
Objets vulnérables
- Champs de saisie
- URL interagissant avec la base de données.
Exemples:
- Injection SQL sur la page de connexion
Se connecter à une application sans avoir d'informations d'identification valides.
Un nom d'utilisateur valide est disponible et le mot de passe n'est pas disponible.
URL de test: http://demo.testfire.net/default.aspx
Nom d'utilisateur: sjones
Mot de passe: 1 = 1 'ou pass123
Requête SQL créée et envoyée à l'interpréteur comme ci-dessous
SELECT * FROM Users WHERE User_Name = sjones AND Password = 1 = 1 'ou pass123;
Recommandations
- Liste blanche des champs de saisie
- Évitez d'afficher des messages d'erreur détaillés utiles à un attaquant.
Scripts intersites
Description
Le Cross Site Scripting est également connu sous le nom de XSS.
Les vulnérabilités XSS ciblent les scripts intégrés dans une page qui sont exécutés côté client, c'est-à-dire navigateur utilisateur plutôt que côté serveur. Ces failles peuvent survenir lorsque l'application prend des données non fiables et les envoie au navigateur Web sans validation appropriée.
Les attaquants peuvent utiliser XSS pour exécuter des scripts malveillants sur les utilisateurs dans ce cas les navigateurs victimes. Étant donné que le navigateur ne peut pas savoir si le script est fiable ou non, le script sera exécuté et l'attaquant peut détourner les cookies de session, altérer les sites Web ou rediriger l'utilisateur vers des sites Web indésirables et malveillants.
XSS est une attaque qui permet à l'attaquant d'exécuter les scripts sur le navigateur de la victime.
Implication:
- En utilisant cette vulnérabilité de sécurité, un attaquant peut injecter des scripts dans l'application, voler des cookies de session, endommager des sites Web et exécuter des logiciels malveillants sur les machines de la victime.
Objets vulnérables
- Champs de saisie
- URL
Exemples
1. http://www.vulnerablesite.com/home?" < script > alert( " xss") script >
Le script ci-dessus lorsqu'il est exécuté sur un navigateur, une boîte de message s'affiche si le site est vulnérable à XSS.
L'attaque la plus sérieuse peut être effectuée si l'attaquant souhaite afficher ou stocker un cookie de session.
2. http://demo.testfire.net/search.aspx?txtSearch
Le script ci-dessus lors de son exécution, le navigateur chargera un cadre invisible pointant vers http://google.com .
L'attaque peut être rendue sérieuse en exécutant un script malveillant sur le navigateur.
Recommandations
- Champs de saisie de la liste blanche
- Codage d'entrée-sortie
Authentification et gestion de session interrompues
Description
Les sites Web créent généralement un cookie de session et un identifiant de session pour chaque session valide, et ces cookies contiennent des données sensibles telles que nom d'utilisateur, mot de passe, etc. il devrait y avoir un nouveau cookie.
Si les cookies ne sont pas invalidés, les données sensibles existeront dans le système. Par exemple, un utilisateur utilisant un ordinateur public (Cyber Cafe), les cookies du site vulnérable sont assis sur le système et exposés à un attaquant. Un attaquant utilise le même ordinateur public après un certain temps, les données sensibles sont compromises.
De la même manière, un utilisateur utilisant un ordinateur public, au lieu de se déconnecter, ferme brusquement le navigateur. Un attaquant utilise le même système, lorsqu'il navigue sur le même site vulnérable, la session précédente de la victime sera ouverte. L'attaquant peut faire tout ce qu'il veut: voler des informations de profil, des informations de carte de crédit, etc.
Une vérification doit être effectuée pour déterminer la force de l'authentification et de la gestion de session. Les clés, les jetons de session, les cookies doivent être mis en œuvre correctement sans compromettre les mots de passe.
Objets vulnérables
- Les identifiants de session exposés sur l'URL peuvent conduire à une attaque de fixation de session.
- Identifiants de session identiques avant et après la déconnexion et la connexion.
- Les délais d'expiration de session ne sont pas correctement mis en œuvre.
- L'application attribue le même ID de session pour chaque nouvelle session.
- Les parties authentifiées de l'application sont protégées à l'aide de SSL et les mots de passe sont stockés au format haché ou crypté.
- La session peut être réutilisée par un utilisateur peu privilégié.
Implication
- En utilisant cette vulnérabilité, un attaquant peut détourner une session, obtenir un accès non autorisé au système qui permet la divulgation et la modification d'informations non autorisées.
- Les sessions peuvent être prises à l'aide de cookies volés ou de sessions utilisant XSS.
Exemples
- L'application de réservation aérienne prend en charge la réécriture d'URL, en plaçant les identifiants de session dans l'URL:
http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Vente de billets pour les Maldives)
Un utilisateur authentifié du site souhaite informer ses amis de la vente et lui envoie un e-mail. Les amis reçoivent l'identifiant de session et peuvent être utilisés pour effectuer des modifications non autorisées ou utiliser à mauvais escient les détails de la carte de crédit enregistrée.
- Une application est vulnérable à XSS, par lequel un attaquant peut accéder à l'ID de session et peut être utilisé pour détourner la session.
- Les délais d'expiration des applications ne sont pas définis correctement. L'utilisateur utilise un ordinateur public et ferme le navigateur au lieu de se déconnecter et s'éloigne. L'attaquant utilise le même navigateur quelque temps plus tard et la session est authentifiée.
Recommandations
- Toutes les exigences d'authentification et de gestion de session doivent être définies conformément à la norme de vérification de la sécurité des applications OWASP.
- N'exposez jamais d'informations d'identification dans les URL ou les journaux.
- De gros efforts doivent également être faits pour éviter les failles XSS qui peuvent être utilisées pour voler des identifiants de session.
Références directes d'objets non sécurisées
Description
Cela se produit lorsqu'un développeur expose une référence à un objet d'implémentation interne, tel qu'un fichier, un répertoire ou une clé de base de données comme dans URL ou en tant que paramètre FORM. L'attaquant peut utiliser ces informations pour accéder à d'autres objets et peut créer une future attaque pour accéder aux données non autorisées.
Implication
- Grâce à cette vulnérabilité, un attaquant peut accéder à des objets internes non autorisés, modifier des données ou compromettre l'application.
Objets vulnérables
- Dans l'URL.
Exemples:
La modification de "userid" dans l'URL suivante peut amener un attaquant à afficher les informations d'autres utilisateurs.
http://www.vulnerablesite.com/userid=123 Modifié en http://www.vulnerablesite.com/userid=124
Un attaquant peut afficher d'autres informations en modifiant la valeur de l'ID utilisateur.
Recommandations:
- Mettre en œuvre des contrôles de contrôle d'accès.
- Évitez d'exposer des références d'objet dans les URL.
- Vérifiez l'autorisation de tous les objets de référence.
Falsification de demande intersite
Description
La falsification de demande intersite est une demande falsifiée provenant du site intersite.
L'attaque CSRF est une attaque qui se produit lorsqu'un site Web, un e-mail ou un programme malveillant amène le navigateur d'un utilisateur à effectuer une action indésirable sur un site de confiance pour lequel l'utilisateur est actuellement authentifié.
Une attaque CSRF force le navigateur d'une victime connectée à envoyer une requête HTTP falsifiée, y compris le cookie de session de la victime et toute autre information d'authentification automatiquement incluse, à une application Web vulnérable.
Un lien sera envoyé par l'attaquant à la victime lorsque l'utilisateur clique sur l'URL lorsqu'il est connecté au site Web d'origine, les données seront volées sur le site Web.
Implication
- L'utilisation de cette vulnérabilité en tant qu'attaquant peut modifier les informations du profil utilisateur, changer le statut, créer un nouvel utilisateur pour le compte de l'administrateur, etc.
Objets vulnérables
- Page de profil utilisateur
- Formulaires de compte utilisateur
- Page de transaction commerciale
Exemples
La victime est connectée au site Web d'une banque en utilisant des informations d'identification valides. Il reçoit un courrier d'un attaquant disant "Veuillez cliquer ici pour faire un don de 1 $ à la cause."
Lorsque la victime clique dessus, une demande valide sera créée pour donner 1 $ à un compte particulier.
http://www.vulnerablebank.com/transfer.do?account=cause&amount=1
L'attaquant capture cette requête et crée la requête ci-dessous et l'intègre dans un bouton disant «Je soutiens la cause».
http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000
Étant donné que la session est authentifiée et que la demande arrive via le site Web de la banque, le serveur transfère 1000 dollars à l'attaquant.
Recommandation
- Mandater la présence de l'utilisateur lors de l'exécution d'actions sensibles.
- Mettez en œuvre des mécanismes tels que CAPTCHA, la ré-authentification et les jetons de demande uniques.
Mauvaise configuration de la sécurité
Description
La configuration de la sécurité doit être définie et déployée pour l'application, les infrastructures, le serveur d'applications, le serveur Web, le serveur de base de données et la plate-forme. S'ils sont correctement configurés, un attaquant peut avoir un accès non autorisé à des données ou des fonctionnalités sensibles.
Parfois, ces défauts entraînent une compromission complète du système. Garder le logiciel à jour est également une bonne sécurité.
Implication
- En utilisant cette vulnérabilité, l'attaquant peut énumérer la technologie sous-jacente et les informations sur la version du serveur d'applications, les informations de la base de données et obtenir des informations sur l'application pour lancer quelques attaques supplémentaires.
Objets vulnérables
- URL
- Champs de formulaire
- Champs de saisie
Exemples
- La console d'administration du serveur d'applications est automatiquement installée et n'est pas supprimée. Les comptes par défaut ne sont pas modifiés. L'attaquant peut se connecter avec des mots de passe par défaut et obtenir un accès non autorisé.
- La liste de répertoires n'est pas désactivée sur votre serveur. L'attaquant découvre et peut simplement lister les répertoires pour trouver n'importe quel fichier.
Recommandations
- Une architecture d'application solide qui assure une bonne séparation et une bonne sécurité entre les composants.
- Modifiez les noms d'utilisateur et les mots de passe par défaut.
- Désactivez les listes de répertoires et implémentez des contrôles de contrôle d'accès.
Stockage cryptographique non sécurisé
Description
Le stockage cryptographique non sécurisé est une vulnérabilité courante qui existe lorsque les données sensibles ne sont pas stockées en toute sécurité.
Les informations d'identification de l'utilisateur, les informations de profil, les détails de santé, les informations de carte de crédit, etc. relèvent des informations de données sensibles sur un site Web.
Ces données seront stockées dans la base de données de l'application. Lorsque ces données sont stockées de manière incorrecte en n'utilisant pas de cryptage ou de hachage *, elles seront vulnérables aux attaquants.
(* Le hachage est la transformation des caractères de chaîne en chaînes plus courtes de longueur fixe ou une clé. Pour déchiffrer la chaîne, l'algorithme utilisé pour former la clé doit être disponible)
Implication
- En utilisant cette vulnérabilité, un attaquant peut voler, modifier ces données faiblement protégées pour mener un vol d'identité, une fraude par carte de crédit ou d'autres crimes.
Objets vulnérables
- Base de données d'application.
Exemples
Dans l'une des applications bancaires, la base de données de mots de passe utilise des hachages non salés * pour stocker les mots de passe de tout le monde. Une faille d'injection SQL permet à l'attaquant de récupérer le fichier de mots de passe. Tous les hachages non salés peuvent être forcés brutalement en un rien de temps alors que les mots de passe salés prendraient des milliers d'années.
(* Hashs non salés - Le sel est une donnée aléatoire ajoutée aux données d'origine. Le sel est ajouté au mot de passe avant le hachage)
Recommandations
- Assurer des algorithmes standard solides et appropriés. Ne créez pas vos propres algorithmes cryptographiques. Utilisez uniquement des algorithmes publics approuvés tels que AES, la cryptographie à clé publique RSA et SHA-256, etc.
- Assurez-vous que les sauvegardes hors site sont chiffrées, mais que les clés sont gérées et sauvegardées séparément.
Échec de la restriction de l'accès à l'URL
Description
Les applications Web vérifient les droits d'accès aux URL avant de rendre les liens et les boutons protégés. Les applications doivent effectuer des contrôles de contrôle d'accès similaires à chaque fois que ces pages sont consultées.
Dans la plupart des applications, les pages, emplacements et ressources privilégiés ne sont pas présentés aux utilisateurs privilégiés.
Par une supposition intelligente, un attaquant peut accéder aux pages de privilèges. Un attaquant peut accéder à des pages sensibles, invoquer des fonctions et consulter des informations confidentielles.
Implication
- En utilisant cette vulnérabilité, l'attaquant peut accéder aux URL non autorisées, sans se connecter à l'application et exploiter la vulnérabilité. Un attaquant peut accéder à des pages sensibles, invoquer des fonctions et consulter des informations confidentielles.
Objets vulnérables:
- URL
Exemples
- L'attaquant remarque que l'URL indique le rôle comme "/ user / getaccounts". Il modifie comme "/ admin / getaccounts".
- Un attaquant peut ajouter un rôle à l'URL.
http://www.vulnerablsite.com peut être modifié comme http://www.vulnerablesite.com/admin
Recommandations
- Mettez en œuvre des contrôles de contrôle d'accès rigoureux.
- Les politiques d'authentification et d'autorisation doivent être basées sur les rôles.
- Restreignez l'accès aux URL indésirables.
Protection insuffisante de la couche de transport
Description
Traite de l'échange d'informations entre l'utilisateur (client) et le serveur (application). Les applications transmettent fréquemment des informations sensibles telles que les détails d'authentification, les informations de carte de crédit et les jetons de session sur un réseau.
En utilisant des algorithmes faibles ou en utilisant des certificats expirés ou invalides ou en n'utilisant pas SSL, la communication peut être exposée à des utilisateurs non approuvés, ce qui peut compromettre une application Web et / ou voler des informations sensibles.
Implication
- En utilisant cette vulnérabilité de sécurité Web, un attaquant peut renifler les informations d'identification de l'utilisateur légitime et accéder à l'application.
- Peut voler des informations de carte de crédit.
Objets vulnérables
- Données envoyées sur le réseau.
Recommandations
- Activez HTTP sécurisé et appliquez le transfert des informations d'identification via HTTPS uniquement.
- Assurez-vous que votre certificat est valide et n'a pas expiré.
Exemples:
1. Une application n'utilisant pas SSL, un attaquant surveillera simplement le trafic réseau et observera un cookie de session victime authentifié. Un attaquant peut voler ce cookie et effectuer une attaque Man-in-the-Middle.
Redirections et transferts non validés
Description
L'application Web utilise peu de méthodes pour rediriger et transférer les utilisateurs vers d'autres pages dans un but précis.
S'il n'y a pas de validation appropriée lors de la redirection vers d'autres pages, les attaquants peuvent en profiter et rediriger les victimes vers des sites de phishing ou de logiciels malveillants, ou utiliser des redirections pour accéder à des pages non autorisées.
Implication
- Un attaquant peut envoyer à l'utilisateur une URL contenant une véritable URL accompagnée d'une URL malveillante codée. Un utilisateur en voyant simplement la partie authentique de l'URL envoyée par l'attaquant peut la parcourir et devenir une victime.
Exemples
1. http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com
Modifié en
http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com
Recommandations
- Évitez simplement d'utiliser les redirections et les transferts dans l'application. S'il est utilisé, n'impliquez pas l'utilisation de paramètres utilisateur pour calculer la destination.
- Si les paramètres de destination ne peuvent pas être évités, assurez-vous que la valeur fournie est valide et autorisée pour l'utilisateur.
Cet article est contribué par Prasanthi Eati