Field Manual

Web Proxies Request Manipulation

4 min read

🛡️ Methodology Checklist

  • Configure browser to proxy through Burp (127.0.0.1:8080)
  • Intercept baseline requests for each function
  • Modify HTTP method (GET→POST, POST→PUT) for verb tampering
  • Alter parameter values for IDOR and injection testing
  • Test headers: X-Forwarded-For, X-Original-URL, Content-Type
  • Replay and compare responses for state differences
  • Use Repeater for manual parameter testing
  • Use Intruder for automated fuzzing of identified parameters

🎯 Operational Context

Use when: Any web application testing — intercept, modify, and replay HTTP requests to test auth bypasses, injection points, and parameter manipulation. Think Dumber First: Always start Burp proxy before any web testing. Every request that goes through the browser gets captured. Replay with Repeater before writing any exploit code. Check for hidden parameters in JS source before fuzzing. Skip when: HTTPS with cert pinning — bypass required first.

⚡ Tactical Cheatsheet

CommandTactical Outcome
set PROXIES HTTP:127.0.0.1:8080Route Metasploit module traffic through Burp/ZAP
set RHOSTS [TARGET_IP]Set target host in MSF
set RPORT [PORT]Set target port in MSF
ip=127.0.0.1;ls;cat flag.txtCommand injection payload via intercepted POST

🔬 Deep Dive & Workflow

Core Concept

Web proxies (Burp Suite, OWASP ZAP) act as a man-in-the-middle between your browser/tools and the target server, allowing inspection and modification of requests and responses in transit.

Key capabilities:

  • Client-Side Bypasses: Interact with disabled UI elements (greyed-out buttons) by modifying HTML responses before they reach the browser.
  • Repeater: Manual trial-and-error testing (e.g., testing command injection payloads).
  • Intruder/Fuzzer: Automated brute-forcing of parameters, directories, or encoded cookies.
  • External Tool Proxying: Capture Metasploit, Nmap, or curl traffic to inspect raw requests.

Scenario 1: Command Injection via Interception

  1. Intercept a standard application request (e.g., a diagnostic ping tool).
  2. Send to Repeater.
  3. Modify POST data with command terminators: 
    ip=127.0.0.1;ls;cat flag.txt
  4. Analyze response body for command output.

Scenario 2: Proxying Metasploit Traffic

  1. Load module in MSFConsole.
  2. Set RHOSTS, RPORT.
  3. Set PROXIES HTTP:127.0.0.1:8080.
  4. Run exploit — view raw requests in HTTP History.

Scenario 3: Fuzzing Encoded Cookies

  1. Capture session cookie.
  2. Decode (Decoder tab): ASCII Hex → Base64 → MD5 hash.
  3. Send to Intruder, highlight cookie value as payload position.
  4. Load wordlist; configure Payload Processing to reverse-engineer encoding:
    • Add Prefix → Encode Base64 → Encode ASCII Hex.
  5. Uncheck URL-encode if payload requires raw Hex/Base64. Sort by response length.

Critical Exam Checks

  • Proxy not capturing? Verify listener is on 127.0.0.1:8080 and browser/tool points to it.
  • Auto URL-encoding breaking payloads? Uncheck URL-encode in Intruder’s payload tab.
  • Response modification (disabled buttons)? Must use Intercept → “Do Intercept → Response to this request” — cannot edit in HTTP History.
  • Session suddenly changing during fuzzing? Baseline response size shift = authentication change or lockout. Inspect the anomaly raw response immediately.

🛠️ Troubleshooting & Edge Cases

ProblemCauseFix
Burp proxy not intercepting HTTPSCA cert not installed in browserExport Burp CA cert from Proxy > Options; install in browser trust store
Target app rejects Burp CA certCertificate pinningUse Frida/objection for mobile apps; for web apps use --ignore-certificate-errors in Chrome
ZAP active scan triggers WAF lockoutScan too aggressiveUse ZAP in passive mode only; reduce scan strength to Low in Active Scan Policy
Repeater request always returns 403CSRF token requiredCapture fresh token from browser intercept; use Burp Macro to auto-refresh tokens
WebSocket traffic not visible in BurpWS upgrade not proxiedEnable WebSocket interception in Proxy > Options > Intercept WebSocket Messages

đź“ť Reporting Trigger

Finding Title: HTTP Request Manipulation Bypasses Application Security Controls Impact: Ability to modify HTTP request parameters, headers, and body content enables authentication bypass, privilege escalation, IDOR exploitation, and injection attack delivery through the application’s own input processing. Root Cause: Application trusts client-supplied HTTP parameters without server-side validation. Business logic implemented solely in client-side code. Recommendation: Implement server-side input validation for all parameters. Use CSRF tokens with short expiration. Apply parameter integrity signing for sensitive operations. Regular manual penetration testing of web application logic.

đź”— Related Nodes

Graph View