Local Testing

Overview

With prioritized shortlist of potentially vulnerable functions, confirm or deny vulnerabilities through testing and local debugging.

Approach: Similar to developer debugging - vulnerabilities are essentially 'issues' in code.

---

Local Testing Phases

Backend Replication
        ↓
     Testing
        ↓
   Exploitation

---

Phase 1: Backend Replication

Goal

Set up test server that closely resembles production backend.

Scenarios

Scenario	Action
Team provides replica server	Skip to testing
No server provided	Set up own test server

Difficulty Factors

Factor	Easier	Harder
Requirements doc	Available	Not documented
Dependencies	Listed (package.json)	Must identify manually
External connections	Documented	Need to discover
Database schema	Provided	Must reverse engineer

Example: Node.js Application

# If package.json exists - easy
npm install
npm start

# If not - must analyze imports manually
grep -rn "require\|import" . | grep -v node_modules

External Connections

Consider:

• Database connections

• API endpoints

• Authentication services

• File storage

• Cache servers

Note: Cost increases with poor documentation - more time to replicate.

---

Phase 2: Testing

Goals

Goal	Description
Trigger target function	Find how to reach the vulnerable code
Control input	Understand how input reaches/affects function

Triggering the Function

Function may not be directly accessible:

• Only triggered under certain conditions

• Requires specific user role

• Needs specific application state

Process:

1. Identify entry points

2. Map request flow to target function

3. Test different conditions

4. Debug to understand triggers

Tracing Input

Frontend Input
     ↓
   Request
     ↓
Controller/Handler
     ↓
Processing Layer
     ↓
 Target Function

At each stage, monitor:

• How input changes

• What filtering/validation occurs

• What transformations apply

Testing Techniques

Technique	Purpose
Breakpoints	Pause execution at key points
Logging	Track variable values
Request modification	Test different inputs
Step-through debugging	Follow execution path

Debugging Tools by Platform

Platform	Tools
PHP	Xdebug, var_dump()
Python	pdb, print(), PyCharm debugger
Node.js	node --inspect, console.log()
Java	IDE debugger, System.out.println()
.NET	Visual Studio debugger

---

Phase 3: Exploitation

Goal

Achieve basic exploitation to confirm vulnerability exists.

NOT Required at This Stage

• Fully operational exploit

• Bypassing WAF/filters

• Overcoming blind exploitation challenges

• Production-ready script

Required at This Stage

• Basic confirmation function is vulnerable

• Proof it can be exploited

Safe Confirmation Payloads

Vulnerability	Safe Test
Command Injection	touch /tmp/test or ping -c 1 localhost
SQL Injection	Execute query, check logs
XSS	Simple alert(1)
File Read	Read known file
SSRF	Request to internal endpoint

Example: Command Injection Test

# Input
; ping -c 1 127.0.0.1

# Check
tcpdump -i lo icmp
# or
tail -f /var/log/apache2/access.log

Example: SQL Injection Test

# Input
' OR '1'='1

# Check database logs
tail -f /var/log/mysql/query.log

Why Basic Exploitation First?

❌ Without basic confirmation:
   Hours bypassing filters → Realize function not vulnerable
   
✅ With basic confirmation:
   Confirm vulnerability → Then invest time in bypasses

---

Decision Point

After Testing

Result	Next Step
Confirmed exploitable	Move to PoC phase
Not exploitable	Reassess priority, move to next target
Uncertain	More testing/analysis needed

Reducing Priority

If confirmed vulnerable but not exploitable:

• Reduces probability of damage

• Reduces overall risk rating

• May still report as finding

---

Local Testing Checklist

Environment Setup

• Test server running

• Matches production config

• Database populated with test data

• Debugging tools installed

• Logging enabled

Testing

• Can trigger target function

• Understand input flow

• Input tracing documented

• Conditions for vulnerability identified

Exploitation

• Basic exploit successful

• Confirmed in logs/output

• Documented exploitation steps

• Ready for PoC phase

---

Tips

1. Document everything - You'll need it for PoC and reporting

2. Use test data - Never test with real/sensitive data

3. Enable verbose logging - Makes tracing easier

4. Compare with production - Ensure test matches reality

5. Don't skip to exploitation - Understanding comes first