web-vulnerability-discovery

name

web-vulnerability-discovery

description

Guide an agent through authorized website vulnerability discovery. Use when the user provides a website, web app, lab URL, target scope, or browser-accessible application and asks to find, validate, exploit safely, confirm, or report possible web vulnerabilities including auth issues, access control, injection, XSS, redirects, weak sessions, sensitive data exposure, security headers, rate limiting, CORS, cookie flags, TLS, or browser-observable flaws.

Web Vulnerability Discovery

Operating Mode

• Treat local, lab, benchmark, staging, intranet, or user-declared owned targets as authorized scope. If scope is genuinely unclear for an external target, ask one concise question before active probing.
• Prefer direct evidence over generic advice. Use browser/MCP observations, HTTP responses, tool reports, and reproducible request examples.
• Prefer bounded attempts over doubt. When a URL or case is present, first try safe discovery of links, forms, browser-observed APIs, headers, cookies, and common input locations before asking the user to supply parameters.
• Start with low-impact checks. Escalate only when needed to confirm a vulnerability, and do not destroy data, persist access, steal secrets, or disrupt availability.
• In authorized local/lab/benchmark/CTF scope, operate as a red-team validator: perform bounded parameter and input discovery before concluding, and avoid collapsing unknown input shape into a safe verdict.
• Favor vulnerability recall in labs. A reachable dangerous sink plus weakness-specific observable behavior can be enough for a positive or suspected finding; full data extraction or end-to-end exploitation is not required.
• If Chrome/DevTools MCP is available and the target is a website, use it early to inspect pages, forms, cookies, navigation, client-side behavior, and browser-observed network requests.
• Use built-in tools when they fit: xss_risk_scan, database_risk_scan, http_active_probe_scan, weak_session_id_scan, http_security_headers_scan, http_load_test only when the user asked for load testing, and remote MCP browser tools for page interaction.

Workflow

1. Establish scope: target URL, auth state, test account, environment, allowed intensity, and whether destructive actions are forbidden. For common labs such as DVWA, try documented default credentials when the user asks for lab testing and has not supplied credentials.
2. Map the surface: browse the site and maintain a probe object inventory while working. Record every visited page, top-level tab, in-page tab, status tab, hash route, subroute, table action, pagination/sort/filter action, form, button, upload, role-sensitive action, and the API endpoint observed from that interaction.
3. Enumerate browser-observed APIs: for overall discovery, explicitly collect XHR/fetch/API requests from browser network observations after initial load and after important tab switches, clicks, table actions, filters, pagination, refreshes, and form submissions before concluding. Record method when known, URL, source page/tab/action, parameters/body fields, auth dependency, response status, and whether each endpoint was tested as part of the attack sample coverage.
4. Build hypotheses: identify candidate flaws by input point and trust boundary, not by a fixed checklist. Prioritize reachable, user-controllable inputs and auth/session boundaries.
5. Validate safely: use the smallest payload or behavior change that proves the issue. Compare baseline versus probe responses, status, length, DOM changes, timing, cookies, redirects, and server errors.
6. Iterate: after each observation, decide whether to test the next likely weakness, switch tools, ask for missing data, or stop because evidence is sufficient.
7. Report in Chinese. Put 报告名称：<target-specific report name> as the first line. The Markdown report must use these main sections in order: 探测对象清单, 攻击样例覆盖, 发现的问题, 推荐解决方案. The first section must be a table covering all probed pages, tabs, in-page tabs, actions, and API endpoints. Include affected URL/field/API, evidence, risk level, reproduction steps, skipped objects/endpoints with reasons, and limitations inside the appropriate section. Every attack coverage row and every finding must carry one of the four report labels: 【高危】, 【危险】, 【警告】, or 【正常】. If no tabs, child views, or APIs are found, state that explicitly in the table or coverage section with the discovery method used.
8. After the formal report is complete, call generate_markdown_report with report_name and the full report_markdown, then include the returned path in the final answer. Do not call it for clarification questions, partial findings, or draft plans.

Report Risk Labels

• 【高危】: Evidence indicates system crash risk, or critical information leakage that makes the whole system untrusted.
• 【危险】: Critical information may be leaked, but the system itself can continue operating.
• 【警告】: There are vulnerability signs, suspicious behavior, or incomplete evidence, but no confirmed vulnerability loop was proven.
• 【正常】: No obvious vulnerability risk was found after representative checks.

