ssl/ezXSS

Project Overview

ezXSS is a self-hosted PHP application that helps you find and document blind cross-site scripting during authorized penetration tests and bug bounty engagements. Blind XSS is the kind you can't see in your own browser: you submit a payload into a form, a support ticket, a user-agent header, or an admin-only log viewer, and it fires somewhere you have no direct access to. ezXSS gives you a callback server that catches those firings and records the proof.

The core idea is simple. You host ezXSS, generate a payload that points back to your instance, and plant it in input fields you suspect get rendered elsewhere. When the script executes in a victim context, it phones home and uploads what it saw — the page URL, DOM snapshot, cookies, origin, screenshot, and more. You review all of it in a dashboard instead of guessing whether an injection landed.

The project is written in PHP and backed by a MySQL database, which means it runs comfortably on the same cheap LAMP hosting most testers already have. It is actively maintained and widely used in the security community, with a large star count reflecting that. Use it only against systems you are explicitly authorized to test — a callback tool like this is for sanctioned engagements, not opportunistic injection.

Licensing is permissive (MIT), so you can self-host and modify it for internal tooling without commercial-license friction.

Key Challenges Addressed

The central problem ezXSS solves is visibility. Reflected XSS is easy to confirm because the payload bounces back to you immediately. Blind XSS hides:

• You inject into a field whose output renders in a back-office tool you'll never see.
• The execution may happen hours or days later when a staff member opens a record.
• You have no way to know which of your dozens of injection points actually worked.

ezXSS addresses each of these with a persistent callback channel. Because the payload reports back asynchronously, you capture executions that happen long after you stopped testing. Because every report is tied to the payload that triggered it, you can trace a firing back to the exact field you injected. And because it collects context — DOM, cookies, local storage, screenshots — you get the evidence a triage team needs to accept the finding rather than a bare "it might be vulnerable."

Getting Started

ezXSS expects a PHP environment with a MySQL/MariaDB database and a web server. A minimal install looks like this:

git clone https://github.com/ssl/ezXSS.git
cd ezXSS
# point your web server's document root at this directory
# create an empty MySQL database for ezXSS to use

From there you open the app in a browser and complete the web installer, which writes the database schema and creates your admin account. After login you generate a payload from the dashboard and place it where you want to test.

Sharp edges you'll hit immediately:

• If you serve ezXSS over plain HTTP, modern target sites running on HTTPS will block the mixed-content callback and your payloads will silently fail to report. Put a valid TLS certificate on your instance before you generate any payloads.
• If your callback host is unreachable from the victim's network (internal-only admin panels, egress-filtered environments), the payload executes but never reaches you, and you'll wrongly conclude the field is safe. Confirm your instance is reachable from the public internet first, and note that strictly segmented targets may never be able to call out at all.
• The default payload references your instance hostname directly, so a Content-Security-Policy with a tight script-src will stop it cold. Check the target's CSP header before assuming a non-firing payload means no vulnerability.

Features and Use Cases

The dashboard is where ezXSS earns its keep. Each captured execution becomes a report containing the firing URL, referrer, user-agent, cookies, local and session storage, the rendered DOM, origin, and an optional screenshot of the page as the victim saw it. That payload of context turns a suspected injection into a documented, reproducible finding.

Realistic scenarios where you'd reach for it:

• Testing a customer support ticketing system where agents view submissions in an internal console you can't reach.
• Probing user-agent, referer, or X-Forwarded-For headers that get logged and later rendered in an analytics or admin dashboard.
• Confirming stored XSS in profile fields that only render for moderators reviewing flagged accounts.

It also supports alerting integrations so you get notified the moment a payload fires, which matters when executions can happen days after you plant them. You can customize payloads per test so you can tell which campaign or client an incoming report belongs to.

Ecosystem and Dependencies

ezXSS sits in the LAMP world: PHP plus MySQL/MariaDB plus any standard web server. There's little to integrate beyond that, which is part of the appeal — it doesn't drag in a heavy framework or a build toolchain.

In a tester's broader toolkit it complements payload resources like payloadbox/xss-payload-list for crafting injection strings, and active scanners like s0md3v/XSStrike that hunt reflected and DOM XSS where ezXSS focuses on the blind, asynchronous case. Notification hooks let it feed into whatever alerting you already run during an engagement.

Architectural Overview

The design has three moving parts: a JavaScript payload, a collection endpoint, and a dashboard.

The payload is the code that runs in the victim's browser. When it executes, it gathers DOM and environment data and posts it back. The collection endpoint receives that data, associates it with the originating payload, and writes a report row to the database. The dashboard reads from the database and renders reports, manages payloads, and handles alerting.

This separation matters because the only component that touches hostile environments is the small payload. Everything heavy — storage, review, configuration — stays server-side on infrastructure you control. The server-rendered PHP dashboard keeps the operational surface small and easy to host, which is the right tradeoff for a tool that needs to be stood up quickly per engagement and torn down afterward.

Pros and Cons

Technical pros:

• Purpose-built for blind XSS, which most general scanners miss entirely.
• Rich evidence capture (DOM, cookies, screenshots) that survives triage scrutiny.
• Trivial to self-host on commodity PHP/MySQL hosting.
• Permissive MIT license for internal modification.

Technical cons:

• Requires public reachability and valid TLS, so segmented or egress-filtered targets defeat it.
• PHP/MySQL stack means you own patching and securing the callback server — a poorly secured instance becomes its own liability holding sensitive captured data.
• Captured reports can contain victim cookies and session data, so you must handle and dispose of that data responsibly within engagement scope.

Comparison and Alternatives

Few tools focus specifically on blind XSS callbacks, but several occupy adjacent ground worth comparing.

These tools split into two camps. s0md3v/XSStrike and epsylon/xsser are active scanners that detect reflected and DOM-based XSS during a crawl. payloadbox/xss-payload-list is a payload corpus, not a tool. Only mandatoryprogrammer/xsshunter_express competes head-on with ezXSS as a self-hosted blind XSS callback platform.

The best overall alternative is mandatoryprogrammer/xsshunter_express, because it targets the same blind-XSS callback workflow with mature documentation and an easy self-host path, making it the closest like-for-like swap if you prefer a Node-based stack over PHP.

Conclusion

If you do bug bounty or pentest work and keep missing stored XSS that fires inside admin tooling you can't see, self-host ezXSS and route your payloads through it — the captured DOM and screenshots turn a hunch into an accepted report. Start with the official docs and source at https://github.com/ssl/ezXSS to stand up an instance.

Do not generate payloads from an instance served over plain HTTP: HTTPS targets block the mixed-content callback and your injections will fire without ever reporting, so you'll record false negatives. Do this first — put a valid TLS certificate on your callback host and confirm it's reachable from the public internet before you plant a single payload.