80,443 - Metodologia de Pentesting Web
Reading time: 20 minutes
tip
Aprenda e pratique Hacking AWS:
HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: 
HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Hacking Azure: 
HackTricks Training Azure Red Team Expert (AzRTE)
Supporte o HackTricks
- Confira os planos de assinatura!
 - Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-nos no Twitter 🐦 @hacktricks_live.
 - Compartilhe truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios do github.
 
Informações Básicas
O serviço web é o serviço mais comum e abrangente e existem muitos diferentes tipos de vulnerabilidades.
Porta padrão: 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
Orientações para Web API
Resumo da metodologia
Nesta metodologia vamos supor que você vai atacar um domínio (ou subdomínio) e somente esse. Portanto, você deve aplicar esta metodologia a cada domínio, subdomínio ou IP descoberto com servidor web indeterminado dentro do escopo.
- Comece por identificar as tecnologias usadas pelo servidor web. Procure por truques para ter em mente durante o restante do teste se você conseguir identificar a tecnologia com sucesso.
 - Há alguma vulnerabilidade conhecida da versão da tecnologia?
 - Está usando alguma tech bem conhecida? Algum truque útil para extrair mais informação?
 - Algum scanner especializado a rodar (como wpscan)?
 - Lance scanners de propósito geral. Você nunca sabe se vão encontrar algo ou alguma informação interessante.
 - Comece com as checagens iniciais: robots, sitemap, 404 error e SSL/TLS scan (if HTTPS).
 - Comece a spidering a página web: é hora de achar todos os possíveis files, folders e parameters being used. Também, verifique por special findings.
 - Note que sempre que um novo diretório for descoberto durante brute-forcing ou spidering, ele deve ser spidered.
 - Directory Brute-Forcing: Tente bruteforçar todas as pastas descobertas procurando por novos files e directories.
 - Note que sempre que um novo diretório for descoberto durante brute-forcing ou spidering, ele deve ser Brute-Forced.
 - Backups checking: Teste se você consegue encontrar backups de discovered files adicionando extensões de backup comuns.
 - Brute-Force parameters: Tente encontrar parâmetros ocultos.
 - Uma vez que você tenha identificado todos os possíveis endpoints que aceitam user input, verifique todos os tipos de vulnerabilidades relacionadas a eles.
 - Follow this checklist
 
Server Version (Vulnerable?)
Identificar
Verifique se há vulnerabilidades conhecidas para a versão do servidor que está em execução.
Os HTTP headers and cookies of the response podem ser muito úteis para identificar as tecnologias e/ou versão em uso. Nmap scan pode identificar a versão do servidor, mas também podem ser úteis as ferramentas whatweb, webtech ou https://builtwith.com/:
whatweb -a 1 <URL> #Stealthy
whatweb -a 3 <URL> #Aggresive
webtech -u <URL>
webanalyze -host https://google.com -crawl 2
Search por vulnerabilities of the web application version
Verificar se existe algum WAF
- https://github.com/EnableSecurity/wafw00f
 - https://github.com/Ekultek/WhatWaf.git
 - https://nmap.org/nsedoc/scripts/http-waf-detect.html
 
Web tech tricks
Algumas dicas para encontrar vulnerabilities em diferentes tecnologias bem conhecidas que estão a ser usadas:
- 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)
 - Sitecore
 - Zabbix
 
