How portswigger/httpoxy-scanner works
<explanation>
1. Identify the project type and purpose
- This is a sample Burp Suite extension that demonstrates use of the HTTPoxy vulnerability with the Burp Collaborator service.
- It provides three language implementations (Java, Python, Ruby) as Burp extensions and a simple Node.js server to simulate a vulnerable application.
2. Analyze the file structure
- Top‑level artifacts:
• BappDescription.html, BappManifest.bmf – metadata for packaging as a Burp extension (BApp).
• README.md – overview, architecture hints, usage instructions.
• java/ – Java Gradle project with BurpExtender.java and HttPoxyIssue.java.
• python/ – Python implementation of the same logic.
• ruby/ – Ruby implementation.
• server/server.js – simple Node.js HTTP server that reads Proxy headers and makes outgoing requests to the Collaborator URL.
- Notices:
• Three parallel implementation folders share the same high‑level logic: generate collaborator payloads, trigger test requests, retrieve interactions.
• A standalone server folder serves as the vulnerable target for active scanning.
3. Examine the README for additional insights
- The extension:
• Uses Burp Collaborator context to generate unique payload URLs.
• Injects these URLs into Proxy headers during an active scan.
• Polls the Collaborator for any inbound interactions, detecting an HTTPoxy condition.
- The provided server merely issues HTTP requests to any URL found in incoming Proxy headers.
4. How to create a system design diagram
a. Main components
1. Burp Suite Host
2. Loaded Extension (choose one implementation: Java/Python/Ruby)
3. Burp Collaborator Service (embedded or remote)
4. Test Server (Node.js)
5. Scanner / Proxy module (built into Burp)
b. Relationships and data flows
• The Extension → Collaborator Service: “Generate payload URL” (API call)
• Extension → Proxy Module: “Inject payload into Proxy header”
• Proxy Module → Test Server: “Active scan request with Proxy header”
• Test Server → Collaborator Service: “Outgoing HTTP to payload URL”
• Extension → Collaborator Service: “Poll for interactions”
• Collaborator Service → Extension: “Return interaction records”
• Extension → Burp Scanner UI: “Report vulnerability”
c. Architectural patterns and design principles
• Plugin pattern: Extension loaded into host application (Burp Suite).
• Publish–subscribe style: extension publishes payloads, then subscribes (polls) for callbacks.
• Language‑agnostic strategy: three parallel implementations sharing an interface contract.
d. Key technologies and frameworks
• Java: Gradle-based BurpExtender plugin.
• Python: Burp API via Jython or Python‑native plugin loader.
• Ruby: Burp extender using JRuby or Ruby‑native loader.
• Node.js: Express‑style server (server.js).
• Burp Collaborator: built‑in or remote service API.
5. Guidelines for tailoring the diagram to this extension
- Emphasize the plugin–host relationship: show Burp Suite as the host and the extension as a separate module.
- Show the Collaborator as an external HTTP service with bidirectional API calls.
- Highlight the test server as the “vulnerable application” that simply proxies requests from headers to the Collaborator.
- Group the three language implementations into a single “Extension Implementation” box, with a note that any one can be loaded.
6. Diagramming best practices
- Use clear, consistent labels for each component (e.g., “Burp Suite”, “Extension”, “Collaborator Service”, “Test Server”).
- Draw directional arrows to show:
• Payload generation
• HTTP scan requests
• Outgoing interactions
• Polling for results
- Color‑code or use distinct shapes:
• Plugin‑type components (extensions) in one color/shape
• External services (Collaborator, Test Server) in another
• Host application (Burp Suite) in its own style
- Include a legend explaining colors/shapes.
7. Emphasis on detail
- Don’t just show host → server; break out each API call and data flow step.
- Capture configuration files (e.g., BappManifest) as part of the packaging component within the host.
- Label the three implementation folders as interchangeable modules behind a single “Burp Extension” interface.
By following these steps, you’ll produce a comprehensive architecture diagram that clearly conveys how the sample extension, the Burp Collaborator service, and the test server interact to demonstrate the HTTPoxy vulnerability.
</explanation>