Skip to content

Latest commit

 

History

History
109 lines (75 loc) · 4.66 KB

File metadata and controls

109 lines (75 loc) · 4.66 KB

PTK Concepts

OWASP Penetration Testing Kit (PTK) is a browser-based application security testing toolkit. It runs inside the browser session, so it can observe authenticated workflows, SPA routes, JavaScript execution, browser storage, cookies, JWTs, and API calls created by the frontend.

PTK complements proxy-based testing. A proxy sees HTTP traffic; PTK also sees browser-side context and can connect traffic, runtime behavior, loaded code, and user actions.

Core Capabilities

Capability Purpose
Dashboard Review technology stack, WAF hints, headers, crawled links, authentication signals, and scan status
Proxy / traffic log Capture requests and responses from real browser use
DAST Actively test live routes, requests, forms, APIs, and parameters
IAST Observe browser runtime behavior, taint flows, sources, and sinks
SAST Analyze loaded JavaScript, HTML, CSS, inline scripts, and external scripts
SCA Identify vulnerable or outdated client-side components
R-Builder Replay, edit, clone, export, and scan selected HTTP requests
JWT Inspector Decode, craft, and test JSON Web Token assumptions
Cookie Editor Inspect, edit, protect, block, import, and export cookies
Decoder / Encoder Convert values during manual testing
Automation Run PTK-backed scans from CLI, SDKs, CI, or tool hosts
ZAP integration Run PTK inside ZAP-launched browsers and report PTK findings into ZAP

Why Browser Context Matters

Modern applications often hide important security behavior behind the browser:

  • authenticated sessions and role-specific UI
  • hash-routed or History API single-page applications
  • JavaScript-generated API calls
  • localStorage, sessionStorage, IndexedDB, and cookies
  • client-side templates, redirects, and DOM sinks
  • bundled JavaScript that contains routes, endpoints, and validation logic

Testing only raw HTTP traffic can miss browser-only behavior. Testing only browser UI can miss request-level tampering opportunities. PTK is designed to connect both views.

DAST

Dynamic Application Security Testing tests the running application from the outside. PTK DAST sends or mutates requests, observes responses, and looks for vulnerabilities exposed through live routes, forms, parameters, APIs, headers, and browser-generated traffic.

Use DAST to answer:

Can this running application be attacked through exposed requests, parameters, APIs, and workflows?

Typical DAST findings include:

  • reflected or stored XSS
  • SQL injection
  • command injection
  • XPath injection
  • JWT weaknesses
  • broken access control indicators
  • unsafe redirect or input handling

IAST

Interactive Application Security Testing observes application behavior while the tester uses the app. PTK IAST instruments browser-side runtime behavior and watches for suspicious flows from sources to dangerous sinks.

Use IAST to answer:

Does untrusted input reach dangerous browser behavior during real application use?

IAST is especially useful for:

  • DOM XSS
  • SPA route changes
  • unsafe innerHTML, outerHTML, eval, script creation, or URL navigation
  • browser-side open redirect behavior
  • JavaScript-heavy workflows where request/response testing alone is weak

SAST

Static Application Security Testing analyzes code without exploiting the application. PTK SAST focuses on the client-side code actually loaded by the browser: external JavaScript, inline scripts, HTML, and CSS.

Use SAST to answer:

What risky client-side code is actually shipped to users?

SAST is useful for:

  • hidden client-side routes and endpoints
  • DOM XSS source/sink patterns
  • dangerous JavaScript APIs
  • hardcoded development endpoints or feature flags
  • risky third-party scripts loaded by the target

SCA

Software Composition Analysis identifies vulnerable or outdated client-side components served to the browser.

Use SCA to answer:

Are vulnerable client-side libraries being served to users, and where are they loaded?

SCA findings usually need manual impact analysis. A vulnerable library matters most when the affected component is reachable, used in the vulnerable way, or exposed on sensitive pages.

Choosing Engines

Situation Engines
Quick unauthenticated check DAST, SCA
Authenticated web app test DAST, IAST, SAST, SCA
SPA or JavaScript-heavy app IAST, SAST, DAST
API traffic visible from browser Proxy, R-Builder, DAST
JWT/session review JWT Inspector, cookies/storage, DAST
CI smoke validation DAST and selected IAST/SAST gates
Dependency review SCA plus manual reachability analysis

Start small. Add engines and scope once the target behavior, rate limits, and authorization are clear.