Penetration Testing Methodology and Execution Questions

Direct answer

SQL Injection (SQLi) happens when untrusted input is concatenated into a SQL query instead of being treated as pure data, letting an attacker change the query's logic. The variants differ mainly in how much feedback the application gives you back: error-based and union-based rely on visible output differences, boolean-blind relies on a true or false behavioral difference with no error message, and time-based relies on nothing visible at all, just response timing.

Structured elaboration

• Error-based: the application returns a raw database error message when the query breaks. Typical vulnerable points are search fields, login forms, and any URL parameter fed directly into a WHERE clause. A minimal, low-risk verification step is appending a single unescaped quote character to the parameter; if the response includes a database syntax error instead of a clean result or a generic error page, the parameter is reaching the query unescaped.
• Union-based: once a point is confirmed injectable, you determine the number of columns the original query returns, commonly by incrementing an ORDER BY clause until it errors, then append your own columns to the result set the application already displays. This is most useful where query results are rendered directly on the page, since it lets you read data back through the application's normal output rather than through errors.
• Boolean-blind: no error and no extra output appears, but the vulnerable points look the same as error-based ones, filters and ID parameters feeding a query whose results are shown or hidden rather than displayed directly. You compare the application's response when you append an always-true condition against its response when you append an always-false condition; if the page content or behavior differs between the two, a search returning results versus returning none, that difference is a channel you can use to extract data one bit at a time.
• Time-based: used when there's no visible content difference at all, such as a login form that always returns the same generic message regardless of what's true in the database. Injecting a conditional delay and measuring whether the response takes noticeably longer when the condition is true versus immediate when it's false confirms the injection point exists without needing any visible signal in the response body.

Worked example

On a product search endpoint with a URL parameter like category=books, error-based testing means trying category=books' and comparing the two responses: a clean, unchanged results page suggests the input is properly parameterized or escaped, while a raw database error, or a subtly different response such as the page silently returning zero results where it previously returned several, is the first signal worth investigating further. From there you'd escalate to determining the column count and, only if authorized to prove impact, using a union-based read of a single, low-sensitivity value like the database version string, which is enough to prove the class of vulnerability without pulling any actual customer data.

Trade-offs and pitfalls

• Proving exploitability doesn't require extracting real data; pulling a harmless value like the database version is normally sufficient evidence, and it keeps the test within the engagement's data-handling rules.
• A clean-looking response to a single test character doesn't rule out injection; some frameworks catch and mask the specific error you're looking for while still being vulnerable to a differently shaped input, so a single negative test is weak evidence on its own.
• Time-based testing is the noisiest to interpret, since normal network jitter or server load can produce false positives; always compare against a baseline timing measurement from an unmodified request first.

Direct answer: The underlying facts of a finding don't change across audiences, but the language, the evidence shown, and what you're asking each reader to do all change. A nontechnical executive needs business risk and a decision; a developer needs exact technical detail to fix the code; security operations (SecOps, the team that monitors and responds to live threats) needs detection signals, not a fix recommendation.

Structured elaboration

Worked example. For a confirmed SQL injection that dumped user records, one sentence per audience:

• Executive: "This flaw let an outside attacker download every customer's password without logging in, which creates breach-notification and reputational exposure until it's fixed."
• Developer: "The username parameter in the login request is concatenated directly into the SQL query, so a UNION-based payload pulls arbitrary columns from the users table; switch it to a parameterized query."
• SecOps: "Watch the web server and firewall logs for repeated UNION SELECT patterns and abnormal response-length spikes on the login endpoint, and pull the last 90 days of access logs to check for prior exploitation."

Trade-offs and pitfalls. Sending one document to all three audiences is the most common mistake: executives disengage from SQL syntax, and developers get frustrated by vague "critical risk" language with no reproduction steps. Don't strip technical specificity from the developer-facing version to keep the report shorter, that's the one audience that needs the most detail. For the executive version, avoid both minimizing severity to reduce alarm and overstating it for effect, either erodes trust in the next report. Keep exact payload strings out of executive summaries; they add risk without adding to the decision being made.

Direct answer

A non-destructive external network test follows a phased methodology, commonly described by the Penetration Testing Execution Standard (PTES) or NIST Special Publication 800-115, where each phase gates the next: authorization and scope are locked before any reconnaissance starts, recon shapes what gets actively scanned, scanning results shape what is actually attempted, and every action from first contact onward is logged well enough to support both remediation verification and two very differently pitched audiences in the final report.

Structured elaboration

• Pre-engagement (scope and rules of engagement): define exact in-scope IP ranges and domains, explicitly exclude anything not authorized such as third-party-hosted assets, agree on testing windows and any blackout periods, and get written authorization signed by someone with actual authority over the assets. Set escalation contacts and a stop condition up front, most importantly what happens if the team discovers signs of an active real intrusion already underway, which should trigger immediate escalation rather than continued routine testing.
• Reconnaissance: passive sources first, WHOIS, DNS records, certificate-transparency logs, employee and open-source intelligence (OSINT), and services like Shodan or Censys, since none of this touches the target directly and stays in the lowest-risk part of the engagement. Only once passive sources are reasonably exhausted does the team move to active queries directly against the target's own infrastructure, building an asset inventory and attack-surface map before ever attempting an exploit.
• Scanning methodology: host discovery, then port scanning, typically a fast broad pass followed by a deeper targeted scan against the ports found open, then service and version fingerprinting cross-referenced across multiple independent signal sources rather than trusted from a single banner, and finally automated vulnerability scanning whose output gets manually triaged before anything is treated as a confirmed finding, since untriaged false positives waste the exploitation phase chasing non-issues.
• Exploitation strategy with safety controls: prioritize validated vulnerabilities by realistic exploitability and business impact rather than attempting every possible avenue. Because this engagement is explicitly non-destructive, prefer proof techniques that demonstrate access without writing or deleting production data or causing service disruption, for example confirming a vulnerable service's version and a documented exploit's applicability through a benign, read-only proof rather than a live exploit attempt against production, unless a controlled window and explicit sign-off exist for something more invasive. Keep a real-time communication channel open with the client during this phase, since it carries the highest risk of accidental impact, with a pre-agreed plan for what happens if something unexpected occurs, such as a service going down even if the test did not cause it.
• Post-exploitation objectives: for a scoped external network test, this phase is about demonstrating realistic business impact rather than deep internal lateral movement, which usually belongs to a broader engagement scope. The objective is showing what an external attacker who gained that initial foothold could plausibly reach next, such as whether the compromised host holds credentials or trust relationships reaching further into the environment, demonstrated conservatively and non-destructively, then stopping and documenting rather than pushing further than the engagement's scope and non-destructive mandate allow.
• Evidence collection for reporting: timestamped logs of every action, command, target, and result, detailed enough to reconstruct exactly what was done, screenshots or output captures at each key milestone such as initial access or any privilege change, and a clean mapping from raw evidence to each specific finding so nothing in the final report is unsupported by an artifact in the engagement notebook.
• Remediation verification: once the client reports fixes deployed, retest the specific finding rather than re-running the whole engagement, and confirm the fix actually closes the underlying issue rather than just changing its symptoms. Confirming that a vulnerable component was genuinely upgraded matters more than confirming the original exploit payload now fails, since a narrow payload-specific patch can leave the same vulnerability class exploitable through a slightly different approach.
• Reporting to two audiences: non-technical stakeholders need business risk framed around a small number of retained numbers and a plain-language consequence narrative, while technical stakeholders need exact reproduction steps, evidence, and remediation guidance tied to the specific vulnerable component, delivered as two coordinated documents drawing from the same underlying findings rather than one generic report trying to serve both at once.

Worked example

flowchart TD
  A[Pre-engagement: scope, ROE, written authorization] --> B[Reconnaissance: passive then active]
  B --> C[Scanning: discovery, port scan, fingerprinting, vulnerability triage]
  C --> D[Exploitation: validated findings only, safety controls, live client contact]
  D --> E[Post-exploitation: demonstrate business impact, non-destructive, stop at scope boundary]
  E --> F[Evidence collection: logs, screenshots, mapped to findings]
  F --> G[Reporting: executive risk narrative and developer reproduction detail]
  G --> H[Remediation verification: retest each fixed finding]
  H -->|fix confirmed| I[Finding closed]
  H -->|fix incomplete| D

