How Proxies Work for Pentesters

TL;DR: Proxies are intermediaries between clients and servers. Forward proxies act on behalf of clients, reverse proxies protect servers. Understanding proxy mechanics is essential for web application testing with tools like Burp Suite.

Table of Contents

Quick Reference

Proxy Types

Common Proxy Ports

Proxy Headers

Why Proxies Matter

For Pentesters

For Attackers

For Defenders

Types of Proxies

Visual Overview

Forward Proxy (Client-side):
┌────────┐      ┌─────────┐      ┌────────┐
│ Client │─────►│  Proxy  │─────►│ Server │
│        │      │         │      │        │
│ Knows  │      │ Knows   │      │ Sees   │
│ proxy  │      │ both    │      │ proxy  │
└────────┘      └─────────┘      └────────┘
Client configures proxy, server sees proxy IP.

Reverse Proxy (Server-side):
┌────────┐      ┌─────────┐      ┌─────────┐
│ Client │─────►│ Reverse │─────►│ Backend │
│        │      │  Proxy  │      │ Server  │
│ Thinks │      │         │      │         │
│ proxy  │      │         │      │ Hidden  │
│ is     │      │         │      │ from    │
│ server │      │         │      │ client  │
└────────┘      └─────────┘      └─────────┘
Client thinks proxy IS the server.

Transparent Proxy:
┌────────┐      ┌─────────┐      ┌────────┐
│ Client │─────►│ Proxy   │─────►│ Server │
│        │      │(invisible)     │        │
│ Doesn't│      │         │      │        │
│ know   │      │ Network │      │        │
│ proxy  │      │ level   │      │        │
│ exists │      │ redirect│      │        │
└────────┘      └─────────┘      └────────┘
Client is unaware of proxy.

Forward Proxies

TL;DR: Forward proxies act on behalf of clients. The client explicitly configures the proxy.

How Forward Proxy Works

1. Client configures proxy (e.g., 192.168.1.10:8080)
2. Browser sends ALL requests to proxy
3. Proxy forwards requests to destination
4. Proxy receives response
5. Proxy forwards response to client

Request to proxy:
GET http://example.com/page HTTP/1.1
Host: example.com
Proxy-Connection: keep-alive

