🔍 What I Found

During a security assessment of a web application, I discovered a Persistent Cross-Site Scripting (XSS) vulnerability in the registration form. What made this finding more interesting was a twist: the XSS payload was split across two separate input fields – the First Name and Last Name.

This means that an attacker doesn’t even need to insert the full malicious code in one field. By spreading it across two fields, the XSS still works once the user logs in and visits any page where their full name is displayed.

⚠️ What is Persistent XSS?

Persistent (or Stored) XSS is a vulnerability where malicious code is saved on the server and later displayed to users without proper filtering. It’s more dangerous than reflected XSS because the payload stays in the system and is triggered whenever the data is viewed.

💥 Steps to Reproduce

1. Go to the registration page of the target application.
2. Fill in the fields like this:
   • First Name: "><img src=s
   • Last Name: onerror=prompt(document.cookie)>
   • Complete the rest of the form with valid data.
3. Submit the form to create an account.
4. Log in using your new credentials.
5. After login, visit any page that displays your full name (e.g., profile or dashboard).
6. 💣 Boom! The JavaScript executes, showing a popup with your cookies. The XSS was triggered from the combined input.

🧠 Why Is This Dangerous?

• Stealing Cookies: Attackers can capture session cookies.
• Session Hijacking: Attackers may take over the account.
• Site Defacement: Malicious code could change content on the page.
• Spreading Malware: Attackers can embed other harmful scripts.

What’s unique here is the split payload. Many systems check each input separately — but this bypasses filters by injecting half the payload in one field and the rest in another.

🛡️ How to Fix It

1. Input Validation
   • Sanitize all user inputs on both frontend and backend.
   • Use libraries like OWASP ESAPI or frameworks with built-in protections.
2. Output Encoding
   • Encode user data properly when displaying it in the browser.
   • Escape characters like <, >, ", and ' for HTML output.
3. Content Security Policy (CSP)
   • Prevent inline JavaScript with a strict CSP.
   • Example: httpCopyEditContent-Security-Policy: default-src 'self'; script-src 'self'
4. Web Application Firewall (WAF)
   • Deploy a WAF to monitor and block XSS patterns.
5. Cross-Field Testing
   • Always test for combinational payloads that might work across multiple input fields.

🧪 Pro Tip: Why This Case Stands Out

This vulnerability proves that XSS payloads don’t always have to live in one field. When rendered together — like full names on dashboards — they can form a valid script. Attackers often use this trick to bypass traditional filters. Developers and testers must think in joined-output contexts, not just per-field validation.

📝 Final Thoughts

XSS vulnerabilities like this highlight the importance of secure coding practices. Even a small input field can become a serious risk if proper sanitization and encoding aren’t applied. Always treat user input as untrusted — and always test creatively.