80,443 - Méthodologie de Pentesting Web

Reading time: 21 minutes

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Infos de base

Le service web est le service le plus commun et étendu, et de nombreux types de vulnérabilités existent.

Port par défaut: 80 (HTTP), 443 (HTTPS)

bash
PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  ssl/https
bash
nc -v domain.com 80 # GET / HTTP/1.0
openssl s_client -connect domain.com:443 # GET / HTTP/1.0

Guide Web API

Web API Pentesting

Résumé de la méthodologie

Dans cette méthodologie, nous allons supposer que vous allez attaquer un domaine (ou sous-domaine) et uniquement celui-ci. Vous devez donc appliquer cette méthodologie à chaque domaine, sous-domaine ou IP découvert(e) avec un serveur web indéterminé dans le périmètre.

  • Commencez par identifier les technologies utilisées par le serveur web. Cherchez des astuces à garder en tête pendant le reste du test si vous pouvez identifier la tech avec succès.
  • Existe-t-il une vulnérabilité connue pour la version de la technologie ?
  • Y a-t-il une tech connue utilisée ? Une astuce utile pour extraire plus d'informations ?
  • Y a-t-il un scanner spécialisé à lancer (par exemple wpscan) ?
  • Lancez des scanners à usage général. On ne sait jamais s'ils vont trouver quelque chose ou des informations intéressantes.
  • Commencez par les vérifications initiales : robots, sitemap, erreur 404 et scan SSL/TLS (si HTTPS).
  • Commencez le spidering de la page web : il est temps de trouver tous les fichiers, dossiers et paramètres utilisés. Vérifiez aussi les découvertes particulières.
  • Notez que chaque fois qu'un nouveau répertoire est découvert lors du brute-forcing ou du spidering, il doit être spideré.
  • Directory Brute-Forcing : Essayez de brute-forcer tous les dossiers découverts à la recherche de nouveaux fichiers et répertoires.
  • Notez que chaque fois qu'un nouveau répertoire est découvert lors du brute-forcing ou du spidering, il doit être Brute-Forced.
  • Backups checking : Testez si vous pouvez trouver des backups des fichiers découverts en ajoutant des extensions de sauvegarde courantes.
  • Brute-Force parameters : Essayez de trouver des paramètres cachés.
  • Une fois que vous avez identifié tous les endpoints possibles acceptant des entrées utilisateur, vérifiez tous les types de vulnérabilités qui y sont liées.
  • Suivez cette checklist

Version du serveur (Vulnérable ?)

Identifier

Vérifiez s'il existe des vulnérabilités connues pour la version du serveur en cours d'exécution.
Les HTTP headers et les cookies de la réponse peuvent être très utiles pour identifier les technologies et/ou la version utilisée. Nmap scan peut identifier la version du serveur, mais les outils whatweb, webtech ou https://builtwith.com/** :**

bash
whatweb -a 1 <URL> #Stealthy
whatweb -a 3 <URL> #Aggresive
webtech -u <URL>
webanalyze -host https://google.com -crawl 2

Search for vulnerabilities of the web application version

Vérifier s'il y a un WAF

Astuces techniques Web

Quelques astuces pour trouver des vulnérabilités dans différentes technologies bien connues utilisées :

Prenez en compte que le même domaine peut utiliser différentes technologies sur différents ports, dossiers et sous-domaines.
Si l'application web utilise l'une des tech/platform listées ci‑dessus ou une autre, n'oubliez pas de chercher sur Internet de nouvelles astuces (et dites‑moi !).

Revue du code source

Si le code source de l'application est disponible sur github, en plus d'effectuer par vous‑même un White box test de l'application, il existe des informations qui pourraient être utiles pour le Black-Box testing en cours :

  • Y a‑t‑il un Change-log ou Readme ou Version file ou quoi que ce soit avec des version info accessible via le web ?
  • Comment et où sont sauvegardés les credentials ? Y a‑t‑il un (accessible ?) file avec des credentials (usernames or passwords) ?
  • Les passwords sont‑ils en plain text, encrypted ou quel algorithme de hachage est utilisé ?
  • Utilise‑t‑il une master key pour chiffrer quelque chose ? Quel algorithm est utilisé ?
  • Pouvez‑vous accéder à l'un de ces fichiers en exploitant une vulnérabilité ?
  • Y a‑t‑il des informations intéressantes dans le github (issues résolues et non résolues) ? Ou dans l'historique des commits (peut‑être un password introduit dans un ancien commit) ?

