Skip to content

workflow.md

Latest commit

 

History

History
149 lines (103 loc) · 4.29 KB

workflow.md

File metadata and controls

149 lines (103 loc) · 4.29 KB
Raw

Pentest Workflow

This workflow is intentionally practical. It assumes you are testing an authorized web application and want useful findings, not just raw scanner output.

Watch: 3 easy steps to start your bug bounty

Phase 1: Prepare

  1. Confirm written authorization and scope.
  2. Create or reset a dedicated PTK browser profile.
  3. Prepare test accounts for each role.
  4. Note rate limits, allowed testing windows, and destructive-action rules.
  5. Decide which engines are safe for the first pass.

Start with low-intensity testing. Increase breadth only after you know how the target behaves.

Phase 2: Establish a Baseline

Open the target and use it normally:

  • sign in
  • visit the dashboard/home page
  • perform search/filter actions
  • open profile/account settings
  • exercise role-specific workflows
  • submit safe forms
  • visit pages that trigger API traffic

Then open PTK and check:

  • Dashboard technology and WAF hints
  • security headers
  • crawled links
  • captured traffic
  • cookies and browser storage
  • loaded JavaScript and components

The baseline tells you what PTK can see before any active testing starts.

Phase 3: Recon

Use recon to decide where active testing should focus.

Watch: OWASP PTK 9 8 0 for a newer PTK workflow demonstration.

Dashboard Recon

Look for:

  • frameworks and frontend libraries
  • WAF or CDN hints
  • missing or weak security headers
  • authentication and session signals
  • interesting linked routes
  • JavaScript-heavy pages

Proxy Recon

In the traffic log, look for:

  • API endpoints with IDs, filters, sort fields, or search parameters
  • state-changing POST/PUT/PATCH/DELETE requests
  • file upload/download routes
  • redirects and callback URLs
  • JSON APIs with nested fields
  • endpoints that behave differently by user role

Send high-value requests to R-Builder for manual tampering.

SAST Recon

Use SAST to find:

  • hidden routes and API paths in JavaScript bundles
  • DOM XSS sources and sinks
  • risky browser APIs
  • development flags or debug endpoints
  • code that references admin, payment, upload, or integration workflows

SCA Recon

Use SCA to identify vulnerable libraries and the pages where they load. Do not report library version alone as high impact unless the vulnerable component is reachable or exploitable in the application context.

Phase 4: Active Testing

Run active testing in layers:

  1. DAST against selected requests or a small page set.
  2. IAST while manually exercising SPA and JavaScript-heavy workflows.
  3. SAST against loaded scripts after navigating through important routes.
  4. SCA after enough pages have loaded representative client-side components.

For authenticated applications, repeat critical checks with different roles.

Phase 5: Manual Validation

Use R-Builder, JWT Inspector, cookies/storage, and Decoder/Encoder to validate findings manually.

For each suspected issue, answer:

  • Is the affected route in scope?
  • Which user role can reach it?
  • What exact input controls the behavior?
  • Is there a reliable proof?
  • Is the behavior exploitable or only suspicious?
  • What is the realistic impact?
  • What server-side or client-side fix is appropriate?

Phase 6: Reporting

Export scan results, but do not paste raw scanner output into the report. Convert findings into reproducible, impact-focused reports.

For each finding, include:

  • title and severity
  • affected asset and user role
  • concise description
  • impact
  • steps to reproduce
  • request/response or runtime evidence
  • root cause
  • recommendation
  • retest steps

Use Reporting for templates.

Phase 7: Retest

After fixes:

  1. Clear browser state or use a fresh profile.
  2. Re-run the original proof.
  3. Re-run related PTK checks.
  4. Confirm the vulnerable behavior is gone.
  5. Check for partial fixes, bypasses, or regressions.

Recommended Daily Pattern

For a normal web-app test, a good rhythm is:

  1. Browse and authenticate manually.
  2. Review Dashboard and Proxy.
  3. Run SAST on loaded code.
  4. Run bounded DAST on selected requests.
  5. Enable IAST and exercise SPA workflows.
  6. Use R-Builder and JWT Inspector for manual proof.
  7. Export, triage, and report.

This keeps scanner output tied to real user workflows and makes the final evidence stronger.