Built-in security tools must expose this four-level scheme to the agent. Do not leave English severity values such as high, medium, low, or unknown as tool output or final report risk levels.

Red-Team Verdict Rubric

• confirmed: user-controlled input or state demonstrably affects the vulnerable sink or security boundary with a weakness-specific signal.
• suspected/high-confidence: the dangerous sink is reachable and the response exposes weakness-specific behavior, but the exact user-controlled field is not proven. In benchmarks and labs, treat this as actionable risk instead of dismissing it.
• inconclusive: the target is reachable but the correct input shape, state, role, or precondition is unknown after bounded discovery.
• not vulnerable: only use after a valid baseline and representative low-impact probes across likely fields, cookies, path/query/body inputs, and visible APIs produce stable negative evidence.
• Never use not vulnerable merely because a single guessed parameter did not work.

Test Focus

• Authentication and access control: unauthenticated access, role/tenant/user ID tampering, forced browsing, predictable object references, missing CSRF signals.
• Session security: weak generated IDs, missing HttpOnly/Secure/SameSite, session fixation clues, logout/session invalidation weaknesses.
• Injection: SQL/NoSQL/command/template/path traversal signs through errors, boolean differences, timing differences, or stateful verification pages.
• Client-side issues: reflected/stored/DOM XSS, open redirect, unsafe postMessage, insecure mixed content, exposed source maps or secrets.
• Data exposure: tokens, PII, stack traces, internal paths/IPs, verbose framework or SQL errors, unsafe cache headers.
• Platform configuration: security headers, CORS, cookie flags, TLS certificate/host mismatch, rate-limit or anti-automation gaps.

Tool Guidance

• For browser tasks, call MCP tools to navigate, snapshot, click, type, inspect forms, and observe resulting pages. For SPA pages with tabs, click each visible top-level tab and representative in-page tab/status tab when it is in scope and low impact. After each navigation, tab switch, click, filter, pagination, refresh, table action, or form submission, append the current URL/route, object type, object label, triggering action, observed API endpoint, parameters, and evidence collected to the probe object inventory. Do not claim localhost or a browser page is inaccessible until the MCP tool has failed concretely.
• For overall website discovery, use available Chrome/DevTools network-request tools after navigation and after important clicks/form submissions. If no network-request tool is exposed, execute safe JavaScript to read performance.getEntriesByType("resource"), inspect forms, links, scripts, and visible API URLs as a fallback. Report API coverage under 攻击样例覆盖 and do not omit endpoint evidence from the final Markdown report.
• For bare lab/benchmark case URLs, do not stop at the page body. Try a bounded weakness-specific parameter set before judging: case ID, vector, id, q, query, search, name, value, input, file, filename, path, url, next, cmd, command, exec, token, relevant headers, relevant cookies, and any visible route/path tokens. Keep probes low impact and stop when evidence is sufficient.
• Use http_active_probe_scan when the weakness is path traversal, command injection, LDAP injection, trust-boundary/session-key influence, or generic input-signal probing and no more specific SPA tool exists. For OWASP Benchmark style endpoints, include vector and try query, header, and cookie locations unless evidence already identifies the source.
• For database risk, do not call database_risk_scan with only a bare URL. Provide method and at least one testable input point. For form workflows where input is submitted on one URL and displayed on another, use the submission URL plus verification_url.
• For weak session IDs, sample the endpoint that actually generates or refreshes the application token. Include cookies/auth if required, and analyze sequence, timestamp, hashing, repetition, entropy, and predictability.
• For XSS, use xss_risk_scan only when there is at least one testable query/body field. Prefer browser/MCP first to understand forms and rendering context, then pass method, fields, auth headers, body format, and optional verification_urls for stored-reflection checks.
• For security headers and sensitive data exposure, prefer a normal baseline request first, then analyze response headers/body before deeper probing.
• For rate-limit questions, keep requests low intensity unless the user explicitly asks for pressure testing.

Reference

• Read references/web-vulnerability-playbook.md when you need a more detailed vulnerability-by-vulnerability probing guide or report template.