10 vulnérabilités de sécurité Web les plus courantes

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 basée sur les données de diverses organisations de sécurité.

Les vulnérabilités de sécurité Web sont priorisées 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é ? L'exploitabilité la plus élevée lorsque l'attaque nécessite uniquement un navigateur Web et la plus faible é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 –Quel dommage sera causé si la faille de sécurité est exposée ou attaquée ? Le plus élevé étant un crash complet du système et le plus bas étant rien du tout.

L'objectif principal de l'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

Description

L'injection est une vulnérabilité de sécurité qui permet à un attaquant de modifier le backend SQL déclarations 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ète dans le cadre d'une commande ou d'une requête et incite l'interprète à 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).
• Administration Operales opérations 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 disposer 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 à Interpreter comme ci-dessous

SELECT * FROM Utilisateurs OÙ Nom_utilisateur = sjones ET Mot de passe = 1=1′ ou pass123 ;

Recommandations

1. Liste blanche des champs de saisie
2. Évitez d'afficher des messages d'erreur détaillés utiles à un attaquant.

Cross Site Scripting

Description

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 le navigateur de l'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 des 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 pourra détourner les cookies de session, dégrader des 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 des 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, dégrader 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'affichera si le site est vulnérable à XSS.

L'attaque la plus grave peut être menée si l'attaquant souhaite afficher ou stocker un cookie de session.

2. http://demo.testfire.net/search.aspx?txtSearch <iframe> http://google.com largeur = 500 hauteur 500>

Le script ci-dessus, une fois exécuté, 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

1. Champs de saisie de la liste blanche
2. Encodage d’entrée et de sortie

Authentification brisée et gestion de session

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 le nom d'utilisateur, le mot de passe, etc. Lorsque la session est terminée soit par une déconnexion, soit par la fermeture brusque du navigateur, ces cookies doivent être invalidés, c'est-à-dire pour chaque session. 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, pour un utilisateur utilisant un ordinateur public (Cyber ​​Café), les cookies du site vulnérable se trouvent sur le système et sont 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 parcourt 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 et les cookies doivent être mis en œuvre correctement sans compromettre les mots de passe.

Objets vulnérables

• Les ID de session exposés sur l'URL peuvent conduire à une attaque de fixation de session.
• Les identifiants de session sont identiques avant et après la déconnexion et la connexion.
• Les délais d'expiration de session ne sont pas implémentés correctement.
• L'application attribue le même ID de session pour chaque nouvelle session.
• Les parties authentifiées de l'application sont protégées via 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, ce qui permet la divulgation et la modification d'informations non autorisées.
• Les sessions peuvent être détournées à l'aide de cookies volés ou de sessions utilisant XSS.

Exemples

1. 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 envoie un email à travers. 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és.
2. Une application est vulnérable au XSS, grâce auquel un attaquant peut accéder à l'ID de session et peut être utilisé pour détourner la session.
3. Les délais d'expiration des applications ne sont pas définis correctement. L'utilisateur utilise un ordinateur public, ferme le navigateur au lieu de se déconnecter et s'en va. L'attaquant utilise le même navigateur quelque temps plus tard et la session est authentifiée.

Recommandations

1. 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 de l'OWASP.
2. N’exposez jamais d’informations d’identification dans les URL ou les journaux.
3. De gros efforts doivent également être déployés pour éviter les failles XSS qui peuvent être utilisées pour voler des identifiants de session.

Références d'objet directes 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 une URL ou en tant que paramètre FORM. L'attaquant peut utiliser ces informations pour accéder à d'autres objets et créer une future attaque pour accéder aux données non autorisées.

Implication

• En utilisant 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 « ID utilisateur » dans l'URL suivante peut inciter un attaquant à consulter les informations d'un autre utilisateur.

http://www.vulnerablesite.com/userid=123 Modifié en http://www.vulnerablesite.com/userid=124

Un attaquant peut afficher les informations des autres en modifiant la valeur de l'identifiant utilisateur.

Nos recommandations:

1. Mettre en œuvre des contrôles d’accès.
2. Évitez d'exposer des références d'objet dans les URL.
3. Vérifiez l'autorisation sur tous les objets de référence.

Contrefaçon de demande intersite

Description

Cross Site Request Forgery est une fausse demande provenant du cross site.

