Burp Suite Web Testing Questions

Hands on proficiency with Burp Suite for discovering, validating, and documenting web application vulnerabilities. Candidates should be able to configure the Burp proxy and browser integration, intercept and modify requests and responses, and use Repeater and Intruder for manual exploitation. They should perform and tune automated scans and passive analysis, craft and manipulate requests for injection testing, cross site scripting, authentication bypasses, session and cookie analysis, access control testing, and business logic assessment. The topic also covers testing of application programming interfaces, use and development of Burp extensions, collaborating with out of band testing services, exporting evidence and producing actionable vulnerability reports, and integrating Burp into a broader penetration testing workflow. Assessment focuses on practical ability to reproduce and demonstrate vulnerabilities, interpret and triage scanner output, troubleshoot tool behaviors, adapt techniques to application specifics, and communicate remediation advice.

HardTechnical

23 practiced

You need to craft an SSRF payload that triggers an out-of-band interaction captured by Burp Collaborator to prove an internal-host access. Explain the full exploit chain: how to identify SSRF entry points with Burp, how to craft Collaborator payloads, how to reduce noise and false positives, and how to present proof of concept in a way that maps to a fix the dev team can implement.

Sample Answer

Situation and high-level goal- I’m performing an authenticated web test and need an out‑of‑band (OOB) interaction (DNS/HTTP) to prove SSRF can reach internal hosts. I use Burp Suite + Burp Collaborator to demonstrate a real network access.

Step 1 — Identify SSRF entry points with Burp- Enumerate inputs accepting URLs/hosts: file fetchers, webhooks, image proxies, PDF generators, metadata endpoints, HTTP params, Host headers, XML/XXE locations.- Use Burp Intruder / Scanner with targeted payloads: http://{{token}}.burpcollaborator.net, https://{{token}}/path, 127.0.0.1, localhost, 169.254.169.254, http://[::1]/, file://127.0.0.1/- Test different contexts: query params, JSON bodies, multipart form data, headers (Host, X-Forwarded-For), redirect targets.- Watch for side effects: request timing, error pages, different status codes.

Step 2 — Craft Collaborator payloads (examples)- Use unique, descriptive tokens per test:

text

rpt-ssrf-12345.your-collab-subdomain.burpcollaborator.net

- DNS-only for low noise and firewall friendly:

text

http://rpt-ssrf-12345.<collab>

- For HTTP evidence include path and query:

text

http://rpt-ssrf-12345.<collab>/i?target=metadata

Step 3 — Reduce noise & false positives- Use one unique token per target+vector to map which parameter caused the hit.- Prefer DNS interactions (lighter, often not cached) unless you need full HTTP headers.- Avoid common CDN/third‑party resolvers by using Burp’s dedicated collaborator server or a controlled OOB domain.- Rate-limit tests and stagger tokens to avoid triggering WAF blocking.- Confirm persistence: re-test with different tokens to rule out cached/benign requests.

Step 4 — Exploit chain / example- Identify image URL param: GET /render?src={url}- Inject:

text

GET /render?src=http://rpt-ssrf-12345.<collab>

- Burp Collaborator shows DNS resolution from internal IP or HTTP GET with internal source headers → proves internal host access.

Step 5 — Presenting PoC and mitigation mapping- Deliver concise PoC with: - Exact request/response (raw HTTP), parameterized token, timestamped Collaborator logs (DNS/HTTP), screenshots. - Mapping table: token → parameter → vulnerable endpoint → collaborator evidence.- Provide remediation prioritized and actionable: - Validate and restrict allowed protocols/hosts (deny file://, 169.254.169.254, localhost). - Implement allowlist of external resolvable hosts or require user-supplied URLs be fetched server-side through a proxy that validates destinations. - Enforce network segmentation and egress filtering (block server reaching internal metadata/IP ranges). - Use safe URL fetch libraries, normalize inputs, and implement input length/character checks.- Optional code-snippet (pseudo):

text

if not is_allowed_hostname(parsed.host):
    reject_request(400, "Invalid host")

Why this proves a fix- The PoC maps directly to controls developers can implement: input validation, host allowlists, and network controls. The Collaborator evidence shows successful resolution/connection from the target environment — the exact behavior to block.

Summary checklist for a report- Reproduction steps with raw traffic- Unique tokens per vector- Collaborator logs and timestamps- Risk rating and suggested fixes (allowlist, egress rules, fetcher proxy)- Retest guidance and verification steps

HardTechnical

23 practiced

You are leading a red-team exercise and need to coordinate multiple testers using Burp Suite against a large web application under scope. Describe how you'd manage concurrency, avoid noisy duplicate testing, consolidate evidence from multiple Burp projects, ensure consistent reporting format, and keep everyone aligned with the test plan while preserving quality of findings.

Sample Answer

**Situation & high-level approach**I lead the engagement as the coordinator: define scope, split work into non-overlapping areas, enforce tooling/config standards, and centralize evidence and findings for consistent delivery and quality.

**Managing concurrency & avoiding noisy duplicates**- Create a detailed target matrix (hosts, apps, endpoints, auth paths) and assign owners per surface.- Publish a shared Burp “in-scope” and “exclude” list (Target → Scope) and require testers to import it before work.- Use endpoint-level ownership and mutexes for fragile/actions (e.g., destructive POSTs). Maintain a live occupancy board (Slack/Confluence) for time-boxed access.- Standardize scanning rules (no active scan without approval) and use Burp project files per tester; coordinate heavy scans off-peak and stagger automated scans.

**Consolidating evidence from multiple Burp projects**- Require export of Burp findings as XML/JSON + raw request/response (Burp scanner XML or Issues -> Save XML). Use a small parsing script to normalize fields into a central CSV/NDJSON and pull raw msgs from project files via Burp Extender API or existing BApp (or burp-rest if available).- Store all Burp project files and exports in a secure shared repo with consistent filenames (teamname_target_timestamp).

**Consistent reporting format & quality**- Provide a report template: title, impact, reproduction steps, PoC request/response snippets, remediation, CVSS score, exploitability, and business risk. Include a severity mapping table.- Require each finding to include a standardized checklist (repro steps, evidence, risk, remediation).- Triage meetings: daily brief + mid-engagement peer-review session where two testers validate each high/critical finding before inclusion.

**Keeping team aligned with the test plan**- Kickoff with runbook, access creds, rate limits, allowed tools, and escalation paths.- Use a central tracker (JIRA/Confluence) for issue intake, status, and owner; link Burp evidence.- Enforce post-test QA: lead reviews, sample re-tests, and final de-duplication pass to merge duplicates into single canonical findings.

This process reduces overlap, preserves service stability, produces consistent, high-quality evidence, and makes final reporting and remediation straightforward.

MediumTechnical

23 practiced

A Burp Scanner has flagged a reflected XSS but the application uses heavy client-side rendering (SPA). Explain how you would manually verify the finding using Burp (tools and techniques) and browser developer tools. Include handling of dynamic DOM sinks, using DOM Invader or other extensions, and the steps to produce a concise reproducible proof-of-concept.

Sample Answer

**Situation & goal**I want to manually verify a Burp Scanner reflected XSS finding in a heavy client-side rendered SPA, confirm it’s a DOM XSS (not server-side), locate dynamic DOM sinks, and produce a concise reproducible PoC.

**High-level approach**1. Confirm reflection path with Burp Proxy / Repeater.2. Reproduce in a proxied browser and observe runtime DOM behavior with DevTools.3. Use Burp extensions (DOM Invader) and DevTools techniques (mutation observers, breakpoints) to find dynamic sinks.4. Produce minimal PoC (URL + payload + steps + evidence).

**Concrete steps — Burp + browser**- Proxy the SPA with Burp (Burp Browser or a normal browser configured to Burp).- Capture the request where the scanner flagged reflection. Send that request to Repeater.- In Repeater, inject a safe, obvious JS test payload and visit the resulting URL in the proxied browser. Example payload:

javascript

<script>console.log("XSS-TEST-"+Date.now()); alert("XSS-TEST");</script>

- If the app strips <script> (likely), try DOM-focused variants that mutate the DOM or trigger event sinks:

javascript

<img src=x onerror="console.log('XSS-TEST')">

javascript

"><svg/onload=console.log('XSS-TEST')>

**Finding dynamic DOM sinks**- Open Chrome DevTools (Elements, Console, Sources).- Use DOM breakpoints: right-click a suspected parent node → Break on → subtree modifications.- Add XHR/fetch breakpoints to pause when SPA code processes the reflected value.- Use Event Listener breakpoints (e.g., click, input) if reflection occurs on interaction.- Instrument the page with a MutationObserver in Console to log where attacker-controlled text appears.

**Use DOM Invader / Burp extensions**- Run DOM Invader against the page to automatically scan for common sink patterns (innerHTML, insertAdjacentHTML, document.write, eval, location-related sinks).- Correlate DOM Invader hits with the exact JS file and line number shown.- From Burp, send malicious payloads via Intruder/Repeater to test different encodings and vectors (hash, path, query, post body, localStorage).

**Producing a concise PoC**- Record the exact URL and input location (e.g., query parameter ?q=PAYLOAD or fragment #/search=PAYLOAD).- Give the minimal payload that triggers execution and a step-by-step reproduction: 1. Proxy browser via Burp. 2. Visit: https://app.example.com/#/search?q=PAYLOAD 3. Observe alert/console message or screenshot of JS execution.- Include: the HTTP request (method, param), the payload, screenshot or console log, the vulnerable JS file and line (from DevTools or DOM Invader), and the exact DOM sink (e.g., element.innerHTML = userInput).

**Notes & caveats**- For SPAs the reflected value might be consumed only after async routing or user action — use breakpoints and mutation observers to catch that.- Prefer non-destructive PoC (console.log or benign alert); document safer alternatives if alert blocked.- If needed, demonstrate persistence via localStorage/sessionStorage injection paths.

This approach combines Burp interception, Repeater/Intruder for payload delivery, DOM Invader for automated sink discovery, and DevTools (DOM/XHR/event breakpoints + MutationObserver) to produce a concise, reproducible proof-of-concept with file/line sink evidence.

MediumTechnical

23 practiced

You want to create a Burp extension that passively flags cookies missing HttpOnly or Secure flags. In pseudocode (Java or Python/Jython), outline the key components: registering the extension, inspecting responses, parsing Set-Cookie headers, and reporting issues to Burp's issue API. Explain how you'd avoid duplicate findings and how you'd test the extension locally.

Sample Answer

**Approach — brief**Create a Burp passive scanner extension that registers as IBurpExtender and IScannerCheck, inspects HTTP responses, parses Set-Cookie headers, and raises IScanIssue entries for cookies missing HttpOnly or Secure. Deduplicate by tracking findings per host+cookieName+path+port.

1) Register extension and scanner

python

# Jython-style pseudocode
class BurpExtender(IBurpExtender, IScannerCheck):
    def registerExtenderCallbacks(self, callbacks):
        self._callbacks = callbacks
        self._helpers = callbacks.getHelpers()
        callbacks.setExtensionName("CookieFlagPassive")
        callbacks.registerScannerCheck(self)
        self._reported = set()  # store (host, port, cookieName, path, flagType)

2) Inspect responses and parse Set-Cookie

python

def doPassiveScan(self, baseRequestResponse):
        resp = baseRequestResponse.getResponse()
        if not resp: return None
        headers = self._helpers.analyzeResponse(resp).getHeaders()
        host = baseRequestResponse.getHttpService().getHost()
        port = baseRequestResponse.getHttpService().getPort()
        issues = []
        for h in headers:
            if h.lower().startswith("set-cookie:"):
                cookie = h[len("Set-Cookie:"):].strip()
                name, attrs = parse_cookie(cookie)  # split on '=' and ';'
                attrs_lower = [a.strip().lower() for a in attrs]
                if "httponly" not in attrs_lower:
                    key = (host, port, name, get_path(baseRequestResponse), "httponly")
                    if key not in self._reported:
                        self._reported.add(key)
                        issues.append(make_issue(..., "HttpOnly missing", evidence=h))
                if "secure" not in attrs_lower:
                    key = (host, port, name, get_path(baseRequestResponse), "secure")
                    if key not in self._reported:
                        self._reported.add(key)
                        issues.append(make_issue(..., "Secure missing", evidence=h))
        return issues if issues else None

3) Build issue objects and report

python

def make_issue(self, baseReqResp, name, detail, evidence):
        return CustomScanIssue(baseReqResp.getHttpService(), baseReqResp.getUrl(),
                               [baseReqResp], name, detail, "Information")

(CustomScanIssue implements IScanIssue; use callbacks.raiseAlert or return list as per API)

4) Avoid duplicates- Use a set keyed by host, port, cookie name, path and flag type.- Persist only in-memory for a run; optionally reset on scope changes.- Use normalized cookie names and paths to avoid variation.

5) Testing locally- Spin up a local webserver (e.g., Flask/Node) that emits various Set-Cookie headers (with/without flags).- Load sites in browser proxied through Burp while extension is enabled.- Confirm passive findings appear once per cookie and provide correct evidence.- Unit-test parse_cookie logic with inputs: multiple attributes, quoted values, commas in values.- Use Burp extender debug logging and enable stderr capture for errors.

Notes / Edge cases- Handle multiple Set-Cookie headers per response.- Account for cookie attributes with values (Domain=, Path=, SameSite=).- Normalize attribute casing and whitespace.

EasyTechnical

19 practiced

List the typical cookie and session configuration problems you would look for in Burp when analyzing session management. For each item (e.g., missing HttpOnly, missing Secure, SameSite lax/none, predictable session IDs, session fixation), explain why it's a problem and how to demonstrate exploitation or risk using Burp.

Sample Answer

**Overview**As a penetration tester I look for cookie/session misconfigurations that enable theft, tampering, or session takeover. For each I explain why it matters and how to demonstrate it in Burp.

**Missing HttpOnly**- Why: JavaScript can read/steal cookie via XSS → session theft.- Demonstration: Intercept response in Proxy → show Set-Cookie without HttpOnly. Use Burp Repeater to inject a reflected XSS payload that calls document.cookie; confirm attacker could exfiltrate cookie via a controlled URL.

**Missing Secure**- Why: Cookie sent over HTTP (unencrypted) → network sniffing / MITM.- Demonstration: Intercept request to HTTP endpoint showing session cookie in clear. Use Repeater to downgrade or force HTTP and show cookie present in request headers.

**SameSite lax/none (or absent)**- Why: Missing/incorrect SameSite allows CSRF or cross-site leakage of cookies.- Demonstration: Show Set-Cookie header value. Craft a CSRF PoC page that triggers a state-changing request from another origin; use Burp Collaborator or Proxy to capture resulting request with session cookie attached when SameSite is lax/none.

**Predictable Session IDs**- Why: Attacker can guess/forge sessions to impersonate users.- Demonstration: Collect multiple session IDs (Proxy) and analyze pattern (sequence, entropy). Use Burp Intruder with payload generation to attempt next IDs or test for acceptance; show authentication without known credentials.

**Session Fixation**- Why: Attacker sets victim’s session ID before login, then reuses it after victim authenticates.- Demonstration: Use Repeater to supply attacker-controlled session ID via Set-Cookie or URL, instruct victim to authenticate, then use that same session ID to access authenticated endpoints in Repeater/Proxy and confirm access.

**Missing Same-Origin or Path restrictions**- Why: Over-broad cookie scope increases exposure.- Demonstration: Show cookie Domain/Path values in Set-Cookie and request from subdomain/path to prove cookie sent where not needed.

**Short/Absent Expiration or Persistent Sessions**- Why: Long-lived tokens increase window for reuse.- Demonstration: Inspect Expires/Max-Age and show persistent cookie survives browser restart; show reuse in Repeater.

For each finding include request/response evidence from Burp, a PoC demonstrating exploitability (Repeater/Intruder/Collaborator), and remediation guidance (set HttpOnly, Secure, SameSite=strict/lax as appropriate, use high-entropy IDs, rotate on login, regenerate session on auth, limit domain/path, set reasonable TTL).

Unlock Full Question Bank

Get access to hundreds of Burp Suite Web Testing interview questions and detailed answers.

Join thousands of developers preparing for their dream job.