80,443 - Metodologia di Pentesting Web
Reading time: 20 minutes
tip
Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Impara e pratica il hacking Azure:
HackTricks Training Azure Red Team Expert (AzRTE)
Supporta HackTricks
- Controlla i piani di abbonamento!
- Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
- Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos github.
Informazioni di base
Il servizio web è il servizio più comune e diffuso e esistono molti tipi diversi di vulnerabilità.
Porta di default: 80 (HTTP), 443(HTTPS)
PORT STATE SERVICE
80/tcp open http
443/tcp open ssl/https
nc -v domain.com 80 # GET / HTTP/1.0
openssl s_client -connect domain.com:443 # GET / HTTP/1.0
Linee guida Web API
Riepilogo della metodologia
In questa metodologia supponiamo che tu stia per attaccare un dominio (o sottodominio) e solo quello. Quindi, dovresti applicare questa metodologia a ogni dominio, sottodominio o IP scoperto con server web non determinato all'interno dello scope.
- Inizia identificando le tecnologie utilizzate dal web server. Cerca trucchi da tenere a mente per il resto del test se riesci a identificare con successo la tecnologia.
- Esistono vulnerabilità note per la versione della tecnologia?
- Stai usando qualche well known tech? Qualche useful trick per estrarre più informazioni?
- Qualche specialised scanner da eseguire (come wpscan)?
- Avvia general purposes scanners. Non sai mai se troveranno qualcosa o informazioni interessanti.
- Inizia con i controlli iniziali: robots, sitemap, errore 404 e SSL/TLS scan (se HTTPS).
- Avvia lo spidering della pagina web: è il momento di trovare tutti i possibili files, folders e parameters in uso. Inoltre, controlla eventuali scoperte particolari.
- Nota che ogni volta che una nuova directory viene scoperta durante brute-forcing o spidering, dovrebbe essere spidered.
- Directory Brute-Forcing: Prova a brute force tutte le folders scoperte cercando nuovi files e directories.
- Nota che ogni volta che una nuova directory viene scoperta durante brute-forcing o spidering, dovrebbe essere Brute-Forced.
- Backups checking: Verifica se puoi trovare backups dei discovered files aggiungendo estensioni di backup comuni.
- Brute-Force parameters: Prova a trovare hidden parameters.
- Una volta che hai identificato tutti i possibili endpoints che accettano user input, verifica tutti i tipi di vulnerabilities correlati.
- Segui questa checklist
Versione del server (Vulnerabile?)
Identifica
Verifica se esistono vulnerabilità note per la versione del server in esecuzione.
Le HTTP headers e i cookies della response possono essere molto utili per identificare le tecnologie e/o la versione in uso. Nmap scan può identificare la versione del server, ma potrebbero essere utili anche gli strumenti whatweb, webtech o https://builtwith.com/:
whatweb -a 1 <URL> #Stealthy
whatweb -a 3 <URL> #Aggresive
webtech -u <URL>
webanalyze -host https://google.com -crawl 2
Cerca le vulnerabilities della versione dell'applicazione web
Controlla se è presente un WAF
- https://github.com/EnableSecurity/wafw00f
- https://github.com/Ekultek/WhatWaf.git
- https://nmap.org/nsedoc/scripts/http-waf-detect.html
Trucchi per tecnologie web
Alcuni trucchi per trovare vulnerabilities in diverse technologies ben note in uso:
- AEM - Adobe Experience Cloud
- Apache
- Artifactory
- Buckets
- CGI
- Drupal
- Flask
- Git
- Golang
- GraphQL
- H2 - Java SQL database
- ISPConfig
- IIS tricks
- Microsoft SharePoint
- JBOSS
- Jenkins
- Jira
- Joomla
- JSP
- Laravel
- Moodle
- Nginx
- PHP (php has a lot of interesting tricks that could be exploited)
- Python
- Spring Actuators
- Symphony
- Tomcat
- VMWare
- Web API Pentesting
- WebDav
- Werkzeug
- Wordpress
- Electron Desktop (XSS to RCE)
Tieni conto che lo stesso dominio può usare tecnologie diverse su porte, cartelle e sottodomini diversi.
Se l'applicazione web sta usando una tech/platform nota elencata prima o qualsiasi altra, non dimenticare di cercare su Internet nuovi trucchi (e fammi sapere!).
Source Code Review
Se il source code dell'applicazione è disponibile su github, oltre a eseguire da parte tua un test White box dell'applicazione ci sono alcune informazioni che potrebbero essere utili per l'attuale test Black-Box:
- Esiste un Change-log o Readme o Version file o qualcosa con version info accessibile via web?
- Come e dove sono salvate le credentials? C'è qualche (accessibile?) file con credentials (usernames o passwords)?
- Le passwords sono in plain text, encrypted o quale hashing algorithm viene usato?
- Usa qualche master key per cifrare qualcosa? Quale algorithm viene usato?
- Puoi accedere a uno di questi file sfruttando qualche vulnerability?
- C'è qualche informazione interessante su github (issues risolti e non)? O nella commit history (forse qualche password introdotta in un commit vecchio)?
Source code Review / SAST Tools
Automatic scanners
General purpose automatic scanners
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"
Scanner per CMS
Se è presente un CMS, non dimenticare di eseguire uno scanner, potresti trovare qualcosa di succoso:
Clusterd: JBoss, ColdFusion, WebLogic, Tomcat, Railo, Axis2, Glassfish
CMSScan: WordPress, Drupal, Joomla, vBulletin siti web per problemi di sicurezza. (GUI)
VulnX: Joomla, Wordpress, Drupal, PrestaShop, Opencart
CMSMap: (W)ordpress, (J)oomla, (D)rupal o (M)oodle
droopscan: Drupal, Joomla, Moodle, Silverstripe, Wordpress
cmsmap [-f W] -F -d <URL>
wpscan --force update -e --url <URL>
joomscan --ec -u <URL>
joomlavs.rb #https://github.com/rastating/joomlavs
A questo punto dovresti già avere alcune informazioni sul web server usato dal cliente (se vengono forniti dati) e qualche trucco da tenere a mente durante il test. Se sei fortunato hai persino trovato un CMS e lanciato qualche scanner.
Scoperta passo-passo della Web Application
Da questo punto inizieremo a interagire con l'applicazione web.
Controlli iniziali
Pagine di default con informazioni interessanti:
- /robots.txt
- /sitemap.xml
- /crossdomain.xml
- /clientaccesspolicy.xml
- /.well-known/
- Controlla anche i commenti nelle pagine principali e secondarie.
Forzare errori
I web server possono comportarsi in modo inaspettato quando vengono inviati dati strani. Questo può aprire vulnerabilities o rivelare informazioni sensibili.
- Accedi a fake pages come /whatever_fake.php (.aspx,.html,.etc)
- Aggiungi "[]", "]]", and "[[" in cookie values and parameter values per creare errori
- Genera un errore fornendo in input
/~randomthing/%s
alla fine dell'URL - Prova different HTTP Verbs come PATCH, DEBUG o errati come FAKE
Check if you can upload files (PUT verb, WebDav)
Se trovi che WebDav è enabled ma non hai sufficienti permessi per uploading files nella cartella root prova a:
- Brute Force credentials
- Upload files via WebDav to the rest of found folders inside the web page. You may have permissions to upload files in other folders.
SSL/TLS vulnerabilites
- Se l'applicazione non forza l'uso di HTTPS in nessuna parte, allora è vulnerable to MitM
- Se l'applicazione sta inviando dati sensibili (passwords) usando HTTP. Allora è una high vulnerability.
Usa testssl.sh per controllare le vulnerabilities (In Bug Bounty programs probabilmente questo tipo di vulnerabilities non verrà accettato) e usa a2sv to recheck the vulnerabilities:
./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>
Informazioni sulle vulnerabilità SSL/TLS:
- https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/
- https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/
Spidering
Avvia una sorta di spider all'interno del web. Lo scopo dello spider è trovare quanti più percorsi possibile dell'applicazione testata. Perciò, web crawling e fonti esterne dovrebbero essere usate per trovare il maggior numero possibile di percorsi validi.
- gospider (go): HTML spider, LinkFinder in JS files and external sources (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com).
- hakrawler (go): HML spider, with LinkFider for JS files and Archive.org as external source.
- dirhunt (python): HTML spider, also indicates "juicy files".
- evine (go): Interactive CLI HTML spider. It also searches in Archive.org
- meg (go): This tool isn't a spider but it can be useful. You can just indicate a file with hosts and a file with paths and meg will fetch each path on each host and save the response.
- urlgrab (go): HTML spider with JS rendering capabilities. However, it looks like it's unmaintained, the precompiled version is old and the current code doesn't compile
- gau (go): HTML spider that uses external providers (wayback, otx, commoncrawl)
- ParamSpider: This script will find URLs with parameter and will list them.
- galer (go): HTML spider with JS rendering capabilities.
- LinkFinder (python): HTML spider, with JS beautify capabilities capable of search new paths in JS files. It could be worth it also take a look to JSScanner, which is a wrapper of LinkFinder.
- goLinkFinder (go): To extract endpoints in both HTML source and embedded javascript files. Useful for bug hunters, red teamers, infosec ninjas.
- JSParser (python2.7): A python 2.7 script using Tornado and JSBeautifier to parse relative URLs from JavaScript files. Useful for easily discovering AJAX requests. Looks like unmaintained.
- relative-url-extractor (ruby): Given a file (HTML) it will extract URLs from it using nifty regular expression to find and extract the relative URLs from ugly (minify) files.
- JSFScan (bash, several tools): Gather interesting information from JS files using several tools.
- subjs (go): Find JS files.
- page-fetch (go): Load a page in a headless browser and print out all the urls loaded to load the page.
- Feroxbuster (rust): Content discovery tool mixing several options of the previous tools
- Javascript Parsing: A Burp extension to find path and params in JS files.
- Sourcemapper: A tool that given the .js.map URL will get you the beatified JS code
- xnLinkFinder: This is a tool used to discover endpoints for a given target.
- waymore: Discover links from the wayback machine (also downloading the responses in the wayback and looking for more links
- HTTPLoot (go): Crawl (even by filling forms) and also find sensitive info using specific regexes.
- SpiderSuite: Spider Suite is an advance multi-feature GUI web security Crawler/Spider designed for cyber security professionals.
- jsluice (go): It's a Go package and command-line tool for extracting URLs, paths, secrets, and other interesting data from JavaScript source code.
- ParaForge: ParaForge is a simple Burp Suite extension to extract the paramters and endpoints from the request to create custom wordlist for fuzzing and enumeration.
- katana (go): Awesome tool for this.
- Crawley (go): Print every link it's able to find.
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).
Tools:
- Dirb / Dirbuster - Included in Kali, old (and slow) but functional. Allow auto-signed certificates and recursive search. Too slow compared with th other options.
- Dirsearch (python): It doesn't allow auto-signed certificates but allows recursive search.
- Gobuster (go): It allows auto-signed certificates, it doesn't have recursive search.
- 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): This isn't a spider but a tool that given the list of found URLs will to delete "duplicated" URLs.
- Scavenger: Burp Extension to create a list of directories from the burp history of different pages
- TrashCompactor: Remove URLs with duplicated functionalities (based on js imports)
- Chamaleon: It uses wapalyzer to detect used technologies and select the wordlists to use.
Recommended dictionaries:
- https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt
- Dirsearch included dictionary
- http://gist.github.com/jhaddix/b80ea67d85c13206125806f0828f4d10
- Assetnote wordlists
- https://github.com/danielmiessler/SecLists/tree/master/Discovery/Web-Content
- raft-large-directories-lowercase.txt
- directory-list-2.3-medium.txt
- RobotsDisallowed/top10000.txt
- https://github.com/random-robbie/bruteforce-lists
- https://github.com/google/fuzzing/tree/master/dictionaries
- https://github.com/six2dez/OneListForAll
- https://github.com/random-robbie/bruteforce-lists
- https://github.com/ayoubfathi/leaky-paths
- /usr/share/wordlists/dirb/common.txt
- /usr/share/wordlists/dirb/big.txt
- /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
Notare che ogni volta che viene scoperta una nuova directory durante brute-forcing o spidering, questa dovrebbe essere brute-forced.
What to check on each file found
- Broken link checker: Find broken links inside HTMLs that may be prone to takeovers
- File Backups: Una volta trovati tutti i file, cerca backup di tutti i file eseguibili (".php", ".aspx"...). Variazioni comuni per il nome di un backup sono: file.ext~, #file.ext#, ~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old. Puoi anche usare lo strumento bfac or backup-gen.
- Discover new parameters: Puoi usare strumenti come Arjun, parameth, x8 and Param Miner per scoprire parametri nascosti. Se possibile, prova a cercare parametri nascosti in ogni file web eseguibile.
- 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: Controlla i commenti di tutti i file, potresti trovare credentials o funzionalità nascoste.
- If you are playing CTF, a "common" trick is to hide information inside comments at the right of the page (using hundreds of spaces so you don't see the data if you open the source code with the browser). Other possibility is to use several new lines and hide information in a comment at the bottom of the web page.
- API keys: If you find any API key there is guide that indicates how to use API keys of different platforms: keyhacks, zile, truffleHog, SecretFinder, RegHex, DumpsterDive, EarlyBird
- Google API keys: If you find any API key looking like AIzaSyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik you can use the project gmapapiscanner to check which apis the key can access.
- S3 Buckets: While spidering look if any subdomain or any link is related with some S3 bucket. In that case, check the permissions of the bucket.
Special findings
While performing the spidering and brute-forcing you could find interesting things that you have to notice.
Interesting files
- Look for links to other files inside the CSS files.
- If you find a .git file some information can be extracted
- If you find a .env information such as api keys, dbs passwords and other information can be found.
- If you find API endpoints you should also test them. These aren't files, but will probably "look like" them.
- JS files: In the spidering section several tools that can extract path from JS files were mentioned. Also, It would be interesting to monitor each JS file found, as in some ocations, a change may indicate that a potential vulnerability was introduced in the code. You could use for example JSMon.
- You should also check discovered JS files with RetireJS or JSHole to find if it's vulnerable.
- 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:
+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.
- On several occasions, you will need to understand the regular expressions used. This will be useful: https://regex101.com/ or https://pythonium.net/regex
- You could also monitor the files were forms were detected, as a change in the parameter or the apearance f a new form may indicate a potential new vulnerable functionality.
403 Forbidden/Basic Authentication/401 Unauthorized (bypass)
502 Proxy Error
If any page responds with that code, it's probably a bad configured proxy. If you send a HTTP request like: GET https://google.com HTTP/1.1
(with the host header and other common headers), the proxy will try to access google.com and you will have found a SSRF.
NTLM Authentication - Info disclosure
If the running server asking for authentication is Windows or you find a login asking for your credentials (and asking for domain name), you can provoke an information disclosure.
Send the header: “Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”
and due to how the NTLM authentication works, the server will respond with internal info (IIS version, Windows version...) inside the header "WWW-Authenticate".
You can automate this using the nmap plugin "http-ntlm-info.nse".
HTTP Redirect (CTF)
It is possible to put content inside a Redirection. This content won't be shown to the user (as the browser will execute the redirection) but something could be hidden in there.
Web Vulnerabilities Checking
Now that a comprehensive enumeration of the web application has been performed it's time to check for a lot of possible vulnerabilities. You can find the checklist here:
Web Vulnerabilities Methodology
Find more info about web vulns in:
- https://six2dez.gitbook.io/pentest-book/others/web-checklist
- https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html
- https://owasp-skf.gitbook.io/asvs-write-ups/kbid-111-client-side-template-injection
Monitor Pages for changes
You can use tools such as https://github.com/dgtlmoon/changedetection.io to monitor pages for modifications that might insert vulnerabilities.
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
Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Impara e pratica il hacking Azure:
HackTricks Training Azure Red Team Expert (AzRTE)
Supporta HackTricks
- Controlla i piani di abbonamento!
- Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
- Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos github.