VulnTech Setting Up Burp Suite for iOS HTTPS Proxying

Setting Up Burp Suite for iOS HTTPS Proxying

Intercepting and modifying HTTPS traffic is one of the most important parts of iOS pentesting. Burp Suite allows you to view, modify and replay encrypted requests made by iOS apps. Because iOS enforces App Transport Security (ATS) and certificate pinning, the setup must be done correctly or interception will fail. This chapter gives a full hands-on workflow including network setup, certificate installation, advanced MITM configuration, SSL pinning bypassing and troubleshooting.

Requirements

iPhone (jailbroken or non-jailbroken)
Burp Suite (Community or Professional)
macOS or Linux machine
Wi-Fi network controlled by you
Same Wi-Fi network for iPhone and your machine

Step 1: Configure Burp Suite Proxy Listener

Open Burp:

Proxy → Proxy Settings → Add a listener

Use these settings:

Bind to address: All interfaces (0.0.0.0)
Port: 8080

Enable:

“Support invisible proxying”
“Request interception turned off” (you will enable it later if needed)

Click “OK”.

Verify Listener

Run:

netstat -an | grep 8080

You should see Burp listening.

Step 2: Find Your Computer’s Local IP

On macOS:

ipconfig getifaddr en0

On Linux:

ip a | grep wlan0

Example output:

192.168.0.101

This IP will be used as the proxy address on the iPhone.

Step 3: Configure Wi-Fi Proxy on iPhone

On the iPhone:

Settings → Wi-Fi → Tap your network → Configure Proxy → Manual

Enter:

Server: your computer’s IP
Port: 8080

Leave Authentication OFF.

Return to Wi-Fi screen so settings apply.

Step 4: Download Burp CA Certificate on iPhone

Open Safari on the iPhone:

http://burp

Burp will serve the CA certificate for installation.

Tap “CA Certificate” → Allow download → Settings will open showing “Profile Downloaded”.

Step 5: Install the Certificate

Settings → General → VPN & Device Management → Burp Suite CA → Install

After installation:

Enable Full Trust for the Certificate

Settings → General → About → Certificate Trust Settings
Enable:

PortSwigger CA – Full Trust

Without this step, HTTPS interception will always fail.

Step 6: Test Intercepting HTTPS Traffic

Open Safari and browse to:

https://example.com

In Burp → Proxy → HTTP history
You should see HTTPS requests appearing unencrypted.

If nothing appears → fix your proxy settings (see troubleshooting section).

Step 7: Configure Burp for Mobile API Testing

Disable auto-certificate verification

Project Options → SSL → Disable “Rebuild server certificates using…” if needed.

Enable invisible proxying (important for mobile apps)

Proxy → Proxy Settings → Listeners → Edit → Enable “Support invisible proxying”.

Invisible proxying ensures apps that do not explicitly set proxy headers still route correctly.

Step 8: Handling Apps with SSL Pinning (Non-Jailbroken)

Non-jailbroken devices cannot bypass SSL pinning automatically.

Possible approaches:

Method 1: Patch the IPA

Use tools like:

Hopper or Ghidra to patch SSL validation
Re-sign the patched IPA using Xcode + signing certificates

This requires advanced reverse engineering.

Step 9: Handling Apps with SSL Pinning (Jailbroken Device)

Jailbroken devices give you multiple easier options.

Option 1: SSL Kill Switch 2

Install:

apt install com.nablac0d3.sslkillswitch2

Reboot the phone.

All SSL pinning from most apps is now bypassed.

Option 2: Frida Script

Run:

frida -U -f com.example.app -l ios_ssl_bypass.js --no-pause

Example hook (short version):

Interceptor.attach(ObjC.classes.SSLCertifcate.method, {
    onEnter: function(args) {
        console.log("SSL bypass triggered");
    }
});

Option 3: Objection

objection -g com.example.app explore
ios sslpinning disable

This instantly disables most SSL pinning functions.

Step 10: Intercepting Backend API Calls

Once SSL pinning is bypassed:

Open Burp → Proxy → HTTP History

Look for:

Authorization headers
JWT tokens
API endpoints
Device identifiers
Session cookies
Sensitive parameters

You can now modify request parameters and replay them for attacks such as:

IDOR
BOLA
Broken auth
Weak server-side validation
Hidden API methods

Step 11: Using Burp Repeater and Intruder with iOS Apps

Send intercepted request to Repeater

Right-click → Send to Repeater

Use this for:

Testing broken authentication
Parameter fuzzing
Endpoint discovery
Testing for IDOR in numeric IDs
Evaluating OTP logic

Send to Intruder

Used for:

Credential stuffing
Brute force
Fuzzing header-based auth
Discovering hidden parameters

Step 12: Testing ATS (App Transport Security) Behavior

Some apps bypass ATS incorrectly.

Check ATS Logs Using Device Console

idevicesyslog | grep -i ATS

If you see logs showing non-compliant endpoints, the app violates iOS network security guidelines.

This often leads to exploitable API weaknesses.

Step 13: Verifying Your Setup

Run:

curl -x http://<your-ip>:8080 https://example.com

If Burp captures it, proxy is working for HTTPS.

Troubleshooting

No traffic appearing in Burp

Wrong IP used → recheck
Proxy set to “Off”
iPhone on different Wi-Fi band (2.4 vs 5 GHz router segregation)
Burp listener not bound to all interfaces
VPN enabled on iPhone
Firewall blocking port 8080

HTTPS works in Safari but not in apps

SSL pinning active
ATS blocks insecure connections
App uses pinned certificate chains
App uses custom networking stack (e.g., Alamofire + pinning)

Burp certificate not trusted

You didn’t enable “Full Trust for Root Certificates”
You installed wrong certificate profile
Cert expired → regenerate from Burp → reinstall

Intel Dump

Burp Suite requires proxy listener on 0.0.0.0:8080
iPhone must use manual HTTP proxy pointing to your machine
Burp CA must be installed and trusted in iOS settings
HTTPS interception requires bypassing SSL pinning for most apps
Jailbroken devices allow SSL Kill Switch, Frida and Objection
Non-jailbroken devices require binary patching
Burp Repeater and Intruder are essential for API pentesting
ATS behavior can be analyzed via device logs
Correct network setup is crucial for stable interception