Concretely, if scanning turns up an outdated VPN (virtual private network) appliance with a known public exploit, the team confirms the version and the exploit's applicability through a benign banner and behavior check rather than firing the live exploit at a production appliance without a controlled window. If sign-off for a more invasive proof exists, the team demonstrates access conservatively, checks what credentials or network trust that appliance holds, documents that as the business-impact story (an external attacker reaching this appliance could plausibly pivot toward the internal network it bridges), and stops there rather than continuing further into internal systems outside this engagement's scope. When the client later reports the appliance patched, the retest specifically re-checks the patched version and the original exploit path, not the whole external estate again.

Trade-offs and pitfalls

• Treating scanning-phase automated output as confirmed findings without manual triage is the most common way an engagement wastes its exploitation-phase time chasing false positives instead of real risk.
• Skipping the pre-agreed stop condition for an active real intrusion is a serious mistake: continuing routine testing while an unrelated real attacker is active in the environment can contaminate evidence, interfere with an active incident response, or even get misattributed to the test itself.
• Verifying a fix only against the exact original payload, rather than the underlying vulnerability class, gives a false sense of closure; a retest that passes for the wrong reason is worse than no retest, since it tells the client a real risk is resolved when it is not.

I find candidate injection points passively by watching what the app reflects back unmodified as I browse it normally, then confirm and refine with Burp Repeater using a harmless, unique marker before ever sending a real payload, and I always tailor the payload's syntax to the exact spot in the page where my input lands.

Discovery: passive then active

• Passive: proxy all traffic through Burp, and watch for any parameter whose value reappears verbatim in the HTML body, an attribute, or inline JavaScript.
• Active: fuzz parameters with a distinctive marker string (something like zzTESTzz) and search responses for that marker, noting whether it comes back encoded or raw.

Context-specific payloads

• HTML body: <script>alert(1)</script>, or <img src=x onerror=alert(1)> if script tags are filtered.
• HTML attribute: break out of the attribute first, for example " onmouseover=alert(1) x=". To trace it: if your input lands inside <input value="HERE">, the leading " closes the value attribute, onmouseover=alert(1) adds an event handler that runs when the mouse moves over the field, and the trailing x=" opens a harmless leftover attribute so the tag stays valid HTML.
• JavaScript string literal: close the string and add a statement, for example ');alert(1);//. To trace it: if your input lands inside a call like search('HERE'), the leading ') closes the string and the function call, ;alert(1); runs as its own statement, and the trailing // comments out the leftover ') so the script does not throw a syntax error.
• URL or href context: javascript:alert(1), or an attribute breakout like "><svg onload=alert(1)>.

Confirming with Repeater

Send the crafted request in Repeater and inspect the raw response for the payload appearing unencoded exactly where expected; if it's being encoded or filtered, adjust case or encoding and retry before concluding the point isn't exploitable.

Demonstrating impact

A benign alert(1) popup, captured with a screenshot alongside the exact request, is the conventional proof for cross-site scripting (XSS); the point is proving script execution happened, not building a full attack chain against a real user.

DOM XSS versus reflected XSS

Reflected XSS round-trips through the server; the payload appears somewhere in the HTTP response Burp can see. Document object model (DOM) XSS never touches the server at all; it's entirely client-side JavaScript writing attacker-controlled input into a dangerous sink like innerHTML. Burp's passive scanner and its DOM Invader browser extension can flag likely DOM sinks, but confirming a DOM XSS finding means reading the page's client-side JavaScript, not just watching HTTP traffic.

Worked example

A search box reflects my marker zzTESTzz unencoded inside <div>results for zzTESTzz</div>. I replace it with <script>alert(1)</script> in Repeater; the raw response shows the tag unencoded, and loading that request in a browser pops the alert, confirming HTML-body-context reflected XSS.

Trade-offs and pitfalls

