Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Sommaire: Cookies VS Session Web footprinting/Vulnerability scanners XSS attack

Sommaire: Cookies VS Session Web footprinting/Vulnerability scanners XSS attack SQL injection CSRF attack HTTP Parameter Pollution (HPP) Directory traversal Session hijacking Cookies attack DDOS attack Contre-mesures: Cookies VS Session Server-side Session : Une session est stockée sur le serveur Client-side Cookies : Un cookie est stocké sur le client Web footprinting: Gathering information related to the web application like- Whois information Netcraft information Firewall information Ports and services running Server and OS discovery Hidden contents Vulnerability scanners: Scanners like Nikto, Nessus, URLscan, Acunetix can be used to find out vulnerabilities in a web application. XSS Attack Les attaques XSS utilisent des ressources Web tierces pour exécuter des scripts dans le navigateur Web de la victime ou dans une application pouvant être scriptée. Plus précisément, l’attaquant injecte un JavaScript malveillant dans la base de données d’un site Web. Lorsque la victime demande une page du site Web, le site Web transmet la page à son navigateur avec le script malveillant intégré au corps HTML. Le navigateur de la victime exécute ce script, qui envoie par exemple le cookie de la victime au serveur de l’attaquant, qui l’extrait et l’utilise pour détourner la session. Les conséquences les plus graves se produisent lorsque XSS sert à exploiter des vulnérabilités supplémentaires. Ces vulnérabilités peuvent non seulement permettre à un attaquant de voler des cookies, mais aussi d’enregistrer les frappes de touches et des captures d’écran, de découvrir et de collecter des informations réseau et d’accéder et de contrôler à distance l’ordinateur de la victime. Type des attaques XSS 1. Stored cross site Scripting 2. Reflected cross site Scripting 3. Dom based cross site Scripting 1. Stored XSS or persistent XSS : l’injection du script est permanente stocke dans les serveurs Cibles comme database, forum message, comment field. Prenons pour exemple un forum, ou un blog. L’attaquant va envoyer un message ou un commentaire contenant le contenu malicieux. Lorsque les autres utilisateurs vont se rendre sur le forum ou le blog, ce contenu sera là, à chaque fois qu’ils afficheront la page. 2. Reflected XSS or non-persistent XSS : l’injection du script est reflétée sur le serveur web comme error message, search result cette attaque est destinée vers un utilisateur par un email ou autre. Lorsqu'un utilisateur est amené à cliquer sur un lien malveillant, à soumettre un formulaire spécialement conçu ou même à simplement naviguer sur un site malveillant, le code injecté se rend sur le site Web vulnérable, ce qui reflète l'attaque dans le navigateur de l'utilisateur. Le navigateur exécute alors le code car il provient d'un serveur «de confiance ». 3. Dom Based XSS or XSS local : Ce type d’attaque est aussi appelé XXS local. En chargeant une de ces adresses URL manipulées, un code malicieux est exécuté sans vérification grâce à une faille présente dans un script côté client. Au contraire des XXS persistants et réfléchis, le serveur Web n’a ici pas sa place dans le processus. Cette variante de script porte également atteinte aux sites Web statiques, qui prennent ce langage de script en charge. Exemple : le script basé sur le DOM fonctionne comme les cross-site-scriptings réfléchis : l’utilisateur ouvre un lien. Après avoir cliqué dessus, un script lit la valeur d’argument de l’URL et exécute le code de script qu’il contient. C’est ainsi que les cookies de session par exemple sont volés. SQL Injection Qu’est-ce que SQL : SQL veut dire Langage de requête structurée. (En anglais : Structured Query Language). Pour que les différents logiciels et le moteur de base de données puissent se comprendre, ils utilisent un langage appelé SQL. Ce langage est complet. Il va être utilisé pour :  Lire les données,  Ecrire les données,  Modifier les données,  Supprimer les données La plupart des sites web utilise des bases de données La plupart des données sont stocke dans de DB (username, password, personnal info …) Attaque par injection SQL : L’injection SQL est devenue un problème courant qui affecte les sites Web exploitant des bases de données. Elle se produit lorsqu’un malfaiteur exécute une requête SQL sur la base de données via les données entrantes du client au serveur. Par ex, à la place du nom d’utilisateur ou du mdp Cette attaque est partout et Un exploit d’injection SQL réussi peut lire les données sensibles de la base de données, modifier (insérer, mettre à jour ou supprimer) les données de la base de données, exécuter des opérations d’administration de la base de données (par exemple la fermer), récupérer le contenu d’un fichier spécifique, et, dans certains cas, envoyer des commandes au système d’exploitation. CSRF attack CSRF : le Cross Site Request Forgery (XSRF en français) est un mode d’escroquerie courant sur Internet. Les criminels prennent le contrôle d'une session autorisée par l’utilisateur (Session Riding) et peuvent ainsi exécuter des actions malveillantes. Celles-ci passent par le biais de requêtes HTTP. Source : https://owasp.org/www-community/attacks/csrf Par exemple nous faisons référence aux opérations bancaires en ligne, car elles illustrent au mieux la portée potentielle de telles techniques d'attaque. Un utilisateur se connecte à son compte en ligne. Il y trouve un formulaire spécifique lui permettant de procéder à un virement bancaire. Lorsqu'il remplit ce formulaire et clique sur le bouton de confirmation, une requête HTTP spécifique est envoyée au serveur et le virement est effectué. L'escroc sait précisément à quoi ressemble le formulaire et comment la requête HTTP est élaborée. Il peut donc les reproduire. Les seules informations à saisir sont alors ses propres coordonnées bancaires et un montant à virer. Le hacker peut ensuite créer un site Web (ou envoyer un email) faisant appel aux intérêts du client bancaire. Ce dernier est alors invité à cliquer sur un lien apparemment inoffensif pour activer la requête HTTP falsifiée. Celle-ci est ensuite envoyée à la banque qui exécute l’action demandée par le hacker. La session est encore active et la requête correcte : Le serveur n’a aucune raison de ne pas exécuter l’action. L'argent est donc transféré en toute simplicité. L’utilisateur ne le remarque que plus tard, sur son relevé de comptes. Http parameter pollution Les attaques de pollution par paramètre HTTP (HPP) n'ont été présentées et discutées que récemment, et n'ont pas a reçu beaucoup d'attention jusqu'à présent. Une vulnérabilité HPP permet à un attaquant d'injecter un paramètre dans les URL généré par une application Web. Les conséquences de l'attaque dépendent de la logique de l'application et peuvent varient d’un simple ennui à une corruption complète du comportement de l’application. Parce que cette classe de web la vulnérabilité n'est pas encore largement connue et bien comprise, dans cette section, nous expliquons et discutons d'abord le problème. Même si l'injection d'un nouveau paramètre peut parfois suffire à exploiter une application, l'attaquant est généralement plus intéressé à remplacer la valeur d'un paramètre déjà existant. Ceci peut être réalisé en "masquant" l'ancien paramètre en introduisant un nouveau avec le même nom. Pour que cela soit possible, il faut que l’application web à «se comporter mal » en présence de paramètres dupliqués, un problème souvent erroné confondu avec la vulnérabilité HPP elle-même. Cependant, étant donné que les attaques de pollution de paramètres reposent souvent sur des paramètres en pratique, nous avons décidé d'étudier le comportement de duplication des paramètres des applications, et de le mesurer en nos expériences. Consequence:  Remplacer les valeurs existantes (codées en dur)  Injecter un nouveau paramètre  Exploiter un paramètre hors d’atteinte directe  Attaque côté client (utilisateur) ou côté serveur (application Web) Exemples de vulnérabilités découvertes : Facebook, Twitter, Digg et d'autres sites de réseaux sociaux offrent un composant de partage pour partager facilement le contenu d'une page Web sur un profil d'utilisateur. En passant en revue les logs de vulnérabilité des applications testées, nous avons remarqué que différents sites permettaient une injection de paramètres sur les liens référençant le composant de partage de Facebook. Dans tous ces cas, un paramètre vulnérable permettrait à un attaquant de modifier la requête envoyée à Facebook et d'amener la victime à partager une page choisie par l'attaquant. Par exemple, il était possible pour un attaquant d'exploiter ces vulnérabilités pour corrompre un lien partagé en écrasant la référence par l'URL d'un site Web de téléchargement. En termes techniques, le problème était dû au fait qu'il était possible d'injecter un paramètre supplémentaire d'url-to-share qui pourrait écraser la valeur du paramètre utilisé par l'application. Par exemple : Directory traversal Une attaque par Directory traversal (également connue sous le nom de path traversal) vise à accéder aux fichiers et répertoires stockés en dehors du dossier racine Web. En manipulant des variables qui référencent des fichiers avec des séquences « point-point-slash (../) » et ses variations ou en utilisant des chemins de fichier absolus, il peut être possible d'accéder à des fichiers et répertoires arbitraires stockés sur le système de fichiers, y compris le code source de l'application ou la configuration et les fichiers système critiques. Il convient de noter que l'accès aux fichiers est limité par le contrôle d'accès opérationnel du système (comme dans le cas de fichiers uploads/S4/ attaques-sur-websites.pdf