Nine Days to the Bagrut: A School Portal Under Time Pressure

1. Broken access control (IDOR) - the defect that was actually exploited. The server trusts a client-supplied identifier and never checks that the session's user is entitled to that student. A substitute changed a number in the address bar and obtained personal data. Severity critical: unauthorised disclosure of minors' records at scale, with a trivial attack (increment the number). Fix: derive the entitlement server-side - the student list must come from the session's role, or an ownership check must run on every request, denying by default.

2. SQL injection - critical but not yet observed. String concatenation of a raw parameter allows reading and modifying the whole grades table, and depending on the driver may allow stacked statements. Fix: PreparedStatement with bound parameters, plus parse studentId as an integer and reject anything that is not. Parameterisation is the fix; "escaping quotes" is not.

3. Unsalted MD5 - latent, high impact. Fast hashes are brute-forced and rainbow-tabled; identical passwords produce identical digests, so one cracked hash exposes every account sharing that password. Fix: Argon2id or bcrypt with per-user salt. Existing digests cannot be converted, so migrate on next successful login and force a reset for staff accounts.

4. Backups in an unlocked drawer - high impact, low likelihood per day, serious once. A lost USB drive is a reportable data-security incident and is not encrypted in any scenario. Fix: encrypted archives with the key held separately, physical lockup, and a documented custody chain.

5. Over-broad logging - systemic. Full URLs with ID numbers, seven-year retention, readable by every staff member: this violates minimisation and purpose limitation, and turns the log into a second copy of the personal data. Fix: mask query parameters, restrict ACLs, shorten retention to what the Ministry actually requires.

The teacher's access was unauthorised even though it was easy. Authorisation comes from a person's function, not from a server's failure to enforce it. A substitute teacher has no teaching responsibility for the two students whose records she viewed; changing the identifier in the URL was deliberate, not accidental, and continuing to browse after the first unexpected result removes any ambiguity. "The system displayed it" is not a defence - it is a description of the vulnerability.

What she should have done: stop immediately, take no further data, and report the finding in writing the same day to the principal and the school's data security officer, describing exactly what she did and what she saw. Nothing in this scenario requires her to exploit further to "prove" it; one demonstration plus a description is sufficient evidence.

The staff-room conversation is a second, independent failure. Repeating grades to colleagues is disclosure of personal data to people with no need to know, and it also destroys the traceability of the incident.

Legal frame. Student grades are personal data in a database held by the school, which is the database owner under Israel's Protection of Privacy Law and the Data Security Regulations. That regime requires defined access permissions by role, documentation, an appointed data security officer, and prompt handling of incidents - including an assessment of whether notification is required. The teacher may have committed an access offence as well as a disciplinary breach; the principal's "we will fix it in July" is a documented decision to leave a known, actively exploitable high-severity defect open during the highest-traffic period of the year, which is exactly the kind of decision a regulator or an auditor examines afterwards. The correct response is to act promptly and proportionately, record the risk decision, apply compensating controls, and consult the data security officer rather than deciding alone.

What nobody in the story did: treat the incident as an incident. No report, no log review, no notification assessment, no record. That absence is itself the governance failure.

Fix now - hours 1–8 (highest risk, lowest cost):

1. PreparedStatement plus integer parsing on report.jsp and on every other endpoint that takes an identifier (2–3 hours). One-line cause, one-line fix, enormous reduction in blast radius.
2. Server-side authorisation: a check that the session's user may see the requested student, denying by default, applied to the same endpoints (3 hours). This closes the hole that was actually used.
3. Log hygiene: mask ID numbers in new log lines, restrict the share to the data security officer and the sysadmin, cut retention from seven years to the Ministry minimum (1 hour).
4. Backup custody: stop copying to the drawer. Either encrypt the archive with a key held by the principal, or suspend the nightly USB copy for nine days and take one manual encrypted backup (1 hour).

Fix now - hours 9–12: an alert that flags a single session fetching an anomalous number of distinct student IDs, and a short written risk memo to the principal listing what is closed, what is open, and what the residual risk is. The memo is part of the deliverable, not paperwork.

Defer, with a dated plan: password hash migration to Argon2id with rehash-on-login (do not force 4,200 resets during exam week - start with the 380 staff accounts), the full endpoint audit, an access-control matrix by role, and the incident assessment with the data security officer.

Refuse: a framework migration, a rewrite of the portal, or a new authentication scheme in nine days. Any of those converts a contained risk into an outage during the Bagrut, which is the one outcome worse than the current state.

Say out loud what is not fixed. "We patched the two exploitable defects, restricted the data copies and made the logs safe; password hashing remains weak until July and here is the compensating control." An honest residual-risk statement is what makes this a professional judgement rather than a gamble.