80,443 - Pentesting Web Methodology
Last updated
Last updated
If you want to know about my latest modifications/additions or you have any suggestion for HackTricks or PEASS, join the , or follow me on Twitter **[🐦](@carlospolopm](). If you want to share some tricks with the community you can also submit pull requests to that will be reflected in this book. Don't forget to** give ⭐ on the github to motivate me to continue developing this book.
The web service is the most common and extensive service and a lot of different types of vulnerabilities exists.
Default port: 80 (HTTP), 443(HTTPS)
In this methodology we are going to suppose that you are going to a attack a domain (or subdomain) and only that. So, you should apply this methodology to each discovered domain, subdomain or IP with undetermined web server inside the scope.
Check if any WAF
Some tricks for finding vulnerabilities in different well known technologies being used:
If the source code of the application is available in github, apart of performing by your own a White box test of the application (no guide available yet in hacktricks) there is some information that could be useful for the current Black-Box testing:
Is there a Changelog or Readme or Version file or anything with version info accesible via web?
How and where are saved the credentials? Is there any (accesible?) file with credentials (usernames or passwords)?
Are passwords in plain text, encrypted or which hashing algorithm is used?
Is it using any master key for encrypting something? Which algorithm is used?
Can you access any of these files exploiting some vulnerability?
Is there any interesting information in the github (solved and not solved) issues? Or in commit history (maybe some password introduced inside an old commit)?
Take into account that the same domain can be using different technologies in different ports, folders and subdomains. If the web application is using any well known tech/platform listed before or any other, don't forget to search on the Internet new tricks (and let me know!).
You should look for these kind of vulnerabilities every time you find a path were a different technology is running. For example, if you find a java webapp and in /wordpress a wordpress is running.
If a CMS is used don't forget to run a scanner, maybe something juicy is found:
At this point you should already have some information of the web server being used by the client (if any data is given) and some tricks to keep in mind during the test. If you are lucky you have even found a CMS and run some scanner.
From this point we are going to start interacting with the web application.
/robots.txt
/sitemap.xml
Some 404 error - Some interesting data could be presented here.
If you find that WebDav is enabled but you don't have enough permissions for uploading files in the root folder try to:
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.
Information about SSL/TLS vulnerabilities:
Launch some kind of spider inside the web. The goal of the spider is to find as much paths as possible from the tested application. Therefore, web crawling and external sources should be used to find as much valid paths as possible.
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.
Recommended dictionaries:
/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.
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
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.
While performing the spidering and brute-forcing you could find interesting things that you have to notice.
Look for links to other files inside the CSS files.
If you find a .env information such as api keys, dbs passwords and other information can be found.
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.
Try using different verbs to access the file: GET, POST, INVENTED
If /path is blocked, try using /%2e/path (if the access is blocked by a proxy, this could bypass the protection). Try also /%252e/path (double URL encode)
Try Unicode bypass: /%ef%bc%8fpath (The URL encoded chars are like "/") so when encoded back it will be //path and maybe you will have already bypassed the /path name check
Change the protocol: from http to https, or for https to http
Other path bypasses:
site.com/secret –> HTTP 403 Forbidden
site.com/SECRET –> HTTP 200 OK
site.com/secret/ –> HTTP 200 OK
site.com/secret/. –> HTTP 200 OK
site.com//secret// –> HTTP 200 OK
site.com/./secret/.. –> HTTP 200 OK
site.com/secret.json –> HTTP 200 OK (ruby)
Other bypasses:
/v3/users_data/1234 --> 403 Forbidden
/v1/users_data/1234 --> 200 OK
{“id”:111} --> 401 Unauthriozied
{“id”:[111]} --> 200 OK
{“id”:111} --> 401 Unauthriozied
{“id”:{“id”:111}} --> 200 OK
{"user_id":"<legit_id>","user_id":"<victims_id>"} (JSON Parameter Pollution)
user_id=ATTACKER_ID&user_id=VICTIM_ID (Parameter Pollution)
X-Originating-IP: 127.0.0.1
X-Forwarded-For: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Remote-Addr: 127.0.0.1
X-ProxyUser-Ip: 127.0.0.1
X-Original-URL: 127.0.0.1
If the path is protected you can try to bypass the path protection using these other headers:
X-Original-URL: /admin/console
X-Rewrite-URL: /admin/console
Guess the password: Test the following common credentials. Do you know something about the victim? Or the CTF challenge name?
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**.
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".
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.
If you find a login page, here you can find some techniques to try to bypass it:
Check for comments inside the page (scroll down and to the right?)
Check if you can directly access the restricted pages
Check to not send the parameters (do not send any or only 1)
Check for default credentials
Check for common combinations (root, admin, password, name of the tech, default user with one of these passwords)
Check the PHP comparisons error: user[]=a&pwd=b , user=a&pwd[]=b , user[]=a&pwd[]=b
Create a dictionary using Cewl, add the default username and password (if there is) and try to brute-force it using all the words as usernames and password
You should also check for:
Check for this vulnerabilities:
Check if there are known vulnerabilities for the server version that is running. The HTTP headers and cookies of the response could be very useful to identify the technologies and/or version being used. Nmap scan can identify the server version, but it could also be useful the tools , or :
Search for
As commented the cookies can be very useful to identify the technology in used (if well known) but if the used cookies are custom, they could be vulnerable. So if you find a custom sensitive cookie you should . Also, the can also be interesting from a security point of view.
********
: , ColdFusion, WebLogic, , Railo, Axis2, Glassfish : , , Joomla, vBulletin websites for Security issues. (GUI) : Joomla, , , PrestaShop, Opencart CMSMap: , (J)oomla, or : , Joomla, , Silverstripe,
Use to checks for vulnerabilities (In Bug Bounty programs probably these kind of vulnerabilities won't be accepted) and use to recheck the vulnerabilities:
(go): HTML spider, LinkFinder in JS files and external sources (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com).
(go): HML spider, with LinkFider for JS files and Archive.org as external source.
(python): HTML spider, also indicates "juicy files".
(go): Interactive CLI HTML spider. It also searches in Archive.org
(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.
(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
go): HTML spider that uses external providers (wayback, otx, commoncrawl)
: This script will find URLs with parameter and will list them.
(go): HTML spider with JS rendering capabilities.
(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 **, which is a wrapper of LinkFinder.
(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 unmaintaned.
(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.
(python): It doesn't allow auto-signed certificates but allows recursive search.
(go): It allows auto-signed certificates, it doesn't have recursive search.
- Fast, supports recursive search.
wfuzz -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt https://domain.com/api/FUZZ
- Fast: ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ
(Very interesting)
included dictionary
: Find broken links inside HTMLs that may be prone to takeovers
Discover new parameters: You can use tools like and to discover hidden parameters. If you can, you could try to search hidden parameters on each executable web file.
API keys: If you find any API key there is guide that indicates how to use API keys of different platforms: , , , , .
Google API keys: If you find any API key looking like AIzaSyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik you can use the project **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, .
If you find API endpoints you . 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 .
You should also check discovered JS files with _**_to find if it's vulnerable.
Javascript Deobfuscator and Unpacker ()
Javascript Beautifier ()
BrainFuck deobfuscation (javascript with chars:"[]!+" )
In several occasions you will need to understand regular expressions used, this will be useful:
Try to stress the server sending common GET requests ().
Change Host header to some arbitrary value ()
Go to and check if in the past that file was worldwide accessible.
Fuzz the page: Try using HTTP Proxy Headers, HTTP Authentication Basic and NTLM brute-force (with a few combinations only) and other techniques. To do all of this I have created the tool .
: Try basic, digest and NTLM auth.
Test manually .
Try to brute-force using a bigger dictionary ()
Check for
More references for each Web Vulnerability: Another checklist: