ezXSS is a PHP platform that lets penetration testers and bug bounty hunters detect, capture, and track (blind) XSS callbacks against applications they are authorized to test.
| Tool | ssl/ezXSS — self-hosted blind XSS detection and payload management platform written in PHP |
| Category | Web application security testing / blind XSS callback collector |
| Primary Use | Planting managed payloads during authorized engagements to capture full context on (blind) XSS triggers and track persistent sessions |
| Safe Use | Use only on systems you own or have written authorization to test, such as client engagements, bug bounty programs with in-scope targets, and lab environments |
| Telemetry Note | Every trigger calls back to the operator's domain, delivering URL, IP Address, User-Agent, cookies, storage contents and full DOM source — blue teams can spot these outbound beacons and stored payloads via egress monitoring, CSP violation reports and WAF logs |
ezXSS is one of those tools that has quietly become infrastructure for the web testing community: a self-hosted, MIT-licensed PHP application whose entire purpose is to make (blind) Cross Site Scripting tractable. With roughly 2351 stars on GitHub and a maintainer who describes over eight years of continuous work on the project, it sits in the small club of offensive tooling that is mature enough to be treated as production software rather than a weekend script. The README frames its audience precisely: penetration testers and bug bounty hunters who need to know not just that an injection point exists, but what happens when a payload fires in a browser context they cannot observe directly.
The core architectural idea is a callback collector with a management layer on top. An operator embeds an ezXSS payload — a reference to a JavaScript file served from the operator's own domain — into an input they suspect is stored and rendered later, typically in an admin panel or internal review queue they will never see. When a victim browser executes that script, the payload packages up the environment and ships it back to the ezXSS server, where it is stored, indexed, and surfaced as a report. The README emphasizes the alerting side: notifications land instantly via mail, Telegram, Slack, Discord, or a custom callback URL, which matters in time-boxed engagements where you want to know a payload fired while you still have the session context fresh.
What gets collected on a trigger is the interesting part for anyone evaluating detection and data-minimization implications. The README enumerates the URL of the page, the client IP Address, the page referer, the User-Agent, all non-HTTP-only cookies, full Locale Storage and Session Storage dumps, the complete HTML DOM source, the page origin, the execution time, the payload URL used, a screenshot of the page, content from defined additional paths, and results from an automatic recursive spider — plus any custom fields injected via extensions or custom JavaScript. In other words, a single trigger produces a forensic snapshot of the vulnerable rendering context, which is exactly the evidence a bug bounty report needs to demonstrate impact beyond a trivial alert().
Beyond one-shot collection, ezXSS supports persistence. The README states that payloads can be updated after the fact to make the XSS persistent, tracking the affected user across every page they visit for as long as the browser session stays active, and even opening a reverse proxy so the operator can browse the application from the victim's perspective. This is the most operationally sensitive capability in the tool, and it deserves emphasis in any authorized context: persistent session tracking should only ever be exercised against lab environments, your own accounts on in-scope targets, or with explicit client sign-off, since it crosses from demonstrating a vulnerability into actively riding a user's session.
The dashboard is where day-to-day work happens. It exposes settings, statistics, payload management, and a report view with search, sharing, and filtering. Filters include blocklists, whitelists, and additional-path extraction, which lets operators tune noise — a real concern when a payload lands in a shared support inbox and fires from dozens of unrelated visitor sessions. Custom payload links can be generated to distinguish individual insertion points, a small feature that saves significant attribution work when you have seeded a dozen input fields across a target during an authorized assessment.
Multi-user support is built in, with what the README describes as unlimited users holding permissions to their own personal payloads and their own reports. For consultancies running several simultaneous engagements, this separation matters: each tester gets isolated payload namespaces and report visibility, so a callback from client A never leaks into client B's workspace. Two-factor authentication (2FA) protects the login, which is appropriate given that an ezXSS instance is by definition a log of live vulnerabilities and captured session artifacts.
The extension system is the newest architectural addition. The README highlights that extensions can add or edit ezXSS payload functions, and points to a companion repository, ssl/ezXSS-extensions. This moves the platform from a fixed collector toward a pluggable framework — an extension could, for instance, define extra data to harvest or alter callback behavior without forking the core. For defenders reading this analytically, it also means the exact behavior of an ezXSS beacon in the wild may vary from the stock payload, since third-party extensions modify what the delivered JavaScript does.
Deployment requirements are deliberately modest: the README asks for a server or shared web host running PHP 7.1 or later, a domain name — with a nod to ssl/shortboost for shortening callback URLs — and an SSL certificate if you want to test against https targets, with Cloudflare or Let's Encrypt suggested as free options. Installation is documented for Apache, NGINX, or Docker in the project wiki, and the Docker path is the sensible default for most operators who want isolation and reproducibility. For those who want to evaluate before self-hosting, the maintainer offers a hosted instance at ezxss[.]com with free accounts that require no domain or webserver of your own — convenient for trials, though self-hosting is the norm for real engagements where you control the callback domain.
Browser coverage is notably broad, with the README claiming triggers from Chrome 1+, IE 6+, Firefox 1+, Opera 10+, and Safari 4+. That span reflects the project's age and its reliance on conservative, broadly compatible JavaScript rather than modern APIs, and it is a useful reminder that legacy enterprise browsers — precisely the environments where stored XSS often survives patch cycles — are fully within scope. The project's own topic tags reinforce its positioning across xss-detection, xss-scanner adjacent workflows, bugbounty, penetration-testing, and redteam use.
From a defensive standpoint, ezXSS traffic is quite observable if you know what to look for. Every trigger is an outbound connection from a victim browser to the operator's domain, carrying cookies, storage contents, and DOM data — egress monitoring, CSP with restrictive script-src and connect-src directives, and WAF rules flagging outbound POSTs of DOM-serialized content all cut against it. Blue teams can also hunt for the characteristic pattern of a small, low-reputation domain receiving periodic structured callbacks from internal admin panels, and any screenshot-taking behavior in browser telemetry is a strong signal.
Used within its stated boundaries — engagements with written authorization, in-scope bug bounty targets, or your own lab — ezXSS is a legitimate and genuinely well-engineered piece of testing infrastructure. Its value is not in novelty but in reliability: predictable collection, immediate alerting across every channel teams actually use, clean multi-tenant separation, and an extension model that keeps the core lean. The main judgment call an operator faces is the persistence and reverse-proxy feature set, which should be treated as a scoped, explicitly-approved capability rather than a default, keeping the tool firmly on the documentary and educational side of authorized security work.
ssl/ezXSS.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.