Leve em conta que o mesmo domínio pode estar a usar diferentes tecnologias em diferentes ports, pastas e subdomínios.
Se a aplicação web estiver a usar alguma tech/platform bem conhecida listada anteriormente ou qualquer outra, não se esqueça de procurar na Internet por novas dicas (e avisa-me!).
Source Code Review
Se o source code da aplicação estiver disponível no github, além de realizar por você mesmo um White box test da aplicação, há algumas informações que podem ser úteis para o atual Black-Box testing:
- Existe algum Change-log ou Readme ou ficheiro Version ou qualquer coisa com informação de versão acessível via web?
 - Como e onde são guardadas as credentials? Existe algum ficheiro (acessível?) com credentials (usernames ou passwords)?
 - As passwords estão em plain text, encriptadas ou qual algoritmo de hashing é usado?
 - Está a usar alguma master key para encriptar algo? Qual algoritmo é usado?
 - Consegue aceder a algum desses ficheiros explorando alguma vulnerabilidade?
 - Existe alguma informação interessante no github (issues resolvidas e não resolvidas)? Ou no commit history (talvez alguma password introduzida num commit antigo)?
 
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"
Scanners de CMS
Se um CMS for usado, não se esqueça de executar um scanner, talvez algo interessante seja encontrado:
Clusterd: JBoss, ColdFusion, WebLogic, Tomcat, Railo, Axis2, Glassfish
CMSScan: WordPress, Drupal, Joomla, vBulletin sites para problemas de segurança. (GUI)
VulnX: Joomla, Wordpress, Drupal, PrestaShop, Opencart
CMSMap: (W)ordpress, (J)oomla, (D)rupal ou (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
Neste ponto você já deve ter algumas informações sobre o web server utilizado pelo cliente (se algum dado foi fornecido) e alguns truques para ter em mente durante o teste. Se tiver sorte, você até pode ter encontrado um CMS e executado algum scanner.
Step-by-step Web Application Discovery
A partir deste ponto vamos começar a interagir com a aplicação web.
Initial checks
Default pages with interesting info:
- /robots.txt
 - /sitemap.xml
 - /crossdomain.xml
 - /clientaccesspolicy.xml
 - /.well-known/
 - Check also comments in the main and secondary pages.
 
Forcing errors
Servidores web podem comportar-se de forma inesperada quando dados estranhos são enviados a eles. Isso pode abrir vulnerabilidades ou divulgar informações sensíveis.
- Access fake pages like /whatever_fake.php (.aspx,.html,.etc)
 - Add "[]", "]]", and "[[" in cookie values and parameter values to create errors
 - Generate error by giving input as 
/~randomthing/%sat the end of URL - Try different HTTP Verbs like PATCH, DEBUG or wrong like FAKE
 
Verifique se você pode enviar arquivos (PUT verb, WebDav)
Se você descobrir que WebDav está enabled mas não tem permissões suficientes para uploading files no diretório root, tente:
- Brute Force credenciais
 - Upload files via WebDav para o restante das pastas encontradas dentro da página web. Você pode ter permissões para enviar arquivos em outras pastas.
 
SSL/TLS vulnerabilidades
- Se a aplicação não estiver forçando o uso de HTTPS em nenhuma parte, então está vulnerável a MitM
 - Se a aplicação estiver enviando dados sensíveis (senhas) usando HTTP, trata-se de uma vulnerabilidade alta.
 
Use testssl.sh para checar vulnerabilidades (em Bug Bounty programs provavelmente esse tipo de vulnerabilidade não será aceito) e use a2sv para recheck as vulnerabilidades:
./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:
- https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/
 - https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/
 
Spidering
Lance algum tipo de spider no site. O objetivo do spider é encontrar o máximo de caminhos possível da aplicação testada. Portanto, web crawling e fontes externas devem ser usadas para encontrar o máximo de caminhos válidos possível.
- gospider (go): HTML spider, LinkFinder em arquivos JS e fontes externas (Archive.org, CommonCrawl.org, VirusTotal.com).
 - hakrawler (go): HML spider, com LinkFider para arquivos JS e Archive.org como fonte externa.
 - dirhunt (python): HTML spider, também indica "juicy files".
 - evine (go): CLI interativo HTML spider. Também faz busca no Archive.org
 - meg (go): Esta ferramenta não é um spider mas pode ser útil. Você pode indicar um arquivo com hosts e um arquivo com paths e o meg vai buscar cada path em cada host e salvar a resposta.
 - urlgrab (go): HTML spider com capacidades de renderização JS. Porém, parece estar sem manutenção, a versão pré-compilada é antiga e o código atual não compila
 - gau (go): HTML spider que usa provedores externos (wayback, otx, commoncrawl)
 - ParamSpider: Este script vai encontrar URLs com parâmetros e listá-los.
 - galer (go): HTML spider com capacidades de renderização JS.
 - LinkFinder (python): HTML spider, com capacidades de JS beautify capaz de buscar novos caminhos em arquivos JS. Pode valer a pena também dar uma olhada no JSScanner, que é um wrapper do LinkFinder.
 - goLinkFinder (go): Para extrair endpoints tanto do source HTML quanto de arquivos javascript embutidos. Útil para bug hunters, red teamers, infosec ninjas.
 - JSParser (python2.7): Um script python 2.7 usando Tornado e JSBeautifier para parsear URLs relativas de arquivos JavaScript. Útil para descobrir pedidos AJAX facilmente. Parece desatualizado.
 - relative-url-extractor (ruby): Dado um arquivo (HTML) irá extrair URLs dele usando regex bacanas para encontrar e extrair URLs relativas de arquivos minificados.
 - JSFScan (bash, várias ferramentas): Coleta informação interessante de arquivos JS usando várias ferramentas.
 - subjs (go): Encontra arquivos JS.
 - page-fetch (go): Carrega uma página em um browser headless e imprime todas as urls carregadas para carregar a página.
 - Feroxbuster (rust): Ferramenta de descoberta de conteúdo que mistura várias opções das ferramentas anteriores
 - Javascript Parsing: Uma extensão do Burp para encontrar path e params em arquivos JS.
 - Sourcemapper: Uma ferramenta que, dado o .js.map URL, retorna o código JS beautified
 - xnLinkFinder: Ferramenta usada para descobrir endpoints para um dado target.
 - waymore: Descobre links do wayback machine (também baixa as respostas no wayback e busca por mais links
 - HTTPLoot (go): Crawl (até preenchendo forms) e também encontra informação sensível usando regexes específicos.
 - SpiderSuite: Spider Suite é um avançado Crawler/Spider GUI multi-featured para profissionais de segurança cibernética.
 - jsluice (go): É um pacote Go e command-line tool para extrair URLs, paths, secrets e outros dados interessantes do código fonte JavaScript.
 - ParaForge: ParaForge é uma simples Burp Suite extension para extrair os paramters e endpoints do request para criar wordlists customizadas para fuzzing e enumeração.
 - katana (go): Ferramenta excelente para isso.
 - Crawley (go): Imprime todo link que conseguir encontrar.
 
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
 
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: Find broken links inside HTMLs that may be prone to takeovers
 - File Backups: Once you have found all the files, look for backups of all the executable files (".php", ".aspx"...). Common variations for naming a backup are: file.ext~, #file.ext#, ~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old. You can also use the tool bfac or backup-gen.
 - Discover new parameters: You can use tools like Arjun, parameth, x8 and Param Miner to discover hidden parameters. If you can, you could try to search hidden parameters on each executable web file.
 - 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: Check the comments of all the files, you can find credentials or hidden functionality.
 - 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](https://github.com/taco-c/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
Aprenda e pratique Hacking AWS:
HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: 
HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Hacking Azure: 
HackTricks Training Azure Red Team Expert (AzRTE)
Supporte o HackTricks
- Confira os planos de assinatura!
 - Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-nos no Twitter 🐦 @hacktricks_live.
 - Compartilhe truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios do github.
 
HackTricks