The Quiz Portal That Trusted the URL
EduQuiz is a district science quiz portal built last year by a Class XII volunteer using PHP and MySQL on a ₹200-per-month shared host. About 5,000 students from 40 schools have accounts. The site runs over plain HTTP, stores passwords as unsalted MD5, and issues a password-reset link of the form http://edquiz.example/reset.php?uid=1042&token=md5(uid). The search box places $_GET['q'] directly into a SQL query, and login sessions keep the same session ID before and after authentication. On Friday, a teacher logs in with her own password but lands on another school's dashboard; on Saturday, a student posts a screenshot showing 300 usernames and 32-character password hashes, plus a link that displays any student's name and roll number when the uid value is changed. The district officer wants the portal taken down for a week, but the quiz round closes in 48 hours.
1. Classify at least three weaknesses the incidents reveal and explain what each permits an attacker to do.
Read the worked answer
- Insecure direct object reference (IDOR). The uid parameter is trusted without a server-side check that the logged-in user owns that record. Changing uid displays other students' names and roll numbers, and the teacher's session landing on another dashboard shows the same flaw at account level. An attacker can enumerate records, map schools, and target individuals.
- SQL injection. The search box concatenates $_GET['q'] into a query. An attacker can alter the query to bypass filters or dump tables, which explains how 300 usernames and hashes could be extracted in bulk. Even if the dump came from another flaw, the injection must be treated as a database-compromise route.
- Weak credential protection and transport. Unsalted MD5 is fast to crack with wordlists and rainbow tables, and plain HTTP exposes passwords and session cookies to anyone on the same network. A captured hash can be cracked offline; a captured session can be replayed.
- Predictable reset tokens and session fixation. token=md5(uid) is derivable by anyone who knows the uid, so an attacker can reset another user's password. Keeping the same session ID after login allows session fixation.
The incidents are not one bug but a chain: weak transport, weak storage, and missing authorisation checks.
2. Give a 48-hour remediation plan that lets the round finish, ordered by risk, with the exact change for each weakness.
Read the worked answer
Hour 0–4: stop active exposure. Force HTTPS with a redirect and set HSTS if the shared host allows it; rotate the database password and any host control-panel password. Put the site behind the host's WAF or at least enable rate limiting on login and reset pages.
Hour 4–12: fix authorisation and injection. Add a server-side check in reset.php and every dashboard page: compare the session user ID with the requested uid and reject mismatches. Replace string-built queries with prepared statements and bind parameters; validate q as plain text. Regenerate the session ID on login and set cookies HttpOnly, Secure and SameSite.
Hour 12–24: fix credentials. Invalidate all existing reset tokens and issue random 32-byte tokens with a 30-minute expiry and single use. On next login, force every user to set a new password. Store new passwords with password_hash() using bcrypt or Argon2id; mark the old MD5 values as compromised and never migrate them silently.
Hour 24–48: verify and monitor. Test IDOR by logging in as two students, test the search box with quotes and UNION attempts, review access logs for bulk uid enumeration, and keep the WAF in blocking mode during the quiz close.
This order protects live users first, then closes the data-leak paths, then repairs stored credentials.
3. The district officer asks whether all 5,000 students must be told. Advise, distinguishing confirmed exposure from possible exposure.
Read the worked answer
Confirmed exposure: the 300 usernames and hashes were posted publicly, so those accounts are definitely compromised. The IDOR link exposed names and roll numbers for any uid that was queried, so those records are also confirmed exposed, although the exact list depends on logs.
Possible exposure: SQL injection could have dumped the entire users table, and HTTP traffic could have exposed sessions. The safe assumption is that all 5,000 accounts and the associated personal data are potentially compromised until logs prove otherwise.
Advice: notify all 5,000 users with a forced password reset and a short, factual notice; contact the 300 known accounts separately. Do not publish roll numbers or names in the notice. Inform the district education officer, CERT-In, and the Data Protection Board of India if the breach meets the DPDP Act threshold. Preserve web-server and database logs, because the scope cannot be stated honestly without them. The reasoning is that notification is cheap and reversible, while silence after a public dump destroys trust and may breach legal duties.