Web app workflows BETA

Send "web" in your chat and the model replies with these web-application testing workflows and their exact syntax — no need to memorize anything.

Beta — these workflows are still being verified, so double-check the results before relying on them.

• web:crawl <url>

  Maps a web application the way a proxy would — crawling its pages, capturing every response, building the list of URLs that take parameters, and decoding any encoded parameter values.

  katanawebfetchgauarjunjwt_tool

  How it works

  1. Crawls the app with katana and stores every response to disk, rendering JavaScript-heavy or Cloudflare-protected pages with the headless browser (webfetch) when a plain crawl returns little.
  2. Pulls historical URLs from the Wayback Machine (gau) for extra surface.
  3. Builds the parameterized-URL worklist — every URL that carries a query string — and discovers hidden parameters with arjun.
  4. Decodes encoded parameter values on the fly (base64, hex and JWT), since the decoded content is where ids, roles and tokens live.
  5. For any JWT found, tests whether it is signed with a weak or default key (jwt_tool against a defaults list and rockyou) and flags a forgeable token.
• web:sqli <url>

  Flags where SQL injection may be possible, without exploiting anything.

  katanacurlwebfetch

  How it works

  1. Takes the parameterized-URL worklist from the crawl.
  2. For each parameter, sends one baseline request and one with a single quote appended, and looks for a database error in the response that the baseline did not produce.
  3. Flags only the parameters that produce a SQL error as possibilities to verify by hand — never as confirmed injection.
  4. Runs no sqlmap and no exploitation payload; the output is a worklist for manual testing in Burp Repeater.
• web:xss <url>

  Flags reflected and stored cross-site-scripting possibilities by submitting a marked test canary to parameters and forms.

  katanacurlwebfetch

  How it works

  1. Finds the injection points — reflective parameters and HTML forms in the captured responses.
  2. Submits a unique marked canary and checks whether it comes back unescaped in the immediate response (reflected).
  3. Re-fetches the pages that display submitted content to see whether the canary persisted unescaped (stored).
  4. Flags only unescaped reflections as possibilities to verify by hand — never as confirmed XSS. The stored check deliberately leaves the marker on the target, so it runs only against a site you are authorized to modify.
• web:secrets <url>

  Scans the captured responses, cookies and headers for exposed sensitive data.

  katanaSecretFinder

  How it works

  1. Greps every captured response for credentials, tokens, keys, JWTs, session ids and similar sensitive strings.
  2. Reviews the cookies for missing HttpOnly, Secure and SameSite flags on session and auth cookies.
  3. Reports only strings literally present in the responses — never an invented secret or header.
• web:full <url>

  Runs the whole chain — crawl, SQLi, XSS and secrets — into a single report.

  katanaarjunjwt_toolnucleihttpxwafw00f

  How it works

  1. Runs web:crawl, web:sqli, web:xss and web:secrets in order against the target.
  2. Adds the technology stack and WAF for context.
  3. Writes one combined report with the Repeater worklist, decoded parameters, SQLi and XSS possibilities, exposed secrets and cookie issues.

web:xss and web:full submit content to the target and can leave a marked test value on it. Run these workflows only against systems you own or have explicit written permission to test.

Each workflow needs an active Kali Linux machine — the whole toolkit (katana, arjun, nuclei, jwt_tool, gau and more) is pre-installed on it, so the model runs everything live. Rent one in the Virtual Machines section.

Have more than one machine? Add --machine <name> (or -m <name>) to the end of any workflow — e.g. web:sqli https://example.com --machine kali-web — to pin every command to that machine. Without it, your active machine is used.

Every web run saves its full report to a file on your Kali machine (under /root/web/) and the reply gives you the exact path — download it from the machine card on the home page, or fetch it over SSH with your key.