A common pitfall is trying a <script> payload everywhere regardless of context, missing that an attribute or JavaScript-literal context needs a different breakout syntax entirely. Another is confusing "the marker reflected" with "the payload executed," since output encoding can make a parameter reflect visibly while still being completely safe.

Direct answer

Pre-engagement scoping turns a client's vague security concern into a bounded, authorized, and safely executable test plan, and doing it well is what prevents legal exposure, scope creep mid-engagement, and wasted testing time. It has to cover objectives, a concrete asset inventory, explicit in-scope and out-of-scope boundaries, permitted and prohibited techniques, data handling rules, points of contact, formal authorization, scheduling, and a Statement of Work (SOW) that ties all of it together contractually.

Structured elaboration

• Test objectives and success criteria: state the actual business question being answered, for example whether an external attacker can reach cardholder data, rather than a vague "find vulnerabilities."
• Asset inventory: a concrete list, not a description, IP ranges and CIDRs (Classless Inter-Domain Routing blocks), domains and subdomains, specific application endpoints or API base URLs, and mobile app package identifiers.
• In-scope and out-of-scope targets: explicit exclusions matter as much as inclusions, for example a third-party payment processor or a disaster-recovery site.
• Permitted and prohibited testing techniques: is social engineering allowed, is any denial-of-service-style testing allowed, is destructive testing permitted anywhere, and if so, only against a specific staging environment.
• Data handling and evidence rules: how discovered sensitive data is handled during and after the test, encryption of the report and evidence at rest, and a retention and destruction timeline.
• Points of contact and escalation: a technical contact for day-to-day questions, and a separate emergency contact reachable for a critical finding or an accidental outage, available for the full testing window.
• Authorization and legal approvals: a signed authorization letter, plus separate cloud-provider authorization when assets are hosted on a major cloud platform, since some providers require advance notification for certain testing activity regardless of the client's own sign-off.
• Scheduling constraints: the testing window itself, plus blackout periods such as quarter-end close or a major release week.
• Statement of Work contents: deliverables, timeline, price, the methodology framework referenced (for example PTES, the Penetration Testing Execution Standard), assumptions and exclusions, and the report's delivery format and confidentiality terms.

Worked example

A condensed scope-document excerpt for a retail client spanning web, API, and mobile surfaces:

• Objective: assess whether an external attacker can reach customer payment data or administrative functions.
• Assets: the web storefront domain, the REST API base path, the iOS and Android app package identifiers, and the CIDR range covering the public-facing load balancers.
• Out of scope: the third-party payment gateway's hosted checkout, and the corporate email and collaboration tenant.
• Permitted: standard web and API testing techniques, automated scanning throttled to a defined rate. Prohibited: denial-of-service-style stress testing, social engineering of employees, and any destructive testing directly against the production database, using a provided staging replica instead.
• Data handling: any live customer data discovered is redacted in screenshots, reported to the named security contact within 24 hours rather than held for the final report, and deleted from tester systems within 30 days of delivery.
• Points of contact: a security engineer for day-to-day technical questions, and the CISO's (Chief Information Security Officer's) direct line as the emergency contact for a suspected active breach or unintended outage, both reachable during the agreed testing window.
• Authorization: signed by the client's general counsel; since the hosting provider is a major cloud platform, the engagement is registered under that provider's own penetration-testing policy in advance, since standard tooling is permitted under that policy but denial-of-service simulation is not.
• Scheduling: weekday business hours over three weeks, with a blackout during the client's peak sales week.
• SOW: fixed-price, PTES-aligned methodology, deliverables of interim critical-finding alerts, a final report, and one retest.

Trade-offs and pitfalls

• Scoping too narrowly can exclude a boundary that still matters; excluding a third-party payment iframe doesn't mean the storefront's own session-handling around it is safe to skip.
• Vague or ambiguous "safe" language in the authorization document, rather than a concrete asset list, creates real risk if a finding later gets disputed as unauthorized access.
• Skipping cloud-provider notification because the client already signed off can still violate that provider's own terms of service; the client's authorization and the provider's authorization are two separate approvals.