Security: Systemic IDOR across messaging, courses, and student records

[lighthousekeeper1212]

Summary

Multiple authorization vulnerabilities allow authenticated users to access/modify resources belonging to other users across the application.

1. Messaging Group IDOR (Critical)

In modules/messaging/Group.php, all group operations (view members, update name/description, delete members) use $_REQUEST['group_id']/$_REQUEST['groupid'] in SQL queries without verifying the current user owns the group.

Affected lines: 101, 122, 816, 822, 840, 865, 880

Fix: Verify group ownership before all operations:

$owner = DBGet(DBQuery("SELECT USER_NAME FROM mail_group WHERE GROUP_ID=..."));
if ($owner[1]['USER_NAME'] != User('USERNAME')) die('Access denied');

2. Course Period IDOR (Critical)

In modules/schoolsetup/Courses.php, DELETE and UPDATE on course periods use $_REQUEST['course_period_id'] without verifying teacher assignment. Lines 273, 312, 967, 1807.

3. Cross-Portal Student Data Access (High)

In modules/messaging/Inbox.php (lines 46-54), teachers can enumerate students/parents of ANY course period by specifying an arbitrary cp_id. No teacher-course verification.

4. Student Record IDOR (High)

In modules/students/Student.php, parent endpoints use $_REQUEST['student_id'] without verifying the parent-student relationship. Parents can read medical info (line 780), enrollment (line 774), and modify records (line 705) for any student.

Root Cause

Authorization checks exist at the module/role level but not at the individual resource level. The system verifies "is this user a teacher?" but not "does this teacher teach THIS course?"

Recommendation

Add per-resource ownership verification before all CRUD operations on groups, course periods, and student records.

---

Found via static analysis by lighthousekeeper1212