WEB OFFENSIVE CHECKLIST

PRIMARY CATEGORY → CHECKLISTS   •   WEB PENTESTING

Mindmap

Web Application Pentesting Mindmap

Zoom in

---

Enumeration - Common Web App

e.g. WordPress, Tomcat, Jenkins, Joomla…

Check this out

---

Enumeration - Custom Web App

• Web Technologies

e.g. Server-Side Programming Language → Whatweb, Wappalyzer

• Extension Fuzzing

• Known Web Resources

e.g. Robots.txt, Sitemap…

• Web Crawling to list accesible web pages and HTLM juicy comments

• Accesible Web pages functionality while having Burpsuite open

i.e. While traffic passes through Burpsuite

• Non-hidden HTTP Parameters: Look for any type of injection

We must look for any resource that accepts user input and subsequently send it to the server

e.g.

GET/POST Parameters in a Login/Registration Form → SQLi

GET/POST Parameters in Contact Form | Comments | Support Tickets → XSS

GET/POST Parameters exposed in the Source Code of each Web Application Page

A web page with GET Parameters such as File, Page and so on → LFI or RFI

A web application where a logged-in user can update its profile picture by uploading a file → File Upload

• Custom HTTP Response Headers and Cookies

• Fuzz for Resources: Directories and Files

Based on the Server-Side Programming Language used i.e. <URL>/<RESOURCE>.php

Juicy Extensions → txt,xml,zip,bk,bak,gz and so on

• Valid domain→ Fuzz for Virtual Hosts and Subdomains

• Fuzz for HTTP Hidden Parameters

Be careful with 301 status code, always follow redirects, then filter out ( e.g. ffuf ...<SNIP>... -r )

• After finding a new VHOST, fuzz it again as a new base domain

e.g. domain.tld → web1337.domain.tld → dev.web1337.domain.tld

• DNS Server available ( i.e. 53 TCP Port open ) → DNS Zone Transfer

• Public/Registered Domain → OSINT ( e.g. CT )

XSS

• Web Page with a Contact Form → Check for XSS

• Web Page with a Comment Section → Check for XSS

• Support Web Page with a Ticket creation Feature → Check for XSS

SQLi

• Login/Registration Panel → Check for Authentication Bypass via SQLi

• Any POST or GET Parameter. Any Cookie and User-Agent value as well

LFI

• Any POST or GET parameter ( Check LFI Known Parameters )

e.g. <URL>?page=<VALUE> or <URL>?language=<VALUE>

• Look for Hidden Parameters through Fuzzing on each Web Application resource

File Upload

• Look for any File Upload feature within the given web application

• If the website has a login feature and we are logged in, check for File Upload as well

Command Injection

• Any POST or GET Parameter

HTTP Verb Tampering

• Try the same request with a different HTTP method (e.g. GET ↔ POST, POST ↔ PUT, GET ↔ HEAD )

IDOR

• Look for any direct object reference in the web application to test for its system access control

XXE

• Search for any HTTP request which sends an XML data structure on its body