Source code Review / SAST Tools

Scanners automatiques

Scanners automatiques à usage général

bash
nikto -h <URL>
whatweb -a 4 <URL>
wapiti -u <URL>
W3af
zaproxy #You can use an API
nuclei -ut && nuclei -target <URL>

# https://github.com/ignis-sec/puff (client side vulns fuzzer)
node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi2rVUN/?query=FUZZ"

Scanners CMS

Si un CMS est utilisé, n'oubliez pas de lancer un scanner, vous pourriez trouver quelque chose d'intéressant :

Clusterd: JBoss, ColdFusion, WebLogic, Tomcat, Railo, Axis2, Glassfish
CMSScan: WordPress, Drupal, Joomla, vBulletin sites web pour des problèmes de sécurité. (GUI)
VulnX: Joomla, Wordpress, Drupal, PrestaShop, Opencart
CMSMap: (W)ordpress, (J)oomla, (D)rupal ou (M)oodle
droopscan: Drupal, Joomla, Moodle, Silverstripe, Wordpress

bash
cmsmap [-f W] -F -d <URL>
wpscan --force update -e --url <URL>
joomscan --ec -u <URL>
joomlavs.rb #https://github.com/rastating/joomlavs

À ce stade vous devriez déjà avoir quelques informations sur le serveur web utilisé par le client (si des données sont fournies) et quelques astuces à garder en tête pendant le test. Si vous avez de la chance, vous avez même trouvé un CMS et lancé un scanner.

Step-by-step Web Application Discovery

À partir de ce point nous allons commencer à interagir avec l'application web.

Initial checks

Default pages with interesting info:

  • /robots.txt
  • /sitemap.xml
  • /crossdomain.xml
  • /clientaccesspolicy.xml
  • /.well-known/
  • Vérifiez aussi les commentaires dans les pages principales et secondaires.

Forcing errors

Les serveurs web peuvent se comporter de manière inattendue lorsque des données étranges leur sont envoyées. Cela peut ouvrir des vulnerabilities ou provoquer une disclosure sensitive information.

  • Accédez à des fake pages comme /whatever_fake.php (.aspx,.html,.etc)
  • Add "[]", "]]", and "[[" dans les cookie values et les parameter values pour créer des erreurs
  • Générez une erreur en donnant comme entrée /~randomthing/%s à la fin de l'URL
  • Essayez des different HTTP Verbs comme PATCH, DEBUG ou des verbes incorrects comme FAKE

Check if you can upload files (PUT verb, WebDav)

Si vous trouvez que WebDav est enabled mais que vous n'avez pas assez de permissions pour uploading files dans le dossier racine, essayez de :

  • Brute Force credentials
  • Upload files via WebDav dans le reste des found folders à l'intérieur de la page web. Vous pouvez avoir la permission d'uploader des fichiers dans d'autres dossiers.

SSL/TLS vulnerabilites

  • Si l'application n'oblige pas l'utilisation de HTTPS dans une quelconque partie, alors elle est vulnérable à MitM
  • Si l'application envoie des données sensibles (mots de passe) via HTTP. Alors c'est une vulnérabilité importante.

Utilisez testssl.sh pour vérifier les vulnerabilities (dans les programmes de Bug Bounty, ce genre de vulnérabilités ne sera probablement pas accepté) et utilisez a2sv pour revérifier les vulnérabilités:

bash
./testssl.sh [--htmlfile] 10.10.10.10:443
#Use the --htmlfile to save the output inside an htmlfile also

# You can also use other tools, by testssl.sh at this momment is the best one (I think)
sslscan <host:port>
sslyze --regular <ip:port>

Information about SSL/TLS vulnerabilities:

Spidering

