CRS-BRP-03
Burp Suite web and API protocol auditing: scoped proxy, Repeater, and differential authorization proofs
Client-side user interfaces hide dozens of background application requests, hidden object fields, and token exchanges behind visual forms. An intercepting proxy such as Burp Suite operates between a dedicated test browser and an authorized staging server. From that vantage point, the engineer inspects, edits, and compares individual HTTP/1.1, HTTP/2, and JSON-RPC messages accurately.
1. Scoped proxy gate and two-token differential BOLA verification
Repeater lanes replay identical object identifiers under separate tenant credentials into Comparer.2. Proving authorization and state flaws without destructive fuzzing
Before intercepting any traffic, the auditor defines the Target Scope allowlist and binds Burp Proxy to 127.0.0.1:8080 locally. A separate blank browser profile holds the proxy certificate so personal mail and production credentials stay untouched.
Broken Object Level Authorization (BOLA) and mass-assignment vulnerabilities cannot be confirmed reliably by blind automated fuzzers because error codes often look identical to valid responses. Instead, the engineer sends one captured GET request to Repeater and swaps account Alpha credentials for account Beta. Keeping the target invoice identifier constant produces an unambiguous differential proof without touching neighboring records.
The exact same proxy discipline applies when auditing modern agentic backends that exchange Model Context Protocol (MCP) tool calls over HTTP Server-Sent Events or JSON-RPC 2.0. Inspecting the raw JSON body in Repeater reveals whether the server validates caller tenant bounds on the backend or blindly trusts parameters generated by the language model.
| Command, Display Filter, or Primitive | Observed Technical Artifact | Operational Interpretation |
|---|---|---|
Target -> Scope -> Include in scope | Strict hostname and path prefix allowlist with out-of-scope logging disabled | Prevents accidental interception or probing of external third-party domains |
Proxy -> HTTP history | Chronological ledger of parsed HTTP/1.1 and HTTP/2 request-response pairs | Exposes undocumented routes, hidden JSON fields, and unauthenticated state transitions |
Repeater (Ctrl+R) | Manual single-request editor supporting raw header, verb, and HTTP/2 pseudo-header edits | Confirms BOLA, JWT validation flaws, and parameter tampering with zero database flood |
Comparer | Word-level and byte-level differential viewer across two recorded HTTP responses | Proves subtle authorization leaks by comparing Tenant Alpha, Tenant Beta, and unauthenticated replies |
Decoder | Deterministic local encoder/decoder for Base64URL, percent-encoding, and hex payloads | Inspects JWT header algorithms (alg) and claim sets offline without external web paste sites |
3. Differential Repeater practicum and scaling to formal witness automation
Proxy, replaying edits in Repeater, and comparing replies.In the laboratory scenario below, the engineer captures a benign read request for invoice 1042 under test tenant Alpha. Replaying that exact request in Repeater with the tenant Beta bearer token verifies whether HTTP 403 isolation holds.
# Baseline request captured in Burp Proxy on an authorized local staging stand:
GET /api/v1/invoices/1042 HTTP/2
Host: localhost:8890
Authorization: Bearer eyJhbGciOiJFZERTQSJ9.eyJzdWIiOiJ1c2VyXzEwMDEifQ.sig_alpha
Accept: application/json
# Differential probe in Burp Repeater (read-only GET, zero DELETE/DROP mutations):
# Replace Authorization with test user_1002 token while keeping invoice ID 1042:
GET /api/v1/invoices/1042 HTTP/2
Host: localhost:8890
Authorization: Bearer eyJhbGciOiJFZERTQSJ9.eyJzdWIiOiJ1c2VyXzEwMDIifQ.sig_beta
Accept: application/json
# Expected secure response: HTTP/2 403 Forbidden (zero cross-tenant fields returned)
# Vulnerable response (BOLA confirmed): HTTP/2 200 OK with user_1001 invoice bodyManual Repeater comparisons teach the exact logic of zero-damage verification, yet repeating them by hand across hundreds of microservice routes after every release is impractical. On INDRA, Stage L4 automates that paired target-versus-decoy differential across 46 classes (AUTH-BOLA, AI-MCP-02), while TOOL-API-04 and TOOL-MCP-03 audit specifications online.
4. Engineering reference notes for module CRS-BRP-03
Reason never to install a Burp Suite root certificate into the main workstation browser
A local proxy certificate authority allows interception of every encrypted session in that browser; confining it to a dedicated blank testing profile protects personal mail, banking, and production credentials.
Why single-request Repeater differentials outperform high-volume intruder fuzzing on APIs
High-rate fuzzing triggers rate limiters, pollutes staging tables with synthetic rows, and misses multi-account logic flaws. A paired two-token GET check in Repeater proves broken authorization cleanly with zero data corruption.
Inspecting JSON web tokens locally in decoder instead of online browser paste tools
Bearer tokens captured on staging systems frequently contain internal service URLs, user identifiers, or active session claims; decoding Base64URL segments inside Burp Decoder keeps every credential strictly in local memory.
Verifying HTTP/2 pseudo-headers and MCP JSON-RPC tool calls inside Repeater
Modern gateways route requests using :authority and :path pseudo-headers alongside JSON-RPC 2.0 method payloads, and Burp Inspector exposes mismatches between transport routing and backend authorization checks.
Enterprise pilot packages and air-gapped delivery
Perimeter posture, transport security & localization
Streebog-256 verification passport.Air-gapped interface verification (indra-core)
OpenAPI schemas and an isolated staging container as input, delivering a thirty-class paired decoy assessment with zero false positives, compiled mcp-sentinel contracts, and a full ledger passport.Autonomous agent runtime gate (MITR)
mcp.json manifests and tool schemas as input, delivering compiled satisfiability policies and pre-socket parameter enforcement.Request the offline kit or schedule a pilot
--no-index --find-links) and standalone verifier scripts are provided for isolated laboratory testing and enterprise pilot evaluations. Submit a work email below without page reload or write directly to af@isslab.ai.
Institutional developer and platform operator
OGRN 1267700083617, INN 9731161602, KPP 773101001, 18 Davydkovskaya Street, Suite VIII, Moscow, 121352). Under the Security 3.0 research and engineering program, the institute develops and operates the MITR runtime action gateway and the INDRA verification stand, publishes the monograph Proven Action, and maintains open Apache-2.0 software packages with zero outside subcontractors.