Physical attacks
Mobile Apps Pentesting

80,443 - Pentesting Web Methodology

The web service is the most extensive service to pentest due to the big amount of vulnerabilities that can exist on it.

nc -v 80 # GET / HTTP/1.0
openssl s_client -connect # GET / HTTP/1.0

1- Server Version Exploits and vulnerabilities

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> #Stealthy
whatweb -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:

Common misconfigurations in servers technologies:

2- Main Page

2.1 Generic Actions

In any case it is recommended to do several things:

2.1.1 Check for pages robots.txt, sitemap.xml and some 404 error.

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

nikto -h <URL>
whatweb -a 4 <URL>

Generic files/directories vulnerabilities:

2.1.4 Brute force files or directories. Several tools could be used:

  • 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

  • /usr/share/wordlists/dirb/big.txt

  • /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

If you find a .git file some information can be extracted

2.1.5 Spider the web. A nice tool to do this is dirhunt:

dirhunt <URL>

2.1.6 Search for backups

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

2.1.7 Search for buckets

Is the web page using external buckets? Check AWS-S3

2.1.8 If the page is using HTTPS you should check for TLS vulnerabilities:

I recommend it checks for vulnerabilities and the output is more clear:

./ [--htmlfile] --openssl-timeout 5
#Use the --htmlfile to save the output inside an htmlfile also

Other tools:

sslscan <host:port>
sslyze --regular <ip:port>

Information about SSL/TLS vulnerabilities:

2.1.9 Bruteforce vhosts

wfuzz -c -w /usr/share/wordlists/SecLists/Discovery/DNS/subdomains-
top1million-20000.txt --hc 400,404,403 -H "Host:" -u -t 100
#From --url="" --remoteip="" --base="" --vhosts="vhosts_full.list"

2.2.10 Look for subdomains

2.1.11 Check for subdomain Take Over (How to take over using different platforms)

2.1.12 Look for API keys and see what can you do with them

A guide that indicates how to use API keys of different platforms:

2.2- Redirection, Empty, Default, Useless web page, HTTP Auth required or propietary web application

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.

2.2.1 Generic test for these cases

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...).

  • Check Javascript Code

You could find:

  • Interesting information (like passwords)

  • Exploitable api web requets

  • Bypassing checks or functions

If the javascript code is obfuscated, probably it is interesting: BrainFuck deobfuscation (javascript with chars:"[]!+", Javascript Beautifier (, Javascript Deobfuscator and Unpacker (

2.2.2 Redirection

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).

2.2.3 Empty, Default or apparently useless

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 --!> .

  • Follow the links to other pages: In the source code maybe you can find javascript or css pages being loaded and inside those pages you could find other links...

  • Test hidden parameters: I would suggest to use the tool: Arjun

arjun -u <URL> --get
arjun -u <URL> --post

2.2.4 Authentication Required

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.

2.2.5 403 Forbidden

  • Try using different verbs

  • If /path is blocked, try using /%2e/path

2.2.6 List of common password to test manually

admin admin
admin password
admin 1234
admin admin1234
admin 123456
root toor
test test
guest guest

2.3 Known web application

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:

2.3.1 Search for scanners of that web application:

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 #

2.3.4 Webapp pentesting tricks:

2.3.3 Search for tutorials of how to pentest that web application in internet.

2.3.4 Look the source code (Github).

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)?

3- User input/Common web vulnerabilities

Now we will discuss several vulnerabilities to test when you are able to send information to the server.

3.1 Captcha Bypass

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

3.2 Bypass regular login (POST or GET method)

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

Brute force

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.

3.3 Inset into/Create Object

Check for SQL INSET INTO Injections.

3.4 Upload Files

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.

3.5 JWT vulnerabilities

Check JWT tricks

3.6 API vulnerabilities

List of API endpoints to check for.

4- User input Web Vulnerabilities list

More references for each Web Vulnerability: