The web service is the most extensive service to pentest due to the big amount of vulnerabilities that can exist on it.
nc -v domain.com 80 # GET / HTTP/1.0openssl s_client -connect domain.com:443 # GET / HTTP/1.0
Check if there are known vulnerabilities for the server version that is running (you should have done this before, but do it now if you haven't).
To know the server version the headers of the HTTP responses should be very useful. The nmap scan use to tell you the server version, but it could also be useful the tool whatweb:
whatweb -a 1 <URL> #Stealthywhatweb -a 3 <URL> #Aggresive
Check also all the headers of the server, maybe you can find some vulnerability related to an Apache module being used. You should also check which technologies are being used by identifying headers and cookies: https://github.com/ShielderSec/webtech
Common misconfigurations in servers technologies:
In any case it is recommended to do several things:
nikto -h <URL>whatweb -a 4 <URL>
Generic files/directories vulnerabilities:
Dirb / Dirbuster - Included in Kali, a little bit old (and slow) but functional. Allow autosigned certificates and recursive search.
Gobuster - Faster, go needed, allow autosigned certificates, it doesn't have recursive search.
Dirsearch - Faster, it doesn't allow autosigned certificates but allows recursive search.
Recommended dictionaries (ordered by size):
Dirsearch included dictionary
Search for backups of every discovered files inside the server: file.ext~, #file.ext#, ~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old
Is the web page using external buckets? Check AWS-S3
I recommend testssl.sh it checks for vulnerabilities and the output is more clear:
./testssl.sh [--htmlfile] --openssl-timeout 5 22.214.171.124:443#Use the --htmlfile to save the output inside an htmlfile also
sslscan <host:port>sslyze --regular <ip:port>
Information about SSL/TLS vulnerabilities:
wfuzz -c -w /usr/share/wordlists/SecLists/Discovery/DNS/subdomains-top1million-20000.txt --hc 400,404,403 -H "Host: FUZZ.example.com" -uhttp://example.com -t 100#From https://github.com/allyshka/vhostbrutevhostbrute.py --url="example.com" --remoteip="10.1.1.15" --base="www.example.com" --vhosts="vhosts_full.list"
A guide that indicates how to use API keys of different platforms: https://github.com/streaak/keyhacks
If the main page ("/", "index.html", "index.php", "index,asp", "index.aspx"...) is completely useless (Empty, Default, useless information or HTTP Auth required), you could try to search for hidden information/auth bypass.
At this point you should be already searching for hidden files and directories, so lets try to find more hidden information.
Maybe you can impersonate users if the cookie present some kind of vulnerability (base64, hashing, encrypted with guessable/bruteforce master password, JWT vulnerable, crytplogical flaws...).
You could find:
Interesting information (like passwords)
Exploitable api web requets
Bypassing checks or functions
In a browser a redirection is almost invisible but with Burp or Zap you can see the content of the redirection, maybe there is some interesting information in there (yes, a redirect could contains more content apart from the redirection info itself).
If the page is the Default one probably it isn't hiding anything inside that page, but you never know...
The first thing you should do is read the source HTML code (CTRL+U), check if the page is completely useless or empty. Sometimes you can find "hidden" information:
Look at the bottom of the page: This kind of pages usually contains a lot of new lines so you don't see the information immediately.
Look at the right of the page: This kind of pages usually contains a lot of spaces so you don't see the information immediately.
Read the comments: Maybe some password is hidden in there (the nmap http-comments-displayer script could be useful). Notice that HTML comments could be closed with --> or --!> .
Test hidden parameters: I would suggest to use the tool: Arjun
arjun -u <URL> --getarjun -u <URL> --post
In this case you need to try to bypass it:
Guess the password: Test manually very common passwords.Do you know something about the victim? Or the CTF challenge name?
Fuzz the page: Try other HTTP Verbs, HTTP Proxy Headers or HTTP Authentication Basic and NTLM bruteforce (with a few combinations only). To do all of this I have created the tool fuzzhttpbypass.
Try using different verbs
If /path is blocked, try using /%2e/path
admin adminadmin passwordadmin 1234admin admin1234admin 123456root toortest testguest guest
If you find a known web application, for example a CMS like Wordpress or Drupal or other less known. Or any opensource web application, there are several things that you should test:
Clusterd: JBoss, ColdFusion, WebLogic, Tomcat, Railo, Axis2, Glassfish CMSScan: WordPress, Drupal, Joomla, vBulletin websites for Security issues. (GUI) VulnX: Joomla, Wordpress, Drupal, PrestaShop, Opencart CMSMap: (W)ordpress, (J)oomla, (D)rupal or (M)oodle
cmsmap [-f W] -F -d <URL>wpscan --force update -e --url <URL>joomscan --ec -u <URL>joomlavs.rb #https://github.com/rastating/joomlavs
There you can see how the web applications works:
Is there a Changelog or Readme or Version file or anything with version info accesible via web?
How and where is saved the credentials? Is there any 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)?
Now we will discuss several vulnerabilities to test when you are able to send information to the server.
To automate the testing of some functions of the server that allows user input it could be needed to bypass a captcha implementation. Test these things:
Do not send the parameter related to the captcha
Check if the value of the captcha is in the source code
Check if the value is inside the cookie
Check if you can send the correct value one time and use this value with the same sessionID
Check manually or with a command how many images are being used and if only a few images are being used, detect them by MD5
Use an OCR (https://github.com/tesseract-ocr/tesseract)
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)
Test manually very common passwords.
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 bruteforce it using all the words as usernames and password
Try to bruteforce using a bigger dictionary
You should also check for:
Check if you can attack the "new" cookie of the authenticated user.
Check "remember me" option if it exists and check how does it works. If it exists and could be vulnerable, always use the cookie of remember me without any other cookie.
Check for SQL INSET INTO Injections.
Check for this vulnerabilities:
If you can upload a XML that is going to be processed:
If you can upload a .zip file that is going to be decompressed:
Try also to upload an executable (.exe) or a .html (less suspicious) that will execute code when opened by victim.
List of API endpoints to check for.
More references for each Web Vulnerability: https://cyberzombie.in/bug-bounty-methodology-techniques-tools-procedures/