Lancez une sorte de spider sur l'application web. L'objectif du spider est de trouver autant de chemins que possible depuis l'application testée. Par conséquent, le crawling web et les sources externes doivent être utilisés pour découvrir le maximum de chemins valides.

  • gospider (go) : HTML spider, LinkFinder dans les fichiers JS et sources externes (Archive.org, CommonCrawl.org, VirusTotal.com).
  • hakrawler (go) : HML spider, avec LinkFinder pour les fichiers JS et Archive.org comme source externe.
  • dirhunt (python) : HTML spider, indique aussi les "juicy files".
  • evine (go) : CLI interactive HTML spider. Cherche aussi dans Archive.org.
  • meg (go) : Cet outil n'est pas un spider mais peut être utile. Indiquez un fichier avec des hosts et un fichier avec des paths ; meg va récupérer chaque path sur chaque host et sauvegarder la réponse.
  • urlgrab (go) : HTML spider avec rendu JS. Cependant, il semble non maintenu, la version précompilée est ancienne et le code actuel ne compile pas.
  • gau (go) : HTML spider qui utilise des providers externes (wayback, otx, commoncrawl).
  • ParamSpider : Ce script trouvera les URLs avec paramètres et les listera.
  • galer (go) : HTML spider avec rendu JS.
  • LinkFinder (python) : HTML spider, avec capacités de JS beautify capable de rechercher de nouveaux chemins dans les fichiers JS. Il peut valoir le coup de jeter un œil aussi à JSScanner, qui est un wrapper de LinkFinder.
  • goLinkFinder (go) : Pour extraire des endpoints à la fois dans le source HTML et dans les fichiers javascript embarqués. Utile pour bug hunters, red teamers, infosec ninjas.
  • JSParser (python2.7) : Script python 2.7 utilisant Tornado et JSBeautifier pour parser les URLs relatives depuis les fichiers JavaScript. Utile pour découvrir facilement les requêtes AJAX. Semble non maintenu.
  • relative-url-extractor (ruby) : Donné un fichier (HTML), il extraira les URLs en utilisant des expressions régulières astucieuses pour trouver et extraire les URLs relatives depuis les fichiers minifiés.
  • JSFScan (bash, plusieurs outils) : Rassemble des informations intéressantes depuis les fichiers JS en utilisant plusieurs outils.
  • subjs (go) : Trouve les fichiers JS.
  • page-fetch (go) : Charge une page dans un navigateur headless et affiche toutes les urls chargées pour afficher la page.
  • Feroxbuster (rust) : Outil de découverte de contenu mixant plusieurs options des outils précédents.
  • Javascript Parsing : Extension Burp pour trouver des paths et params dans les fichiers JS.
  • Sourcemapper : Outil qui, donné l'URL du .js.map, récupère le code JS beautifié.
  • xnLinkFinder : Outil pour découvrir des endpoints pour une cible donnée.
  • waymore: Découvre des liens depuis la wayback machine (télécharge aussi les réponses depuis la wayback et recherche plus de liens).
  • HTTPLoot (go) : Crawl (même en remplissant des formulaires) et trouve aussi des infos sensibles en utilisant des regex spécifiques.
  • SpiderSuite : Spider Suite est un crawler/spider GUI multi-fonctions avancé conçu pour les professionnels de la cybersécurité.
  • jsluice (go) : Package Go et command-line tool pour extraire URLs, paths, secrets et autres données intéressantes depuis le code source JavaScript.
  • ParaForge : ParaForge est une simple Burp Suite extension pour extraire les paramètres et endpoints depuis les requêtes afin de créer des wordlists personnalisées pour le fuzzing et l'énumération.
  • katana (go) : Excellent outil pour cela.
  • Crawley (go) : Affiche chaque lien qu'il trouve.

Brute Force directories and files

Start brute-forcing from the root folder and be sure to brute-force all the directories found using this method and all the directories discovered by the Spidering (you can do this brute-forcing recursively and appending at the beginning of the used wordlist the names of the found directories).
Outils :

  • Dirb / Dirbuster - Inclus dans Kali, old (et slow) mais fonctionnel. Permet les certificats auto-signés et la recherche récursive. Trop lent comparé aux autres options.
  • Dirsearch (python): Il n'autorise pas les certificats auto-signés mais permet la recherche récursive.
  • Gobuster (go) : Permet les certificats auto-signés, il n'a pas de recherche recursive.
  • Feroxbuster - Fast, supports recursive search.
  • wfuzz wfuzz -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt https://domain.com/api/FUZZ
  • ffuf - Fast: ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ
  • uro (python) : Ce n'est pas un spider mais un outil qui, donné la liste d'URLs trouvées, va supprimer les URLs "dupliquées".
  • Scavenger : Burp Extension pour créer une liste de répertoires depuis l'historique Burp de différentes pages.
  • TrashCompactor : Supprime les URLs avec fonctionnalités dupliquées (basé sur les imports js).
  • Chamaleon : Utilise wapalyzer pour détecter les technologies utilisées et sélectionner les wordlists à utiliser.

Recommended dictionaries:

Note that anytime a new directory is discovered during brute-forcing or spidering, it should be Brute-Forced.

What to check on each file found

  • Broken link checker : Trouve les liens cassés dans les HTML qui peuvent être vulnérables à des takeovers.
  • File Backups : Une fois que vous avez trouvé tous les fichiers, cherchez des backups des fichiers exécutables (".php", ".aspx"...). Variations communes pour les noms de backup : file.ext~, #file.ext#, ~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old. Vous pouvez aussi utiliser l'outil bfac ou backup-gen.
  • Discover new parameters : Utilisez des outils comme Arjun, parameth, x8 et Param Miner pour découvrir des paramètres cachés. Si possible, recherchez des paramètres cachés dans chaque fichier web exécutable.
  • Arjun all default wordlists: https://github.com/s0md3v/Arjun/tree/master/arjun/db
  • Param-miner “params” : https://github.com/PortSwigger/param-miner/blob/master/resources/params
  • Assetnote “parameters_top_1m”: https://wordlists.assetnote.io/
  • nullenc0de “params.txt”: https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773
  • Comments : Vérifiez les commentaires de tous les fichiers, vous pouvez y trouver des credentials ou des fonctionnalités cachées.
  • Si vous êtes en CTF, une astuce courante est de cacher des informations dans les commentaires à droite de la page (en utilisant des centaines d'espaces pour ne pas voir les données si vous ouvrez le source dans le navigateur). Autre possibilité : utiliser plusieurs nouvelles lignes et cacher des informations dans un commentaire en bas de la page web.
  • API keys : Si vous trouvez une API key, il existe des projets qui indiquent comment utiliser les API keys pour différentes plateformes : keyhacks, zile, truffleHog, SecretFinder, RegHex, DumpsterDive, EarlyBird
  • Google API keys : Si vous trouvez une API key commençant par AIzaSyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik vous pouvez utiliser le projet gmapapiscanner pour vérifier quelles APIs la clé peut appeler.
  • S3 Buckets : Pendant le spidering, regardez si un subdomain ou un lien est lié à un S3 bucket. Dans ce cas, check the permissions of the bucket.

Special findings

Pendant le spidering et le brute-forcing, vous pouvez tomber sur des éléments intéressants qu'il faut noter.

Interesting files

  • Cherchez des liens vers d'autres fichiers à l'intérieur des fichiers CSS.
  • If you find a .git file some information can be extracted
  • Si vous trouvez un .env, des informations telles que des api keys, mots de passe de db et d'autres données peuvent être trouvées.
  • Si vous trouvez des API endpoints, vous should also test them. Ce ne sont pas des fichiers, mais ils ressembleront probablement à des fichiers.
  • JS files : Dans la section spidering plusieurs outils pour extraire des paths depuis les fichiers JS ont été mentionnés. Il serait aussi intéressant de monitorer chaque fichier JS trouvé, car dans certaines occasions, un changement peut indiquer qu'une vulnérabilité potentielle a été introduite dans le code. Vous pouvez par exemple utiliser JSMon.
  • Vous devriez aussi analyser les fichiers JS découverts avec RetireJS ou JSHole pour voir s'ils sont vulnérables.
  • Javascript Deobfuscator and Unpacker: https://lelinhtinh.github.io/de4js/, https://www.dcode.fr/javascript-unobfuscator
  • Javascript Beautifier: http://jsbeautifier.org/, http://jsnice.org/
  • JsFuck deobfuscation (javascript with chars:"[]!+" https://enkhee-osiris.github.io/Decoder-JSFuck/)
  • TrainFuck](https://github.com/taco-c/trainfuck): +72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.
  • Dans de nombreuses occasions, il faudra comprendre les expressions régulières utilisées. Cela sera utile : https://regex101.com/ ou https://pythonium.net/regex
  • Vous pouvez aussi monitorer les fichiers où des forms ont été détectés, car un changement dans un paramètre ou l'apparition d'un nouveau formulaire peut indiquer une nouvelle fonctionnalité potentiellement vulnérable.

403 Forbidden/Basic Authentication/401 Unauthorized (bypass)

403 & 401 Bypasses

502 Proxy Error

Si une page répond avec ce code, c'est probablement un proxy mal configuré. Si vous envoyez une requête HTTP comme : GET https://google.com HTTP/1.1 (avec le Host header et d'autres headers courants), le proxy tentera d'accéder à google.com et vous aurez trouvé un SSRF.

NTLM Authentication - Info disclosure

Si le serveur demandant l'authentification est Windows ou si vous tombez sur un login demandant vos credentials (et demandant le domain), vous pouvez provoquer une divulgation d'informations.
Envoyez l'header : “Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=” et, en raison du fonctionnement de l'authentification NTLM, le serveur répondra avec des informations internes (version d'IIS, version de Windows...) dans l'en-tête "WWW-Authenticate".
Vous pouvez automatiser cela en utilisant le plugin nmap "http-ntlm-info.nse".

HTTP Redirect (CTF)

Il est possible de placer du contenu dans une Redirection. Ce contenu ne sera pas affiché à l'utilisateur (le navigateur exécutera la redirection) mais quelque chose peut être caché dedans.

Web Vulnerabilities Checking

Maintenant qu'une énumération complète de l'application web a été effectuée, il est temps de vérifier de nombreuses vulnérabilités possibles. Vous pouvez trouver la checklist ici :

Web Vulnerabilities Methodology

Find more info about web vulns in:

Monitor Pages for changes

Vous pouvez utiliser des outils tels que https://github.com/dgtlmoon/changedetection.io pour monitorer des pages afin de détecter des modifications qui pourraient introduire des vulnérabilités.

HackTricks Automatic Commands

Protocol_Name: Web    #Protocol Abbreviation if there is one.
Port_Number:  80,443     #Comma separated if there is more than one.
Protocol_Description: Web         #Protocol Abbreviation Spelled out

Entry_1:
Name: Notes
Description: Notes for Web
Note: |
https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/index.html

Entry_2:
Name: Quick Web Scan
Description: Nikto and GoBuster
Command: nikto -host {Web_Proto}://{IP}:{Web_Port} &&&& gobuster dir -w {Small_Dirlist} -u {Web_Proto}://{IP}:{Web_Port} && gobuster dir -w {Big_Dirlist} -u {Web_Proto}://{IP}:{Web_Port}

Entry_3:
Name: Nikto
Description: Basic Site Info via Nikto
Command: nikto -host {Web_Proto}://{IP}:{Web_Port}

Entry_4:
Name: WhatWeb
Description: General purpose auto scanner
Command: whatweb -a 4 {IP}

Entry_5:
Name: Directory Brute Force Non-Recursive
Description:  Non-Recursive Directory Brute Force
Command: gobuster dir -w {Big_Dirlist} -u {Web_Proto}://{IP}:{Web_Port}

Entry_6:
Name: Directory Brute Force Recursive
Description: Recursive Directory Brute Force
Command: python3 {Tool_Dir}dirsearch/dirsearch.py -w {Small_Dirlist} -e php,exe,sh,py,html,pl -f -t 20 -u {Web_Proto}://{IP}:{Web_Port} -r 10

Entry_7:
Name: Directory Brute Force CGI
Description: Common Gateway Interface Brute Force
Command: gobuster dir -u {Web_Proto}://{IP}:{Web_Port}/ -w /usr/share/seclists/Discovery/Web-Content/CGIs.txt -s 200

Entry_8:
Name: Nmap Web Vuln Scan
Description: Tailored Nmap Scan for web Vulnerabilities
Command: nmap -vv --reason -Pn -sV -p {Web_Port} --script=`banner,(http* or ssl*) and not (brute or broadcast or dos or external or http-slowloris* or fuzzer)` {IP}

Entry_9:
Name: Drupal
Description: Drupal Enumeration Notes
Note: |
git clone https://github.com/immunIT/drupwn.git for low hanging fruit and git clone https://github.com/droope/droopescan.git for deeper enumeration

Entry_10:
Name: WordPress
Description: WordPress Enumeration with WPScan
Command: |
?What is the location of the wp-login.php? Example: /Yeet/cannon/wp-login.php
wpscan --url {Web_Proto}://{IP}{1} --enumerate ap,at,cb,dbe && wpscan --url {Web_Proto}://{IP}{1} --enumerate u,tt,t,vp --passwords {Big_Passwordlist} -e

Entry_11:
Name: WordPress Hydra Brute Force
Description: Need User (admin is default)
Command: hydra -l admin -P {Big_Passwordlist} {IP} -V http-form-post '/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log In&testcookie=1:S=Location'

Entry_12:
Name: Ffuf Vhost
Description: Simple Scan with Ffuf for discovering additional vhosts
Command: ffuf -w {Subdomain_List}:FUZZ -u {Web_Proto}://{Domain_Name} -H "Host:FUZZ.{Domain_Name}" -c -mc all {Ffuf_Filters}

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks