WEB
international days all around the world with or without hashtags, useful for social networks activities.
1. Information Gathering
1.1. CODE SOURCE
1.2. INTERACTION
1.3. LIENS
1.4. Leakage
1.4.1. SHODAN
1.4.1.1. a service for searching Internet-connected devices and services. Usage options include a limited free plan as well as paid subscription plans.
1.4.2. Search Operators
1.4.2.1. site: will limit the search to the provided URL.
1.4.2.1.1. site:youtube.com
1.4.2.2. inurl: will only return results that include the keyword in the URL.
1.4.2.2.1. inurl:youtube.com
1.4.2.3. intitle:will only return results that have the keyword in the page title.
1.4.2.3.1. intitle:youtube.com
1.4.2.4. intext: or inbody: will only search for the keyword in the body of pages.
1.4.2.4.1. intext:youtube.com
1.4.2.5. filetype: will match only a specific filetype, i.e. png, or php.
1.4.2.5.1. filetype:youtube.com
1.4.3. ROBOT.TX
1.4.3.1. Fichier robots.txt
1.4.3.2. Description : Fichier robots.txt
1.4.3.3. Le fichier robots.txt est utilisé pour donner des instructions aux robots Web, tels que les robots des moteurs de recherche, sur les emplacements du site Web que les robots sont autorisés, ou non, à explorer et à indexer.
1.4.3.4. La présence du fichier robots.txt ne présente pas en soi de vulnérabilité de sécurité. Cependant, il est souvent utilisé pour identifier les zones restreintes ou privées du contenu d'un site. Les informations contenues dans le fichier peuvent donc aider un attaquant à cartographier le contenu du site, en particulier si certains des emplacements identifiés ne sont pas liés à d'autres emplacements du site. Si l'application s'appuie sur le fichier robots.txt pour protéger l'accès à ces zones et n'applique pas de contrôle d'accès approprié sur celles-ci, cela présente une vulnérabilité sérieuse.
1.4.3.4.1. http://'example.com'/robots.txt#
1.5. empreintes digitales
1.5.1. Nikto
1.5.2. Nmap
1.5.3. Netcraft
1.5.4. Key Locations for Fingerprinting
1.5.4.1. HTTP Headers
1.5.4.2. Cookies
1.5.4.3. HTML Source Code
1.5.4.4. File Extensions
1.5.4.5. Error Messages
1.5.5. Tools for Framework Fingerprinting
1.5.5.1. WhatWeb
1.6. Énumération
1.6.1. DNS et IP Inversée
1.6.1.1. dig -x 192.168.1.1
1.6.1.2. host 192.168.1.1
1.6.1.3. dig @dns.example.com
1.6.1.4. example.com AXFR
1.6.1.5. URL non standard
1.6.1.5.1. Recherche des chemins courants dans les URL, tels que /admin, /webmail, /login, /upload, /devou d'autres noms probables. Utiliser des outils comme Gobuster ou Dirb pour forcer brutalement les répertoires et découvrir des pages cachées :
1.6.1.6. Hôtes Virtuels
1.6.1.6.1. Hôtes Virtuels
1.7. Black box
1.7.1. Recherche de Commentaires HTML
1.7.1.1. Commentaires HTML
1.7.1.2. Métadonnées
1.7.2. GREY BOX
1.7.2.1. WGET
1.8. surface d'attaque
1.8.1. BURPSUITE
1.8.2. OWASP
2. CONFIGURATION TESTING
2.1. Network Infrastructure
2.1.1. Cartographier l'infrastructure
2.1.1.1. lucidchart
2.1.2. Analyser les vulnérabilités connues
2.1.2.1. Vulnérabilités d'Injection
2.1.2.1.1. SQLmap
2.1.2.1.2. Burpsuite
2.1.2.1.3. LDAP Injection
2.1.2.1.4. XPATH Injection
2.1.2.1.5. NoSQL Injection
2.1.2.2. Vulnérabilités Auth
2.1.2.2.1. Hydra
2.1.2.2.2. Cookie Editor
2.1.2.2.3. XSSI
2.1.2.2.4. Credential snuffing
2.1.2.3. Vulnérabilités Cross-Site
2.1.2.3.1. XSS
2.1.2.3.2. CSRF
2.1.2.4. Vulnérabilités liées aux données sensibles
2.1.2.4.1. SSLyze
2.1.2.4.2. IDOR
2.1.2.5. Vulnérabilités dans la gestion des accès
2.1.2.5.1. Broken Access Control
2.1.2.5.2. CORS
2.1.2.6. Vulnérabilités des API
2.1.2.6.1. Absence de limitation de débit
2.1.2.6.2. Autorisation de niveau d'objet brisé (BOLA)
2.1.2.7. Vulnérabilités liées aux configurations
2.1.2.7.1. SecurityHeaders.io
2.1.2.8. Vulnérabilités dans les dépendances
2.1.2.8.1. attack dependecy
2.1.2.9. Vulnérabilités de l’infrastructure
2.1.2.9.1. Aquatone
2.1.2.9.2. SSRF
2.1.2.10. Vulnérabilités spécifiques aux CMS
2.1.2.10.1. WPScan
2.1.2.10.2. JoomScan
2.1.2.11. Vulnérabilités liées aux attaques physiques ou sociales
2.1.2.11.1. Hameçonnage
2.1.2.11.2. Enregistrement et surveillance insuffisants
2.1.2.12. Vulnérabilités de Business Logic
2.1.2.13. Vulnérabilités Frontend
2.1.2.13.1. Clobbering DOM et XSS basé sur DOM
2.1.2.13.2. Clickjacking
3. EXPLOIT
3.1. Essential skills
3.2. SQL Injection
3.2.1. SQL COMMAND LIST
3.2.2. DETECT VULN SQL
3.2.2.1. The single quote character ' and look for errors or other anomalies.
3.2.2.2. Boolean conditions such as OR 1(égale)1 and OR 1(égale)2, and look for differences in the application's responses.
3.2.3. SQL injection vulnerability in WHERE clause allowing retrieval of hidden data
3.2.3.1. SELECT * FROM products WHERE category = 'Gifts' AND released = 1
3.2.4. SQL injection vulnerability allowing login bypass
3.2.4.1. Modify the username parameter, giving it the value: administrator'--
3.2.5. Examining the database in SQL injection attacks
3.2.5.1. LIST THE CONTENT
3.2.6. SQL injection attack, querying the database type and version on Oracle
3.2.6.1. Determine the number of columns that are being returned by the query and which columns contain text data. Verify that the query is returning two columns, both of which contain text, using a payload like the following in the category parameter: '+UNION+SELECT+'abc','def'+FROM+dual-- Use the following payload to display the database version: '+UNION+SELECT+BANNER,+NULL+FROM+v$version--
3.2.7. SQL Injection attack Microsoft & Mysql
3.2.8. SQL injection attack, listing the database contents on non-Oracle databases
3.2.9. SQL injection attack, listing the database contents on Oracle
3.2.10. UNION ATTACK
3.2.10.1. DETERMINING THE NUMBER OF COLUMN
3.2.10.2. COLUMN WITH USEFUL DATABASE
3.2.10.3. RETRIEVING INTERESTING DATA
3.2.10.4. MULTIPLE VALUE WITH A SINGLE COLUMN
3.2.11. Blind SQL injection with conditional responses
3.2.12. Blind SQL injection with conditional errors
3.2.13. Visible error-based SQL injection
3.2.14. Blind SQL injection with time delays
3.2.15. Blind SQL injection with time delays and information retrieval
3.2.16. Blind SQL injection with out-of-band interaction
3.2.17. Blind SQL injection with out-of-band data exfiltration
3.2.18. SQL injection with filter bypass via XML encoding
3.3. XSS
3.3.1. DETECT XSS
3.3.1.1. How to find and test for XSS vulnerabilities The vast majority of XSS vulnerabilities can be found quickly and reliably using Burp Suite's web vulnerability scanner. Manually testing for reflected and stored XSS normally involves submitting some simple unique input (such as a short alphanumeric string) into every entry point in the application, identifying every location where the submitted input is returned in HTTP responses, and testing each location individually to determine whether suitably crafted input can be used to execute arbitrary JavaScript. In this way, you can determine the context in which the XSS occurs and select a suitable payload to exploit it. Manually testing for DOM-based XSS arising from URL parameters involves a similar process: placing some simple unique input in the parameter, using the browser's developer tools to search the DOM for this input, and testing each location to determine whether it is exploitable. However, other types of DOM XSS are harder to detect. To find DOM-based vulnerabilities in non-URL-based input (such as document.cookie) or non-HTML-based sinks (like setTimeout), there is no substitute for reviewing JavaScript code, which can be extremely time-consuming. Burp Suite's web vulnerability scanner combines static and dynamic analysis of JavaScript to reliably automate the detection of DOM-based vulnerabilities.
3.3.2. Reflected XSS into HTML context with nothing encoded
3.3.3. Stored XSS into HTML context with nothing encoded
3.3.4. DOM XSS in document.write sink using source location.search
3.3.5. DOM XSS in innerHTML sink using source location.search
3.3.6. DOM XSS in jQuery anchor href attribute sink using location.search source
3.3.7. DOM XSS in jQuery selector sink using a hashchange event
3.3.8. Reflected XSS into attribute with angle brackets HTML-encoded
3.3.9. Stored XSS into anchor href attribute with double quotes HTML-encoded
3.3.10. Reflected XSS into a JavaScript string with angle brackets HTML encoded
3.3.11. DOM XSS in document.write sink using source location.search inside a select element
3.3.12. DOM XSS in AngularJS expression with angle brackets and double quotes HTML-encoded
3.3.13. Reflected DOM XSS
3.3.14. Stored DOM XSS
3.3.15. Reflected XSS into HTML context with most tags and attributes blocked
3.3.16. Reflected XSS into HTML context with all tags blocked except custom ones
3.3.17. Reflected XSS with some SVG markup allowed
3.3.18. Reflected XSS in canonical link tag
3.3.19. Reflected XSS into a JavaScript string with single quote and backslash escaped
3.3.20. Reflected XSS into a JavaScript string with angle brackets and double quotes HTML-encoded and single quotes escaped
3.3.21. Stored XSS into onclick event with angle brackets and double quotes HTML-encoded and single quotes and backslash escaped
3.3.22. Reflected XSS into a template literal with angle brackets, single, double quotes, backslash and backticks Unicode-escaped
3.3.23. Exploiting cross-site scripting to steal cookies
3.3.24. Exploiting cross-site scripting to capture passwords
3.3.25. Exploiting XSS to perform CSRF
3.3.26. Reflected XSS with AngularJS sandbox escape without strings
3.3.26.1. Reflected XSS with AngularJS sandbox escape and CS
3.3.27. Reflected XSS with event handlers and href attributes blocked
3.3.28. Reflected XSS in a JavaScript URL with some characters blocked
3.3.29. Reflected XSS protected by very strict CSP, with dangling markup attack
3.3.30. Reflected XSS protected by CSP, with CSP bypass
3.4. CSRF
3.4.1. DELIVERING CSRF EXPLOIT
3.4.1.1. How to deliver a CSRF exploit The delivery mechanisms for cross-site request forgery attacks are essentially the same as for reflected XSS. Typically, the attacker will place the malicious HTML onto a website that they control, and then induce victims to visit that website. This might be done by feeding the user a link to the website, via an email or social media message. Or if the attack is placed into a popular website (for example, in a user comment), they might just wait for users to visit the website. Note that some simple CSRF exploits employ the GET method and can be fully self-contained with a single URL on the vulnerable website. In this situation, the attacker may not need to employ an external site, and can directly feed victims a malicious URL on the vulnerable domain. In the preceding example, if the request to change email address can be performed with the GET method, then a self-contained attack would look like this: <img src="https://vulnerable-website.com/email/[email protected] ">
3.4.2. Manual testing for Cross-Site Request Forgery
3.4.2.1. If you want to discover if the session is insecure you will need to examine the application’s session. If session management is on the user side, indicating information is available to the browser, then the application is vulnerable. “Client-side values” refer to HTTP authentication credentials and cookies. Accessible resources via HTTP GET requests are undoubtedly vulnerable, although POST requests tend to be automated via JavaScript and are exposed and vulnerable, therefore the use of POST only is not enough to fix the occurrence of CSRF vulnerabilities.
3.4.2.2. Tools
3.4.2.2.1. OWASP ZAP
3.4.2.2.2. BURP
3.4.3. CSRF vulnerability with no defenses
3.4.4. CSRF where token validation depends on request method
3.4.5. CSRF where token validation depends on token being present
3.4.6. CSRF where token is not tied to user session
3.4.7. CSRF where token is tied to non-session cookie
3.4.8. CSRF where token is duplicated in cookie
3.4.9. SameSite Lax bypass via method override
3.4.10. SameSite Strict bypass via client-side redirect
3.4.11. SameSite Strict bypass via sibling domain
3.4.12. SameSite Lax bypass via cookie refresh
3.4.13. CSRF where Referer validation depends on header being present
3.4.14. CSRF with broken Referer validation
3.5. Clickjacking
3.5.1. Test clickjacking
3.5.1.1. https://clickjacker.io/
3.5.1.2. BURP
3.5.2. Basic clickjacking with CSRF token protection
3.5.3. Clickjacking with form input data prefilled from a URL parameter
3.5.4. Clickjacking with a frame buster script
3.5.5. Exploiting clickjacking vulnerability to trigger DOM-based XSS
3.5.6. Multistep clickjacking
3.6. CRLF Injection
3.7. DOM BASED
3.7.1. INFO
3.7.2. CHECK FOR DOM VULN
3.7.3. DOM XSS using web messages
3.7.4. DOM XSS using web messages and a JavaScript URL
3.7.5. DOM XSS using web messages and JSON.parse
3.7.6. DOM-based open redirection
3.7.7. DOM-based cookie manipulation
3.7.8. Exploiting DOM clobbering to enable XSS
3.7.9. Clobbering DOM attributes to bypass HTML filters
3.8. Cross-origin resource sharing
3.8.1. CHECK CROSS-ORIGIN
3.8.1.1. How to Detect Cross-Origin Resource Sharing (CORS) Issues 3. Tools for Detecting CORS Issues Burp Suite: Use the "CORS" extension or manually inspect HTTP responses for CORS headers. OWASP ZAP: Analyze requests and responses to find insecure CORS configurations. Postman: Test API endpoints by sending cross-origin requests. Browser Developer Tools: Check the Network tab for CORS-related errors or warnings. 4. Manual Testing Steps Inspect HTTP Responses for CORS Headers: Use tools like curl, browser developer tools, or proxies to analyze responses from the target application. Example using curl: curl -i -H "Origin: https://evil.com" -X OPTIONS https://www.target.site Check for: Access-Control-Allow-Origin: * (indicates a vulnerable policy) Access-Control-Allow-Credentials: true with * or overly permissive origins. Automated Testing with Burp Suite Enable CORS Testing: Install the "CORS" extension in Burp Suite. Use the scanner to identify insecure configurations. Interpret Results: Look for warnings like "Access-Control-Allow-Origin: *" or "Credentials allowed with wildcard origins."
3.8.2. CORS vulnerability with basic origin reflection
3.8.3. CORS vulnerability with trusted null origin
3.8.4. CORS vulnerability with trusted insecure protocols
3.9. XML Injection
3.9.1. DETECT
3.9.2. Exploiting XXE using external entities to retrieve files
3.9.3. Exploiting XXE to perform SSRF attacks
3.9.4. Blind XXE with out-of-band interaction
3.9.5. Blind XXE with out-of-band interaction via XML parameter entities
3.9.6. Exploiting blind XXE to exfiltrate data using a malicious external DTD
3.9.7. Exploiting blind XXE to retrieve data via error messages
3.9.8. Exploiting XInclude to retrieve files
3.9.9. Exploiting XXE via image file upload
3.9.10. Exploiting XXE to retrieve data by repurposing a local DTD
3.10. SSRF
3.10.1. HOW TO DETECT SSRF VULN
3.10.2. Basic SSRF against the local server
3.10.3. Basic SSRF against another back-end system
3.10.4. Blind SSRF with out-of-band detection
3.10.5. SSRF with blacklist-based input filter
3.10.6. SSRF with filter bypass via open redirection vulnerability
3.10.7. Blind SSRF with Shellshock exploitation
3.10.8. SSRF with whitelist-based input filter
3.11. HTTP Request Smuggling
3.11.1. HOW TO DETECT HTTP RESQUEST SMUGGLING
3.11.2. HTTP request smuggling, confirming a CL.TE vulnerability via differential responses
3.11.3. HTTP request smuggling, confirming a TE.CL vulnerability via differential responses
3.11.4. Exploiting HTTP request smuggling to bypass front-end security controls, CL.TE vulnerability
3.11.5. Exploiting HTTP request smuggling to bypass front-end security controls, TE.CL vulnerability
3.11.6. Exploiting HTTP request smuggling to reveal front-end request rewriting
3.11.7. Exploiting HTTP request smuggling to capture other users' requests
3.11.8. Exploiting HTTP request smuggling to deliver reflected XSS
3.11.9. Response queue poisoning via H2.TE request smuggling
3.11.10. H2.CL request smuggling
3.11.11. HTTP/2 request smuggling via CRLF injection
3.11.12. CL.0 request smuggling
3.11.13. HTTP request smuggling, basic CL.TE vulnerability
3.11.14. HTTP request smuggling, basic TE.CL vulnerability
3.11.15. HTTP request smuggling, obfuscating the TE header
3.11.16. HTTP request smuggling, obfuscating the TE header
3.11.17. Exploiting HTTP request smuggling to perform web cache poisoning
3.11.18. Exploiting HTTP request smuggling to perform web cache deception
3.11.19. Bypassing access controls via HTTP/2 request tunnelling
3.11.20. Web cache poisoning via HTTP/2 request tunnelling
3.11.21. Client-side desync
3.11.22. Server-side pause-based request smuggling
3.12. OS command injection
3.12.1. HOW TO DETECT OS COMMAND VULN
3.12.2. OS command injection, simple case
3.12.3. Blind OS command injection with time delays
3.12.4. Blind OS command injection with output redirection
3.12.5. Blind OS command injection with out-of-band interaction
3.12.6. Blind OS command injection with out-of-band data exfiltration
3.13. Server-side template injection
3.13.1. HOW TO DETECT SRVEUR-SIDE TEMPLATE INJECTION
3.13.2. Basic server-side template injection
3.13.3. Basic server-side template injection (code context)
3.13.4. Server-side template injection using documentation
3.13.5. Server-side template injection in an unknown language with a documented exploit
3.13.6. Server-side template injection with information disclosure via user-supplied objects PRACTITIONER
3.13.7. Server-side template injection in a sandboxed environment
3.13.8. Server-side template injection with a custom exploit
3.14. Path Traversal
3.14.1. File path traversal, simple case
3.14.2. File path traversal, traversal sequences blocked with absolute path bypass
3.14.3. File path traversal, traversal sequences stripped non-recursively
3.14.4. File path traversal, traversal sequences stripped with superfluous URL-decode
3.14.5. File path traversal, validation of start of path
3.14.6. File path traversal, validation of file extension with null byte bypass
3.15. Access control vulnerabilities
3.15.1. Unprotected admin functionality
3.15.2. Unprotected admin functionality with unpredictable URL
3.15.3. User role controlled by request parameter
3.15.4. User role can be modified in user profile
3.15.5. User ID controlled by request parameter
3.15.6. User ID controlled by request parameter, with unpredictable user IDs
3.15.7. User ID controlled by request parameter with data leakage in redirect
3.15.8. User ID controlled by request parameter with password disclosure
3.15.9. Insecure direct object references
3.15.10. URL-based access control can be circumvented
3.15.11. Method-based access control can be circumvented
3.15.12. Multi-step process with no access control on one step
3.15.13. Referer-based access control
3.16. Authentication
3.16.1. HOW TO DETECT
3.16.1.1. Pour détecter les vulnérabilités d'authentification, il est crucial de comprendre à la fois les mécanismes d'authentification et les failles courantes associées. Voici une méthode structurée pour identifier ces vulnérabilités : 1. Comprendre le mécanisme d'authentification Type d'authentification utilisé : Basé sur un mot de passe. Multi-facteurs (MFA). Biométrique ou comportemental. Authentification via des tiers (par ex. OAuth). Identifier les fonctionnalités critiques : Connexion, réinitialisation de mot de passe, gestion des sessions. 2. Identifier les vecteurs de vulnérabilités courants Failles générales : Mécanismes vulnérables au brute-force (absence de limitation sur les tentatives de connexion). Mots de passe faibles ou non protégés par des algorithmes de hachage robustes. Existence de logic flaws qui permettent de contourner l'authentification (par exemple, utilisation d'un jeton prévisible ou session non correctement invalidée). Vulnérabilités spécifiques : Réinitialisation de mot de passe : Poisoning via des URL mal sécurisées. Réinitialisation sans vérification d'identité. Multi-factor authentication : Contournement via des techniques comme le bypass de codes OTP ou l'exploitation de sessions non sécurisées. OAuth ou tiers : Mauvaise implémentation des flux OAuth (ex. absence de vérification des jetons). 3. Utiliser des outils et techniques d'analyse Analyse manuelle : Tester les workflows critiques (connexion, réinitialisation) en simulant des scénarios malveillants. Vérifier la logique des contrôles d'accès. Utilisation d'outils automatisés : Burp Suite : Pour manipuler les requêtes, détecter des injections, ou tester les mécanismes de protection (ex. contre le brute-force). Hydra : Pour tester les mots de passe ou effectuer du brute-force sur des systèmes authentifiés. OWASP ZAP : Analyse automatisée des vulnérabilités courantes. Analyse des journaux : Vérifiez les logs pour repérer des signes d'accès non autorisés ou des tentatives répétées. 4. Détection spécifique selon les cas d'usage Détection du brute-force : Vérifier si le système implémente des limitations de tentative (CAPTCHA, délai après plusieurs essais échoués). Utiliser des listes prédéfinies pour tester les mots de passe faibles. Détection de failles dans le MFA : Vérifier si des mécanismes de sauvegarde (par ex., questions de sécurité) contournent le MFA. Tester si un attaquant peut réutiliser des tokens d’authentification expirés. Test des implémentations OAuth : Vérifier si les jetons JWT sont correctement signés et sécurisés. Tester les redirections non sécurisées. 5. Références aux standards et labos OWASP Authentication Cheat Sheet : Une ressource précieuse pour identifier les bonnes pratiques et détecter les vulnérabilités. PortSwigger Labs : Accéder à des exercices pratiques pour s'entraîner sur des cibles vulnérables. 6. Prévention et recommandations Pour minimiser les vulnérabilités : Toujours utiliser des algorithmes de hachage modernes comme bcrypt pour stocker les mots de passe. Implémenter des limites de tentatives de connexion et des délais progressifs. Vérifier l’intégrité des tokens (CSRF, JWT) et des sessions. Utiliser des bibliothèques et frameworks de sécurité éprouvés pour éviter les erreurs d'implémentation.
3.16.2. Username enumeration via different responses
3.16.3. 2FA simple bypass
3.16.4. Password reset broken logic
3.16.5. Username enumeration via subtly different responses
3.16.6. Username enumeration via response timing
3.16.7. Broken brute-force protection, IP block
3.16.8. Username enumeration via account lock
3.16.9. 2FA broken logic
3.16.10. Brute-forcing a stay-logged-in cookie
3.16.11. Offline password cracking
3.16.12. Password reset poisoning via middleware
3.16.13. Password brute-force via password change
3.16.14. Broken brute-force protection, multiple credentials per request
3.16.15. 2FA bypass using a brute-force attack
3.17. WebSockets
3.17.1. HOW TO DETECT
3.17.1.1. Pour détecter une vulnérabilité de type cross-site WebSocket hijacking (CSWSH), vous pouvez suivre ces étapes détaillées : 1. Identifier les connexions WebSocket Utilisez un outil comme Burp Suite pour analyser les connexions WebSocket entre le client et le serveur. Assurez-vous d'inspecter les en-têtes de la requête initiale de handshake WebSocket (souvent un GET avec l'en-tête Upgrade: websocket). 2. Vérifier l'absence de protection CSRF Vérifiez si la requête de handshake WebSocket inclut des mécanismes de protection CSRF tels que : Un jeton CSRF transmis dans les en-têtes ou les paramètres. Des restrictions sur les origines autorisées via l'en-tête Origin. Test : Tentez d'établir une connexion WebSocket depuis un domaine contrôlé par un attaquant. Si la connexion réussit sans validation d'origine ou de jeton, il existe potentiellement une vulnérabilité. 3. Tester les actions exploitables Une fois connecté au WebSocket, tentez d'exécuter des actions sensibles (modification de données, envoi de commandes, etc.) pour confirmer la vulnérabilité. Exemple de scénario : Une application permet d'envoyer des messages privés via WebSocket. Si un attaquant peut s'y connecter et envoyer des messages au nom de la victime, la vulnérabilité est avérée. 4. Analyser les données envoyées et reçues Inspectez les messages échangés via le WebSocket. Testez avec des données malveillantes (comme du JavaScript dans une chaîne de texte) pour vérifier des vulnérabilités telles que : XSS : Envoi de contenu pouvant être interprété côté client. SQLi : Transfert de données manipulables côté serveur. 5. Reproduire un scénario d'attaque Créez une page malveillante (contrôlée par l'attaquant) avec un script JavaScript qui ouvre une connexion WebSocket au serveur de la cible. Exemple : javascript Copier le code var ws = new WebSocket('ws://vulnerable-site.com/websocket'); ws.onopen = function() { ws.send('{"action":"stealData"}'); }; ws.onmessage = function(event) { console.log("Data received: " + event.data); }; Si cette page peut établir une connexion et interagir avec l'application cible sans restrictions, la vulnérabilité est confirmée. 6. Vérifier les dépendances des sessions Assurez-vous que le contexte de session (cookies ou tokens) est correctement géré. Une mauvaise gestion pourrait permettre à l'attaquant d'exploiter la session de la victime sans authentification. Test : Supprimez les cookies de session côté client. Essayez de manipuler le WebSocket pour voir si l'application dépend uniquement des en-têtes HTTP initiaux. 7. Exploiter des en-têtes HTTP mal sécurisés Inspectez l'utilisation de l'en-tête X-Forwarded-For ou d'autres en-têtes personnalisés dans le handshake WebSocket. Essayez de falsifier ces en-têtes pour contourner des restrictions ou usurper une identité. Outils recommandés Burp Suite (Proxy et Repeater pour manipuler les messages WebSocket et le handshake). OWASP ZAP (alternative gratuite à Burp). Browser DevTools (pour inspecter les connexions WebSocket directement dans le navigateur). 8. Remédiations Si une vulnérabilité est détectée : Implémentez des protections CSRF pour les handshakes WebSocket. Limitez les origines autorisées via l'en-tête Origin. Chiffrez les connexions WebSocket avec wss://. Validez et nettoyez les données transmises dans les deux sens.
3.17.2. Manipulating WebSocket messages to exploit vulnerabilities
3.17.3. Cross-site WebSocket hijacking
3.17.4. Manipulating the WebSocket handshake to exploit vulnerabilities
3.18. Web cache poisoning
3.18.1. HOW TO DETECT
3.18.1.1. Pour détecter une vulnérabilité de type Web Cache Poisoning, voici les étapes clés à suivre : 1. Comprendre les principes du cache Identifier les parties de la requête HTTP utilisées par le cache (les "cache keys") pour déterminer si une réponse peut être réutilisée. Comprendre les éléments ignorés par le cache (les "unkeyed inputs") qui peuvent être exploités pour introduire des charges malveillantes. 2. Tester les entrées ignorées par le cache Injectez des valeurs aléatoires dans des headers ou des paramètres de requêtes (par exemple : X-Forwarded-Host, X-Original-URL, etc.). Analysez la réponse pour voir si ces entrées influencent le contenu généré par le serveur, même si elles ne modifient pas le cache key. Outils recommandés : Manuellement : Utilisez un proxy comme Burp Suite pour modifier les requêtes. Comparez les réponses obtenues avec et sans les paramètres injectés. Automatiquement : Installez l'extension Param Miner dans Burp Suite pour tester automatiquement une liste prédéfinie de headers. 3. Tester les réponses du serveur Recherchez des réponses non nettoyées (unsanitized) où vos entrées sont reflétées ou utilisées pour générer du contenu dynamique. Identifiez des vulnérabilités comme : XSS (Cross-Site Scripting) : Injecter des scripts JavaScript. Redirection ouverte : Manipuler des URLs pour rediriger vers des sites malveillants. Injection HTML/JS : Insérer du contenu malveillant visible pour l’utilisateur. 4. Observer le comportement du cache Vérifiez si la réponse malveillante est mise en cache : Modifiez légèrement vos requêtes tout en conservant le même cache key. Rafraîchissez plusieurs fois pour voir si les modifications persistent dans les réponses. Si votre réponse est servie directement depuis le cache, la vulnérabilité est confirmée. 5. Ajouter un cache buster pour éviter des effets indésirables Pour éviter d’empoisonner réellement le cache pendant les tests : Ajoutez un paramètre unique (ex. ?buster=12345) à vos requêtes. 6. Analyser la politique de mise en cache Vérifiez les en-têtes de réponse HTTP pour identifier les éléments relatifs au cache : Cache-Control Expires Vary Cela peut vous aider à comprendre quelles conditions permettent au cache de stocker les réponses. 7. Exploiter la vulnérabilité (dans un environnement contrôlé) Une fois que vous avez identifié un header ou un paramètre exploitable : Injectez une charge malveillante. Faites en sorte que cette réponse soit mise en cache. Validez l’impact en générant des requêtes avec le même cache key depuis différents clients. Outils supplémentaires Burp Suite : Utiliser Comparer pour analyser les différences de réponses. Repeater pour tester différentes requêtes avec précision. cURL : Tester rapidement les headers avec des commandes comme : bash Copier le code curl -I -H "X-Forwarded-Host: evil.com" http://example.com Signes révélateurs de vulnérabilités Un contenu dynamique reflète les valeurs des paramètres ou headers non pris en compte dans le cache key. Les réponses injectées persistent pour d'autres utilisateurs accédant à la même ressource. Le serveur met en cache des réponses potentiellement dangereuses.
3.18.2. Web cache poisoning with an unkeyed header
3.18.3. Web cache poisoning with an unkeyed cookie
3.18.4. Web cache poisoning with multiple headers
3.18.5. Targeted web cache poisoning using an unknown header
3.18.6. Web cache poisoning via an unkeyed query string
3.18.7. Web cache poisoning via an unkeyed query parameter
3.18.8. Parameter cloaking
3.18.9. Web cache poisoning via a fat GET request
3.18.10. URL normalization
3.18.11. Web cache poisoning to exploit a DOM vulnerability via a cache with strict cacheability criteria
3.18.12. Combining web cache poisoning vulnerabilities
3.18.13. Cache key injection
3.18.14. Internal cache poisoning
3.19. Insecure deserialization
3.19.1. Modifying serialized objects
3.19.2. Modifying serialized data types
3.19.3. Using application functionality to exploit insecure deserialization
3.19.4. Arbitrary object injection in PHP
3.19.5. Exploiting PHP deserialization with a pre-built gadget chain
3.19.6. Exploiting Ruby deserialization using a documented gadget chain
3.19.7. Developing a custom gadget chain for Java deserialization
3.19.8. Developing a custom gadget chain for PHP deserialization
3.19.9. Using PHAR deserialization to deploy a custom gadget chain
3.19.10. T
3.20. Information disclosure
3.20.1. HOW TO DETECT
3.20.2. Information disclosure in error messages
3.20.3. Information disclosure on debug page
3.20.4. Source code disclosure via backup files
3.20.5. Authentication bypass via information disclosure
3.20.6. nformation disclosure in version control history
3.21. Business logic vulnerabilities
3.21.1. Excessive trust in client-side controls
3.21.2. High-level logic vulnerability
3.21.3. Inconsistent security controls
3.21.4. Flawed enforcement of business rules
3.21.5. Low-level logic flaw
3.21.6. Inconsistent handling of exceptional input
3.21.7. Weak isolation on dual-use endpoint
3.21.8. Insufficient workflow validation
3.21.9. Authentication bypass via flawed state machine
3.21.10. Infinite money logic flaw
3.21.11. Authentication bypass via encryption oracle
3.21.12. Bypassing access controls using email address parsing discrepancies EXPERT
3.22. HTTP Host header attacks
3.22.1. Basic password reset poisoning
3.22.2. Host header authentication bypass
3.22.3. Web cache poisoning via ambiguous requests
3.22.4. Routing-based SSRF
3.22.5. SSRF via flawed request parsing
3.22.6. Host validation bypass via connection state attack
3.22.7. Password reset poisoning via dangling markup
3.23. OAuth authentication
3.23.1. HOW TO DETECT
3.23.2. Authentication bypass via OAuth implicit flow
3.23.3. SSRF via OpenID dynamic client registration
3.23.4. Forced OAuth profile linking
3.23.5. OAuth account hijacking via redirect_uri
3.23.6. Stealing OAuth access tokens via an open redirect
3.23.7. Stealing OAuth access tokens via a proxy page
3.24. File upload vulnerabilities
3.24.1. Remote code execution via web shell upload
3.24.2. Web shell upload via Content-Type restriction bypass
3.24.3. Web shell upload via path traversal
3.24.4. Web shell upload via extension blacklist bypass
3.24.5. Web shell upload via obfuscated file extension
3.24.6. Remote code execution via polyglot web shell upload
3.24.7. Web shell upload via race condition
3.25. JWT
3.25.1. JWT authentication bypass via unverified signature
3.25.2. JWT authentication bypass via flawed signature verification
3.25.3. JWT authentication bypass via weak signing key
3.25.4. JWT authentication bypass via jwk header injection
3.25.5. JWT authentication bypass via jku header injection
3.25.6. JWT authentication bypass via kid header path traversal
3.25.7. JWT authentication bypass via algorithm confusion
3.25.8. JWT authentication bypass via algorithm confusion with no exposed key
3.26. Prototype pollution
3.26.1. Client-side prototype pollution via browser APIs
3.26.2. DOM XSS via client-side prototype pollution
3.26.3. DOM XSS via an alternative prototype pollution vector
3.26.4. Client-side prototype pollution via flawed sanitization
3.26.5. Client-side prototype pollution in third-party libraries
3.26.6. Privilege escalation via server-side prototype pollution
3.26.7. Detecting server-side prototype pollution without polluted property reflection
3.26.8. Bypassing flawed input filters for server-side prototype pollution
3.26.9. Remote code execution via server-side prototype pollution
3.26.10. Exfiltrating sensitive data via server-side prototype pollution
3.27. GraphQL API vulnerabilities
3.27.1. Accessing private GraphQL posts
3.27.2. Accidental exposure of private GraphQL fields
3.27.3. Finding a hidden GraphQL endpoint
3.27.4. Bypassing GraphQL brute force protections
3.27.5. Performing CSRF exploits over GraphQL
3.28. Race Condition
3.28.1. Limit overrun race conditions
3.28.2. Bypassing rate limits via race conditions
3.28.3. Multi-endpoint race conditions
3.28.4. Single-endpoint race conditions
3.28.5. Exploiting time-sensitive vulnerabilities
3.28.6. Partial construction race conditions
3.29. NoSQL injection
3.29.1. Detecting NoSQL injection
3.29.2. Exploiting NoSQL operator injection to bypass authentication
3.29.3. Exploiting NoSQL injection to extract data
3.29.4. Exploiting NoSQL operator injection to extract unknown fields
3.30. Web LLM attacks
3.30.1. Exploiting LLM APIs with excessive agency
3.30.2. Exploiting vulnerabilities in LLM APIs
3.30.3. Indirect prompt injection
3.30.4. Exploiting insecure output handling in LLMs
3.31. Web Cache Deception
3.31.1. Exploiting path mapping for web cache deception
3.31.2. Exploiting path delimiters for web cache deception
3.31.3. Exploiting origin server normalization for web cache deception
3.31.4. Exploiting cache server normalization for web cache deception
3.31.5. Exploiting exact-match cache rules for web cache deception