• A File Upload feature that allows [[FILE UPLOAD - LIMITED FILE UPLOADS#XXE#SVG|SVG]] images

---

Exploitation - Common Web App

See Common Applications Checklist

---

Exploitation - Custom Web App

When testing any input data through a certain HTTP Parameter looking for a possible injection, remember to try all available HTTP verbs ( HTTP Verb Tampering )

e.g.

Abusing Insecure Function Calls through an IDOR and HTTP Verb Tampering

User Reset Password Feature →

• POST

Access Denied

Zoom in

• GET

“Password changed successfuly”

Zoom in

SQLi

• SQLi Type Identification

Always check first IN-BAND SQLi ( e.g. UNION or Error-based ), then Blind

• DBMS Identification

Data Exfiltration

• Enumeration: Databases, Tables, Columns, Fields

• Check if the current DB user has Read/Write permissions: FILE Privilege and secure_file_priv empty or set to an interesting path

If READ permissions → Look for interesting files

Read files

• Web Application Source Code Script ( e.g. PHP Scripts )

So we can look for any existing security flaw by analyzing the code

• Web Server Configuration Files ( i.e. Apache, Nginx, Tomcat… )

• Virtual Hosts Configuration Files ( e.g. Web Root Path, .HTPasswd files or another type of sensitive files )

• Configuration files within the Web Root ( e.g. config.php, db_conn.php… )

• Service Configuration files that are externally accesible such as FTP, SSH, RSYNC, CIFS, SQUID, SNMP and so on

• Home Directory Files such as SSH Keys, Shell History Files…

If WRITE Permissions →

Write files

• Web Shell Deployment on Web Root or any directory on which the system user running the DBMS has write permissions

XSS

• Web Defacement

• Session Hijacking

Try with different payloads

• Phishing via Login Form Injection

LFI

Bypasses

Try different Bypasses

Important

There are situations where the webapp does not return the expected output from the browser

Zoom in

Therefore, we could try to carry out the same actions using curl

curl --silent --location --request GET '<URL>?p=....//....//....//....//....//....//....//....//etc/passwd'

Zoom in

• Non-Recursive Path Traversal Filter

Try all of them

• Encoding

Simple and Double

• Approved Path

To find the Approved Path → Examine requests sent by existing forms or fuzz for existing web directories under the same path until we get a match ( e.g. <URL>?lang=./<DIR>/../../../etc/passwd )

Once we are able to exploit the LFI to point to other web files →

Sensitive Data Exposure

See Reading files via SQLi

We may deal with a VHOST whose config. file has a randon name, so we cannot list its content to disclose the webroot path → Disclose the latter through fuzzing

It also applies to Log Files

Source code Disclosure

Check LFI PHP Filters if include() or require() is used

• Look for any security flaw or information present in the rest of the web application scripts

e.g. Check a File Upload Validation Filters to try to bypass them or the context of an SQL Query looking for an SQLi

RCE

• PHP Wrappers

data:// | input:// | expect:// )

• File Upload

• RFI

• Log Poisoning

Non-standard location → Server Logs Fuzzing

• PHP Session Poisoning

File Upload

• File Upload Feature allows SVG → SVG file is displayed on the Web Application → [[FILE UPLOAD - LIMITED FILE UPLOADS#XXE#SVG|External Entity Definition within the SVG]] ( XXE ) → Source Code Disclosure of any existing script within the webapp

Then, we can disclose the uploads directory and all validation filters by reviewing the Upload Feature’s source code

• If the Web Application runs X (e.g. PHP), try uploading an X script (e.g. test.php)

If the given upload is not allowed, security filters may have been set up. If so →

Bypasses

• Client-Side Validation Bypass

• Blacklist Bypass

• Whitelist Bypass

• Content-Type Bypass

• MIME Type Bypass

If none of the previous bypasses work →

Alternative Methods

• Fuzz for allowed extensions (e.g. SVG)

• Check Limited File Uploads

• LFI ↔ File Upload Chain → Fuzz for allowed Extensions → Add a Code Snippet (e.g. mini WebShell) within the file ( e.g. Image Metadata ) before uploading it

Check this out

Once a malicious file is uploaded, we must know the path where it is stored in order to request it, and thereby gain RCE

Disclosing the Uploads Directory Path

• Image path referenced in the source code

e.g. <img src=http://<TARGET>/uploads/<IMAGE>

• Fuzzing

• Upload Feature’s Source Code Disclosure through other security flaws

e.g. LFI, XXE ( e.g. [[FILE UPLOAD - LIMITED FILE UPLOADS#XSS#SVG|SVG Upload with an External Entity]] ) or SQLi ( Read Files )

Command Injection

• Try a basic command injection to see if there is any input validation or sanitizacion in place

if not, reverse shell and pwned. If so →

• Try to bypass them with different filter evasions and command obfuscation

HTTP Verb Tampering

• Send an OPTIONS HTTP request to know the supported HTTP methods by the web server

• In case of any error or unauthorized operation, simply try changing the HTTP request method to look for differences in the HTTP response

IDOR

This attack vector results from a bad access control system or its absence and a direct object reference

Simple Direct Object Reference (e.g. <URL>?id=1 )

• Just try changing its value to something else to test the access control system

More Secure Direct Object Reference (e.g. <URL>?id=6B29FC40-CA47-1067-B31D-00DD010662DA or <URL>?id=098f6bcd4621d373cade4e832627b4f6 )

• Check if the reference is being created in the frontend ( e.g. JS Function ) before being sent to the server

i.e. Function Disclosure

Once we discover the IDOR →

• Mass Enumeration

• Insecure Function Calls

XXE

Once we have located an HTTP request that sends XML data within its body

Data Disclosure

See Reading files via SQLi

• Simple XXE

• If the web application runs PHP, try XXE using PHP Filter Wrapper

• If not, try XXE using CDATA

• If our input is not reflected anywhere in the HTTP response, check if the web application handles error properly

• If not, try Error based XXE

• If we are dealing with a Blind XXE, see Blind OOB XXE

RCE

• Bear in mind that we can achieve RCE as well