Skip to content

scanning.md

Latest commit

 

History

History
148 lines (104 loc) · 4.58 KB

scanning.md

File metadata and controls

148 lines (104 loc) · 4.58 KB
Raw

Scanning Engines

PTK includes DAST, IAST, SAST, and SCA engines. Each engine answers a different question. Use them together, but triage them differently.

DAST

DAST actively tests a running application through requests, parameters, forms, APIs, and browser-generated traffic.

When to Run DAST

Run DAST when:

  • you have confirmed scope and authorization
  • you have a stable test account
  • you understand whether state-changing actions are allowed
  • the target can tolerate the request volume
  • you have selected important pages or requests

Recommended DAST Workflow

  1. Browse the target normally.
  2. Identify high-value requests in the Proxy traffic log.
  3. Send selected requests to R-Builder when you want single-request testing.
  4. Run a small DAST scan first.
  5. Review findings and application impact.
  6. Increase breadth only when the first pass is stable.

DAST Triage

For each DAST finding, verify:

  • the exact request and parameter
  • whether the request is authenticated
  • whether the result is reflected, stored, or state-changing
  • whether a browser proof exists for XSS-like findings
  • whether controls reject a benign or missing payload
  • whether the finding is duplicated across multiple routes

Do not report a DAST finding only because a payload appeared in a response. Confirm exploitability or a defensible security impact.

IAST

IAST observes browser runtime behavior while you use the application.

When to Use IAST

Use IAST for:

  • SPAs and hash-routed apps
  • DOM XSS analysis
  • unsafe browser sinks
  • runtime-only JavaScript behavior
  • pages where payloads do not appear clearly in HTTP responses

Recommended IAST Workflow

  1. Start IAST on the target tab.
  2. Exercise the workflow manually: search, filters, profile, basket, account, upload, admin, or role-specific pages.
  3. Trigger route changes and form submissions.
  4. Review source-to-sink findings.
  5. Validate the input source and dangerous sink.

IAST Triage

For each IAST finding, check:

  • source type: URL, hash, storage, cookie, message, form, response, or script-controlled data
  • sink type: innerHTML, script execution, navigation, URL assignment, eval, or another dangerous API
  • whether the source is attacker-controllable
  • whether the route is reachable by an attacker or victim
  • whether application context makes exploitation practical

SAST

SAST analyzes client-side code loaded by the browser.

Watch: OWASP PTK SAST catches a DOM-based XSS vulnerability on PortSwigger's lab before using SAST for DOM XSS review.

When to Run SAST

Run SAST:

  • after browsing enough of the app to load representative bundles
  • on pages with rich JavaScript behavior
  • when looking for hidden routes and endpoints
  • when a DOM XSS or unsafe sink needs code context
  • before writing report root-cause details

SAST Workflow

  1. Browse important target pages.
  2. Run SAST from PTK.
  3. Review risky sinks, sources, hidden routes, and loaded scripts.
  4. Correlate SAST evidence with Proxy, DAST, and IAST.
  5. Use code references to explain root cause in reports.

High-Value SAST Signals

  • direct DOM writes from controllable values
  • template injection patterns
  • URL/hash parsing feeding sinks
  • unsafe redirect logic
  • hardcoded API paths
  • debug or admin routes
  • insecure crypto or token handling
  • external script dependencies on sensitive pages

SAST evidence is strongest when paired with runtime reachability from DAST or IAST.

SCA

SCA identifies vulnerable or outdated client-side components.

SCA Workflow

  1. Browse enough pages to load representative assets.
  2. Run SCA.
  3. Review component name, version, affected pages, and vulnerability references.
  4. Confirm whether the vulnerable feature is used by the app.
  5. Assign severity based on application reachability and exploitability, not just CVE severity.

SCA Triage Template

Use this structure:

  • Component:
  • Version:
  • Loaded from:
  • Affected pages:
  • Vulnerability:
  • Is the vulnerable code path reachable?
  • Application-specific impact:
  • Recommended upgrade or mitigation:

Engine Correlation

The best reports often combine engines:

Evidence How It Helps
Proxy Shows exact request/response and authentication context
DAST Shows active attack behavior
IAST Shows runtime source-to-sink behavior
SAST Shows root cause in loaded code
SCA Shows dependency risk and affected pages
R-Builder Shows repeatable manual proof

When multiple engines point to the same weakness, merge the evidence into one strong finding instead of reporting duplicates.