Note: Full URL in request line (http://example.com/page)
      vs normal request: GET /page HTTP/1.1

Forward Proxy Request vs Direct Request

Direct Request:
┌─────────────────────────────────────┐
│ GET /page HTTP/1.1                  │
│ Host: example.com                   │
│ Connection: keep-alive              │
└─────────────────────────────────────┘

Proxy Request:
┌─────────────────────────────────────┐
│ GET http://example.com/page HTTP/1.1│  ← Full URL
│ Host: example.com                   │
│ Proxy-Connection: keep-alive        │  ← Proxy-specific
└─────────────────────────────────────┘

Common Forward Proxies

Configuring Forward Proxy

# === System-wide (Linux) ===
export http_proxy="http://192.168.1.10:8080"
export https_proxy="http://192.168.1.10:8080"
export no_proxy="localhost,127.0.0.1"

# === curl ===
curl -x http://192.168.1.10:8080 http://example.com
curl --proxy http://192.168.1.10:8080 http://example.com

# === wget ===
wget -e use_proxy=yes -e http_proxy=192.168.1.10:8080 http://example.com

# === Python requests ===
import requests
proxies = {
    'http': 'http://192.168.1.10:8080',
    'https': 'http://192.168.1.10:8080'
}
response = requests.get('http://example.com', proxies=proxies)

# === Firefox/Chrome ===
# Settings → Network → Proxy → Manual configuration
# Or use FoxyProxy extension

# === Burp Suite browser ===
# Pre-configured browser with proxy

Reverse Proxies

TL;DR: Reverse proxies sit in front of servers, handling requests on their behalf. Clients don’t know they’re talking to a proxy.

How Reverse Proxy Works

1. Client connects to proxy (thinking it's the server)
2. Proxy receives request
3. Proxy decides which backend to forward to
4. Backend processes request
5. Backend responds to proxy
6. Proxy forwards response to client

Client → example.com → (actually reverse proxy)
                           │
                           ├──► backend1.internal
                           ├──► backend2.internal
                           └──► backend3.internal

Reverse Proxy Functions

Common Reverse Proxies

Identifying Reverse Proxies

# Check response headers
curl -I https://target.com | grep -i "server\|x-\|via"

# Common indicators:
# Server: nginx
# Server: cloudflare
# X-Cache: HIT
# X-Served-By: cache-server
# Via: 1.1 varnish
# CF-RAY: ... (Cloudflare)

# Check for proxy-specific behavior
# Different response times
# Different error pages
# Header inconsistencies

# Timing analysis
curl -w "@curl-format.txt" -o /dev/null -s https://target.com

# curl-format.txt:
#     time_namelookup:  %{time_namelookup}\n
#     time_connect:  %{time_connect}\n
#     time_appconnect:  %{time_appconnect}\n
#     time_redirect:  %{time_redirect}\n
#     time_pretransfer:  %{time_pretransfer}\n
#     time_starttransfer:  %{time_starttransfer}\n
#     time_total:  %{time_total}\n

Pentester Considerations

Transparent Proxies

TL;DR: Transparent proxies intercept traffic without client configuration. Often used by ISPs and corporate networks.

How Transparent Proxy Works

Network-Level Interception:

┌────────┐                     ┌─────────────┐       ┌────────┐
│ Client │───►  Traffic ───►   │ Transparent │  ───► │ Server │
│        │      redirected     │    Proxy    │       │        │
│ No     │      at router/     │             │       │        │
│ config │      firewall       │ iptables    │       │        │
│ needed │      level          │ REDIRECT    │       │        │
└────────┘                     └─────────────┘       └────────┘

Redirection methods:
- iptables REDIRECT
- WCCP (Cisco)
- Policy-based routing

iptables Transparent Proxy

# Redirect all HTTP traffic to local proxy (port 3128)
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 \
    -j REDIRECT --to-port 3128

# For HTTPS (requires SSL inspection)
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 \
    -j REDIRECT --to-port 3129

Detecting Transparent Proxies

# Compare traceroute with and without proxy
traceroute example.com

# Check for unexpected hops
# Check response headers for proxy indicators
# Compare from different network locations

# Test with curl
curl -v http://httpbin.org/ip
# If IP doesn't match your public IP, proxy exists

HTTP CONNECT Method

TL;DR: CONNECT creates a TCP tunnel through an HTTP proxy, used for HTTPS and other protocols.

How CONNECT Works

For HTTPS through forward proxy:

1. Client → Proxy: CONNECT example.com:443 HTTP/1.1

2. Proxy → example.com:443: [TCP connection established]

3. Proxy → Client: HTTP/1.1 200 Connection Established

4. Client ←───── TLS tunnel ─────→ Server
   (Proxy just passes encrypted bytes, can't read them)

┌────────┐          ┌─────────┐          ┌────────┐
│ Client │──CONNECT─►│  Proxy  │──TCP────►│ Server │
│        │          │         │          │ :443   │
│        │◄──200────│         │◄─────────│        │
│        │          │         │          │        │
│        │◄═══════════TLS═══════════════►│        │
│        │  (Proxy can't read TLS)       │        │
└────────┘          └─────────┘          └────────┘

CONNECT Request/Response

CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com:443
Proxy-Authorization: Basic dXNlcjpwYXNz

HTTP/1.1 200 Connection Established

[TLS handshake begins]

Security Implications

HTTPS Interception

TL;DR: To intercept HTTPS, proxies perform MITM by presenting their own certificate. Clients must trust the proxy’s CA.

How HTTPS Interception Works

Without interception (normal HTTPS):
Client ◄══════════════════TLS═══════════════════► Server
(Proxy can only see encrypted blobs)

With interception (Burp, mitmproxy):

┌────────┐           ┌─────────┐           ┌────────┐
│ Client │◄══TLS 1══►│  Proxy  │◄══TLS 2══►│ Server │
│        │           │         │           │        │
│ Trusts │           │ Has CA  │           │        │
│ Proxy  │           │ cert    │           │        │
│ CA     │           │         │           │        │
└────────┘           └─────────┘           └────────┘

TLS 1: Client ↔ Proxy (using proxy's generated cert)
TLS 2: Proxy ↔ Server (using server's real cert)

Proxy decrypts from client, re-encrypts to server.

Certificate Generation Process

1. Proxy has its own CA certificate (e.g., Burp CA)
2. Client trusts this CA (installed in trust store)
3. When client connects to example.com:
   a. Proxy connects to real example.com
   b. Proxy gets real certificate
   c. Proxy generates fake cert for example.com
   d. Fake cert signed by Proxy CA
   e. Client accepts fake cert (trusts Proxy CA)
4. Proxy can now read all traffic

Setting Up HTTPS Interception

# 1. Export Burp CA Certificate
# Proxy → Options → Import/Export CA Certificate
# Export Certificate in DER format

# 2. Install on client system

# Linux (Debian/Ubuntu):
sudo cp burp-ca.der /usr/local/share/ca-certificates/burp-ca.crt
sudo update-ca-certificates

# macOS:
sudo security add-trusted-cert -d -r trustRoot \
    -k /Library/Keychains/System.keychain burp-ca.der

# Windows:
# Run certmgr.msc
# Import to "Trusted Root Certification Authorities"

# Firefox (separate trust store):
# Preferences → Privacy & Security → Certificates → Import

# 3. Configure proxy
# Browser: 127.0.0.1:8080
# Or use Burp's embedded browser

# Start mitmproxy
mitmproxy

# CA certificate generated at:
# ~/.mitmproxy/mitmproxy-ca-cert.pem

# Install CA (same methods as Burp)

# Alternative: mitmweb for GUI
mitmweb

# Transparent mode (no client config needed)
mitmproxy --mode transparent

# With iptables redirect:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 \
    -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 \
    -j REDIRECT --to-port 8080

Certificate Pinning Challenges

Burp Suite Internals

TL;DR: Burp Suite is an intercepting proxy with tools for manual and automated security testing.

Architecture

┌─────────────────────────────────────────────────────────────────┐
│                        Burp Suite                                │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐           │
│  │  Proxy  │  │ Spider  │  │ Scanner │  │ Intruder│           │
│  │         │  │ (Crawl) │  │  (Auto) │  │ (Fuzz)  │           │
│  └────┬────┘  └─────────┘  └─────────┘  └─────────┘           │
│       │                                                         │
│       ▼                                                         │
│  ┌─────────────────────────────────────────────────────┐       │
│  │                   HTTP History                       │       │
│  │              (All intercepted traffic)               │       │
│  └─────────────────────────────────────────────────────┘       │
│       │                                                         │
│       ▼                                                         │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐           │
│  │Repeater │  │ Decoder │  │Comparer │  │Sequencer│           │
│  │(Resend) │  │(Encode) │  │ (Diff)  │  │(Random) │           │
│  └─────────┘  └─────────┘  └─────────┘  └─────────┘           │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Proxy Tab Workflow

1. Request enters Burp proxy

2. If intercept ON:
   ┌─────────────────────────┐
   │ Request held for review │
   │ - View/modify request   │
   │ - Forward or drop       │
   └─────────────────────────┘

3. If intercept OFF:
   Request forwarded immediately
   (still logged in History)

4. Response returns:
   - Can intercept responses too
   - Logged in History

5. All traffic in HTTP History
   - Right-click → Send to tools
   - Repeater, Intruder, Scanner, etc.

Key Burp Features for Pentesters

Useful Burp Configurations

# Scope configuration
Target → Scope → Add target URL
- Only log in-scope items
- Reduce noise

# Match and Replace
Proxy → Options → Match and Replace
- Auto-modify requests
- Change headers, body, etc.

# Response modification
Proxy → Options → Response modification
- Unhide hidden form fields
- Remove input limits
- Enable disabled buttons

# Invisible proxying
Proxy → Options → Request Handling
- Support invisible proxying for apps that don't respect proxy

# SSL Pass Through
Proxy → Options → SSL Pass Through
- Don't intercept certain hosts
- Useful for apps with pinning

# Performance
Project options → HTTP → Streaming responses
- Enable for large files
- Reduce memory usage

# Macros (for session handling)
Project options → Sessions → Macros
- Auto-login when session expires
- Handle CSRF tokens

Proxy Chains

TL;DR: Proxy chains route traffic through multiple proxies for anonymity or to bypass restrictions.

How Proxy Chains Work

Single proxy:
Client → Proxy → Server

Proxy chain:
Client → Proxy1 → Proxy2 → Proxy3 → Server

Each proxy only knows:
- Who sent it the request (previous hop)
- Where to send it (next hop)

Example with Tor:
Client → Guard → Middle → Exit → Server

Configuring Proxy Chains

# Install proxychains
apt install proxychains4

# Edit /etc/proxychains4.conf
# Chain types:
# dynamic_chain - skip dead proxies
# strict_chain - all must work
# random_chain - random order

# Example configuration:
[ProxyList]
socks5 127.0.0.1 9050    # Tor
socks4 192.168.1.10 1080 # SOCKS proxy
http   192.168.1.20 8080 # HTTP proxy

# Usage
proxychains4 curl http://example.com
proxychains4 nmap -sT target.com

# With Burp
proxychains4 java -jar burp.jar

Burp Through Tor

# 1. Start Tor
tor

# 2. Configure Burp upstream proxy
# User options → Upstream Proxy Servers
# Destination: *
# Proxy host: 127.0.0.1
# Proxy port: 9050
# SOCKS proxy: checked

# 3. All Burp traffic now goes through Tor

Proxy Detection and Bypass

Detecting Proxy Usage

Bypassing Proxy Restrictions

# SSH tunnel (SOCKS proxy)
ssh -D 9050 user@remote-server
# Then use localhost:9050 as SOCKS proxy

# SSH port forwarding
ssh -L 8080:target.com:80 user@jump-server
# Access target.com:80 via localhost:8080

# Stunnel for SSL wrapping
# Wrap any traffic in SSL to bypass inspection

# DNS tunneling
iodine -f -P password tunnel.example.com
# Creates tunnel through DNS

# HTTP tunneling through proxy
# Some proxies allow CONNECT to any port
CONNECT internal.server:22 HTTP/1.1
# Then SSH over the tunnel

Common Proxy Headers

X-Forwarded Headers

# Original client IP
X-Forwarded-For: 203.0.113.50

# Multiple proxies
X-Forwarded-For: 203.0.113.50, 70.41.3.18, 150.172.238.178
                 ↑ Client      ↑ Proxy1    ↑ Proxy2

# Original protocol
X-Forwarded-Proto: https

# Original host
X-Forwarded-Host: www.example.com

# Original port
X-Forwarded-Port: 443

Forwarded Header (RFC 7239)

Forwarded: for=203.0.113.50; proto=https; host=www.example.com
Forwarded: for=203.0.113.50, for=70.41.3.18

Via Header

Via: 1.1 proxy1.example.com, 1.0 proxy2.example.com

Security Implications

# Spoof client IP
curl -H "X-Forwarded-For: 127.0.0.1" https://target.com/admin
# May bypass IP whitelist

# Multiple X-Forwarded-For
curl -H "X-Forwarded-For: 127.0.0.1, attacker-ip" https://target.com
# Some parsers take first, some take last

# Host header injection
curl -H "X-Forwarded-Host: evil.com" https://target.com/password-reset
# May generate links to evil.com

# Protocol downgrade
curl -H "X-Forwarded-Proto: http" https://target.com
# May confuse application logic

Tools Reference

Intercepting Proxies

Forward Proxies

Reverse Proxies

Practice Labs

Beginner

Practice Exercises

1. Configure Burp to intercept mobile app
2. Chain Burp through Tor
3. Bypass WAF using header manipulation
4. Detect transparent proxy on network
5. Set up mitmproxy for automated testing

Lab Setup

# Practice reverse proxy setup
# Install nginx
apt install nginx

# Configure as reverse proxy (/etc/nginx/sites-available/default)
server {
    listen 80;
    server_name proxy.local;

    location / {
        proxy_pass http://backend:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

# Test header handling
curl -v http://proxy.local

Glossary

What’s Next?

Now that you understand proxies:

Summary

Proxy knowledge is fundamental for web security testing:

1. Forward Proxies - Client-configured, act on behalf of clients
2. Reverse Proxies - Server-side, protect backends
3. Transparent Proxies - Network-level, invisible to clients
4. HTTPS Interception - Requires CA trust, enables traffic inspection
5. Burp Suite - Essential tool for web application testing
6. Headers - X-Forwarded-* can be exploited

Key Skills:

• Configure browser/system to use proxy
• Set up Burp for HTTPS interception
• Understand proxy chain configuration
• Identify and test proxy-related vulnerabilities

Found this guide helpful? Check out the other posts in the SecureKhan penetration testing series.