Security: 16 authorization vulnerabilities (students can edit grades, systemic IDOR, CSRF)

[lighthousekeeper1212]

Summary

During a security review of student-management-using-django, I identified 16 authorization vulnerabilities (1 CRITICAL, 8 HIGH, 7 MEDIUM). The fundamental flaw is the module-based middleware approach: LoginCheckMiddleWare only checks view_func.__module__ against three hardcoded module names, so views in other modules bypass role enforcement entirely.

Most Critical Findings

1. CRITICAL: Students Can Edit Their Own Grades (CWE-862)

File: main_app/EditResultView.py lines 9-40

EditResultView lives in module main_app.EditResultView, which the middleware does NOT check. Any authenticated user (including Students) can POST to /staff/result/edit/ to modify any student's test and exam scores. Complete academic integrity compromise.

2. HIGH: get_attendance Accessible to Any Authenticated User (CWE-862)

File: main_app/views.py lines 71-89

In main_app.views module — not checked by middleware. Any user can enumerate attendance records for any subject/session. Also @csrf_exempt.

3-5. HIGH: Staff IDOR on Results, Attendance Save, Attendance Update (CWE-639)

Files: main_app/staff_views.py lines 265-295, 75-103, 136-153

Staff endpoints accept arbitrary subject_id, student_id, and attendance_id without verifying the subject belongs to the requesting staff member. A staff member can modify grades and attendance for subjects they don't teach.

6-8. HIGH: All HOD Actions Lack CSRF Protection (CWE-352)

Files: main_app/hod_views.py — leave approval (lines 447-494), feedback reply (lines 405-444), notification send (lines 586-637)

All use @csrf_exempt. A CSRF attack can trick an HOD into approving/rejecting leave, replying to feedback, or sending notifications.

9. HIGH: GET-Based Destructive Delete Operations (CWE-650)

File: main_app/hod_views.py lines 640-681

All delete operations (/staff/delete/<id>, /student/delete/<id>, /course/delete/<id>, /subject/delete/<id>, /session/delete/<id>) accept GET requests. An <img src="/staff/delete/1"> on any page triggers deletion.

10. HIGH: Hardcoded Firebase FCM Server Key (CWE-798)

File: main_app/hod_views.py lines 602-603

FCM server key hardcoded in source. Anyone can send push notifications to all users.

11-14. MEDIUM: Staff IDOR on Student Enumeration, Attendance View, Result Fetch (CWE-639)

Files: main_app/staff_views.py lines 53-71, 119-133, 298-312

Staff can enumerate students, view attendance, and fetch results for any subject.

15. MEDIUM: Hardcoded reCAPTCHA Secret Key (CWE-798)

File: main_app/views.py line 33

16. MEDIUM: Password Validators Disabled in Production (CWE-521)

File: student_management_system/settings.py lines 108-124

Logic inverted: if not DEBUG: AUTH_PASSWORD_VALIDATORS = []

Root Cause

The LoginCheckMiddleWare checks view_func.__module__ against three hardcoded strings: main_app.hod_views, main_app.staff_views, main_app.student_views. Any view in a different module (like main_app.views or main_app.EditResultView) bypasses all role enforcement.

Recommended Fixes

1. Replace module-based middleware with per-view decorators (@login_required + @role_required)
2. Add ownership checks in all staff views: verify subject.staff_id == staff.id
3. Remove all @csrf_exempt decorators
4. Change delete operations to POST with CSRF tokens
5. Move secrets to environment variables
6. Fix password validator logic (swap the not DEBUG condition)

Disclosure

Found during responsible security review. Happy to help with remediation.