L'attaque CSRF est une attaque qui se produit lorsqu'un site Web, un courrier électronique 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 fausse requête HTTP, comprenant 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 du site Web.

Implication

• L'utilisation de cette vulnérabilité en tant qu'attaquant peut modifier les informations du profil utilisateur, modifier le statut, créer un nouvel utilisateur au nom de l'administrateur, etc.

Objets vulnérables

• Page Profil utilisateur
• Formulaires de compte utilisateur
• Page des transactions commerciales

Exemples

La victime est connectée à un site Web bancaire à l'aide d'informations d'identification valides. Il reçoit un courrier d'un attaquant lui 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 demande, crée la demande ci-dessous et l'intègre dans un bouton indiquant « 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 provient du site Web de la banque, le serveur transférerait 1000 dollars à l'attaquant.

Recommandation

1. Mandatez la présence de l'utilisateur lors de l'exécution d'actions sensibles.
2. Mettre en œuvre des mécanismes comme CAPTCHA, réauthentification et jetons de demande uniques.

Mauvaise configuration de la sécurité

Description

La configuration de sécurité doit être définie et déployée pour l'application, les frameworks, le serveur d'applications, le serveur Web, le serveur de base de données et la plateforme. Si ceux-ci sont correctement configurés, un attaquant peut avoir un accès non autorisé aux données ou fonctionnalités sensibles.

Parfois, de telles failles 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 les informations sur la technologie sous-jacente et 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

1. La console d'administration du serveur d'applications est automatiquement installée et non 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é.
2. La liste des annuaires 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

1. Une architecture applicative solide qui offre une bonne séparation et sécurité entre les composants.
2. Modifiez les noms d'utilisateur et les mots de passe par défaut.
3. Désactivez les listes de répertoires et mettez en œuvre des contrôles 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 sur la base de données de l'application. Lorsque ces données sont stockées de manière inappropriée sans utiliser de cryptage ou de hachage*, elles seront vulnérables aux attaquants.

(*Le hachage est la transformation des caractères de la chaîne en chaînes plus courtes de longueur fixe ou en clé. Pour décrypter 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 commettre un vol d'identité, une fraude par carte de crédit ou d'autres crimes.

Objets vulnérables

• Base de données d'applications.

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 chacun. 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 en un rien de temps, alors que les mots de passe salés prendraient des milliers d'années.

(*Hachages 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

1. Garantir des algorithmes standards 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.
2. 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 aux URL

Description

Les applications Web vérifient les droits d'accès aux URL avant d'afficher des liens et des boutons protégés. Les applications doivent effectuer des contrôles d'accès similaires à chaque accès à ces pages.

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 privilégiées. Un attaquant peut accéder à des pages sensibles, appeler des fonctions et afficher 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, appeler des fonctions et afficher des informations confidentielles.

Objets vulnérables :

• URL

Exemples

1. L'attaquant remarque que l'URL indique le rôle comme « /user/getaccounts ». Il se modifie comme « /admin/getaccounts ».
2. Un attaquant peut ajouter un rôle à l'URL.

http://www.vulnerablsite.com peut être modifié comme http://www.vulnerablesite.com/admin

Recommandations

1. Mettez en œuvre des contrôles d’accès rigoureux.
2. Les politiques d’authentification et d’autorisation doivent être basées sur les rôles.
3. Restreindre l'accès aux URL indésirables.

Protection insuffisante de la couche de transport

Description

Traite 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.

L'utilisation d'algorithmes faibles ou de certificats expirés ou invalides ou la non-utilisation de SSL peut permettre à la communication d'être exposée à des utilisateurs non fiables, 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 détecter les informations d'identification d'un 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

1. Activez HTTP sécurisé et appliquez le transfert d’informations d’identification via HTTPS uniquement.
2. 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 le but prévu.

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 les redirections pour accéder à des pages non autorisées.

Implication

• Un attaquant peut envoyer à l'utilisateur une URL contenant une véritable URL complétée par 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

1. Évitez simplement d’utiliser des redirections et des transferts dans l’application. S'il est utilisé, n'implique pas l'utilisation de paramètres utilisateur dans le calcul de la destination.
2. Si les paramètres de destination ne peuvent être évités, assurez-vous que la valeur fournie est valide et autorisée pour l'utilisateur.