WEBIGniter v28.7.23 - Stored XSS

WEBIGniter v28.7.23 — Stored XSS Vulnerability

Summary: WEBIGniter v28.7.23 contains a stored (persistent) cross-site scripting (XSS) vulnerability in the user creation workflow. The your_name parameter is not properly validated or encoded, allowing an attacker to store HTML/JavaScript in the application database which later executes in other users’ browsers when they view the "users" page in their profile.

Why this matters

• Stored XSS is high-risk because payloads persist on the server and execute in the context of any user's browser that views the affected page.
• An attacker can steal session cookies, perform actions as the victim, or deliver further client-side malware or social-engineering content.
• Even seemingly small fields such as display name or profile name are high-value attack vectors when output is not properly escaped.

Vulnerability details

Item	Value
Product	WEBIGniter
Version	v28.7.23 (reported)
Component	User creation API — your_name parameter
Type	Stored (persistent) Cross-Site Scripting (XSS)
Proof-of-Concept	Store an image tag with onerror handler (e.g. <img src onerror="prompt(8)">) and view "users" page
Severity	High (remediation recommended immediately)

Proof-of-Concept (PoC) — conceptual

The following is a conceptual PoC request pattern to illustrate how an attacker can store a payload. This example uses a POST to the account creation endpoint to submit a malicious display name. Use this only on systems you are authorized to test.

POST /create-account HTTP/1.1
Host: webigniter.example
Content-Type: application/x-www-form-urlencoded

email=attacker%40example.com&password=Passw0rd!&your_name=<img src onerror="prompt(8)">

Explanation: This request submits the your_name parameter containing the payload <img src onerror="prompt(8)">. If the server stores the value and later renders it into the users list without proper encoding, the payload executes when a victim visits the users page.

How the vulnerability typically arises

• Server stores user-supplied HTML/JS verbatim in a database field (e.g., display_name) without sanitization.
• When rendering the users list or profile, the application injects the stored value directly into the HTML page using something like <td><?= $user['name'] ?></td> instead of safely encoding it.
• Browsers parse the HTML and execute any script handlers (e.g., onerror) found in image tags or inline scripts.

Example of vulnerable rendering (server-side)

<td><?php echo $user['your_name']; ?></td>

Explanation: This PHP example simply echoes the stored name into the HTML without escaping. If $user['your_name'] contains HTML or event handlers, browsers will parse and execute them. This is a classic XSS sink.

Safe rendering — immediate fix

<td><?php echo htmlspecialchars($user['your_name'], ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8'); ?></td>

Explanation: htmlspecialchars converts special characters to HTML entities (e.g., < to &lt;, > to &gt;, quotes to entities). This ensures that user-supplied content is rendered as text, not HTML or executable script. Use the UTF-8 charset and include ENT_QUOTES to encode both single and double quotes.

Recommended input validation and encoding strategy

• Primary defense: Output encoding. Always HTML-encode user-supplied data at the point where it enters HTML context.
• Secondary defense: Input validation. Validate and constrain fields where practical (e.g., allow only letters, numbers, spaces, and limited punctuation in display names).
• Contextual encoding: Use the appropriate encoding for the output context — HTML body, attribute, JavaScript, CSS, or URL.
• Escape on output, not input; but perform input normalization and block obviously dangerous content where business logic allows.

Example: validate and normalize a display name (PHP)

// Normalize and validate input before storing
$name = trim($_POST['your_name'] ?? '');

// Allow letters, numbers, spaces, hyphen, underscore, and basic punctuation
if (!preg_match('/^[\p{L}\p{N}\s\-\_\.]{1,80}$/u', $name)) {
    // Reject or fallback to sanitized value
    $name = preg_replace('/[^\p{L}\p{N}\s\-\_\.]+/u', '', $name);
}

// Store $name in DB

Explanation: This snippet trims whitespace and uses a Unicode-aware regular expression to allow letters (\p{L}), numbers (\p{N}), spaces and a small set of punctuation. If the input contains forbidden characters, it either rejects the input or strips them. This approach reduces attack surface while preserving legitimate names.

Additional mitigations (defense in depth)

• Content Security Policy (CSP): Add a strict CSP to mitigate the impact of any injected script. Example header:

  Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self';

  Explanation: CSP can prevent execution of inline scripts and scripts from untrusted sources. Note: CSP is a mitigation, not a replacement for proper encoding.

• HTTPOnly & Secure cookies: Prevent JavaScript from reading session cookies.
• Use framework-provided templating/escaping: Many frameworks automatically escape variables (e.g., Twig, Blade, Django templates). Prefer these over manual concatenation.
• Audit and sanitize stored HTML if rich text is required: If your app allows HTML (e.g., profile bios), use a robust HTML sanitizer (DOMPurify, HTML Purifier) with a strict whitelist.
• Security headers: X-Content-Type-Options, X-Frame-Options, Referrer-Policy to reduce other risks.

Example: CSP + server-side header (PHP)

// Set a restrictive CSP (example)
header('Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'');

Explanation: This header instructs compliant browsers to only load scripts from the same origin, disallow plugin objects, and constrain base-uri. It reduces risk even if an XSS payload is present. Keep in mind CSP must be carefully tested with your application behavior.

How to test and verify remediation

• Recreate the PoC: Submit payloads like <img src onerror="alert(1)"> or encoded variants to the account creation flow, then view the users page. After fixes, these payloads should render as text or be blocked.
• Use security testing tools: Burp Suite, OWASP ZAP, and browser DevTools to inspect DOM and network behavior.
• Automate scanning: Add XSS checks to CI/CD pipelines using dynamic scanners or unit tests that assert stored values are properly encoded when rendered.
• Verify CSP and headers: Confirm security headers are present with correct values via curl or security header checkers.

Responsible disclosure and remediation timeline

• If you discover this issue in a live system, follow responsible disclosure: notify the vendor (WebIGniter) with PoC and remediation guidance, provide time for patching, and avoid public disclosure until a fix is available or coordinated.
• Patch priority: Fix stored XSS quickly — recommend treating as high priority (within days depending on deployment constraints).

References and further reading

• OWASP XSS (Cross Site Scripting) — Prevention Cheat Sheet
• PortSwigger — Cross-site scripting (XSS)
• OWASP Top Ten — A7:2021 Identification and Authentication Failures (and related A3:2021 — Injection)

Quick checklist for developers

• Never insert unescaped user input into HTML — always encode for the output context.
• Use framework/template auto-escaping features where available.
• Validate and normalize inputs according to business rules.
• Use CSP and secure cookie attributes as complementary protections.
• Sanitize stored HTML only with vetted libraries and restrictive whitelists.
• Add automated tests and run dynamic application security scans periodically.