Skip to content

Latest commit

 

History

History
27 lines (21 loc) · 3.42 KB

web-pentesting-methodology.md

File metadata and controls

27 lines (21 loc) · 3.42 KB
## SecurityExplained S-1:
### My Penetration Testing Methodology [Web]

The below threat contain an overview of my penetration testing methodology on the web application targets:

1. Initially, before starting with the engagement, I start with *Scoping*, where I go through the details shared by the client to understand the scope and see if the testing is feasible as per the given timeline. During this phase, I check if the application is accessible and credentials (if required) are working correctly. If anything from **Step-1** is blocking, I reach out to the concerned person and request unblocking the blocker items.
2. Next, I start browsing the application while letting the traffic flow through Burp Suite to populate the *Targe* menu. The main idea is to understand core business logic, map out interesting functionalities and build an overall attack surface. I also take notes if required.
3. In parallel to **Step-2**, I run *Recon* activities depending on the scope size. However, some bare minimums are to run *Port Scan*, *Directory Fuzzing*, *Historical URL Scan*, *Nuclei/Template Based Fuzzing*, *GitHub Scanning*, and some other tools as required. I also perform quick OSINT to check for the information & data leakage related to my target.
4. Further, I start preparing a threat map containing hypothetical test cases of "What an attacker can do to exploit this application?". For example, if an application has three user roles, I would check for the privilege escalation on "Three Different Levels"(Vertical) as well as privilege escalation on "Same Level" (Horizontal).
5. Lastly and most importantly, I start the manual penetration testing on the application. I include the test cases derived from **Step-4** in my manual testing. Now, breaking down the manual penetration testing approach a bit further:
	+ I mainly rely upon *Burp Suite*, *Developer Tools* and *Skills* during the manual assessment.
	+ I use the *Advance Scope* option in the Burp Suite to remove unnecessary noise and help be in the correct scope while running *Active/Passive* Scanner or Scans originating from *Burp Extensions*.
	+ I use [Autorize](https://portswigger.net/bappstore/f9bbac8c4acf4aefa4d7dc92a991af2f) to perform checks related to *Privilege Escalation* & *IDOR*.
	+ I check most of the *GET* endpoints that return data using an unauthenticated user to check for Lack of Authorization Checks.
	+ I use *Burp Match & Replace* to check for injection attacks. I define specific stings which are further replaced to the Payloads by Burp Proxy's Match & Replace rules. It makes overall testing relatively easy.
	+ I spend more time on functionalities such as *File Upload* because such functionalities themselves have a huge attack surface.
	+ Similarly, I use *Burp Extensions* as per the application. So, for example, If the application uses *SSO*, then only I enable the extensions related to *SSO*, such as *SAML Raider*, and others.
	+ I keep logs of the testing using [Logger++](https://portswigger.net/bappstore/470b7057b86f41c396a97903377f3d81). Taking logs helps a lot.

I use this basic testing methodology while testing a web application. However, I will attempt to cover a lot more in the *Manual Testing* shortly through some Blogs.

Feel free to ask if you have any questions on "How do I Test specific things", etc. on my Twitter handle @harshbothra_

Follow Twitter Thread