diff --git a/docs/OnTrack/Fix Vulnerabilites/IDOR.md b/docs/OnTrack/Fix Vulnerabilites/IDOR.md new file mode 100644 index 000000000..294543eb8 --- /dev/null +++ b/docs/OnTrack/Fix Vulnerabilites/IDOR.md @@ -0,0 +1,100 @@ + +# AppAttack x OnTrack Vulnerability review + +## Team Member Name + +| Name | Student ID | +| ----------------------- | ---------- | +| Atharv Sandip Bhandare | 223650012 | + +--- + +## Vulnerability Details + +### Vulnerability Name + +Insecure Direct Object Reference (IDOR) – Unauthorized Access to Staff Information + +### Vulnerability purpose + +- This vulnerability targets Insecure Direct Object References (IDOR), where a low level user entity, such as a student, can access high level entity such as internal staff information through insufficient authorization checks on the server. +- This vulnerability is made possible due to insufficient access control implementation on the backend, such as: + - The API endpoint handling unit information does not perform role-based access control (RBAC) checks to differentiate between students and staff. + - Sensitive fields like `main_convenor_id` and `tutor_id` are included by default in the API response, regardless of the user's role. + - The system relies only on `authentication (whether the user is logged in)`, but fails to apply proper authorization filters to control what different types of users should see. + - Lack of `object-level data filtering` or `data minimization practices` results in unnecessary information disclosure. + +### Affected Assets and Interaction Points +- Affected Assets: + - Based on my understanding, the following backend files are involved in exposing unauthorized staff information and are part of the vulnerable assets: + +| File | Why It Is Affected | +| --- | --- | +| `doubtfire-api/app/api/entities/minimal/minimal_user_entity.rb` | Handles minimal user serialization; insufficient filtering led to staff identifiers being exposed. | +| `doubtfire-api/app/api/entities/unit_entity.rb` | Constructs the Unit API response; embeds sensitive staff IDs like `main_convenor_id` directly into API outputs without access control. | +| `doubtfire-api/app/api/entities/unit_role_entity.rb` | Handles serialization of staff roles within a unit; vulnerable to leaking tutor information linked to students without authorization checks. | +| `doubtfire-api/app/api/entities/user_entity.rb` | Manages user-level details; includes sensitive attributes when responding to certain requests. | +| `doubtfire-api/app/api/unit_roles_api.rb` | API controller that processes staff role information; lack of proper authorization checks results in potential data exposure. | +| `doubtfire-api/app/api/units_api.rb` | Main controller serving Unit information; sends out staff IDs embedded within the unit payload even for student-level users. | + +- Interaction Points: + - API Endpoint: `Get /api/units/:id` + - When any user (even a student) queries unit information, the API response contains internal fields like main_convenor_id, tutor_id, exposing unauthorized mapping between students and staff. + +- Tools Used to Expose Vulnerability: + - Postman: Used to craft custom API requests and view raw JSON responses revealing sensitive internal IDs. + - Burp Suite: Can be used for intercepting and analyzing insecure API responses systematically. + +## Vulnerability outcomes + +### Outcomes +| Outcome | Impact on OnTrack | +| ------------------------------- | ----------------- | +| Unauthorized Viewing of Staff Assignments | Students could view staff assigned to units without permission, breaching confidentiality within academic operations. | +| Exposure of Staff Internal Roles | Students could infer privileged internal staff roles (e.g., convenors, tutors), disrupting academic hierarchies and workflows. | +| Potential Misuse of Staff Information | Exposed staff IDs could be used to impersonate staff members in unit activities, extension requests, or academic disputes. | +| Degradation of Access Control Integrity | Trust in OnTrack’s role-based access control (RBAC) system could diminish, undermining secure separation between student and staff data. | +| Increased Internal Support Burden | Staff would require additional support to manage privacy breaches, leading to administrative overhead and possible process changes. | + +Vulnerability Exposure: ![data access](Resources/staff_data_before.png) +- In the above screenshot, using Postman, a student user `(student_1)` successfully accessed sensitive staff information for a unit by sending a GET request to the endpoint +`/api/units/1`. +- The API response reveals sensitive details of staff, including their user IDs, email addresses, first and last names, usernames, and nicknames: all without appropriate authorization checks and improper data sanitization. +- This demonstrates a clear violation of access control policies where non-privileged users (students) can retrieve confidential staff data. + +## My Approach to Resolving the Vulnerability +To address the identified IDOR vulnerability in the OnTrack system, I followed a structured and investigative approach: +1. Initial Vulnerability Verification: + - Using `Postman api`, I simulated a GET request to the vulnerable endpoint `/api/units/:id` with a student user's credentials (student_1), successfully exposing sensitive staff information (emails, full names, usernames) associated with the unit. +2. Review of the Vulnerability Report: + - Carefully reviewed the penetration testing report again to fully understand the scope and impact, which emphasized that staff-level information was improperly accessible to student-level users. +3. Identification of Affected Assets: + - Analyzed the backend repository (doubtfire-api) to identify relevant files that potentially exposed staff-related information without access control. +4. Understanding How the Vulnerability Was Made Possible: + - Investigated serialization logic inside the above entity and API files (specified in the outcomes section). + - Found that sensitive staff data fields were included in the API responses without verifying user roles or privileges. + - Lack of role-based access control (RBAC) or conditional serialization was the root cause. +5. Designing the Remediation Strategy + - Planned to implement Role-Based Access Control (RBAC) by restricting the fields returned based on the user's role (Student vs Staff/Admin). + - Decided to refactor serialization methods in entities to exclude or sanitize sensitive staff attributes for unauthorized users. + - Added a new helper (role_helpers.rb) to centralize RBAC logic for consistent access decisions across APIs. +6. Implementation of Fixes: + - Modified serialization logic in all affected entity files to conditionally expose sensitive data based on user roles. + - Updated controller responses to ensure students receive only non-sensitive information. + +## Vulnerability Validation +`Note: Before starting OnTrack, make sure to be on 8.0.x branch and you have Postman Api installed in your system` +1. Pull my work +2. Start OnTrack locally and open your Postman Api alongside: ![setup](Resources/step_1.png) +3. Now make a login `POST` request to the endpoint `http://localhost:3000/api/auth` and make sure to pass the credentials `username` and `password` as per the below screenshot then hit on `send`: ![step_2](Resources/step_2.png) + - `201 Status` created means you have successfully made a request to the desired endpoint. + - Now, make sure to copy the `auth_token`, it will be used later to make a `GET` request to the frontend. +4. Now, make a `GET` request to the endpoint: `http://localhost:4200/api/units/1`, but make sure you have your headers(username, auth-token, content-type) properly setup as per the below image, here auth_token you can access it from step 3: ![step_4](Resources/step_4.png) +5. Now, if you scroll down through the response section, and if you don't see any `json object` like below: ![check](Resources/staff_data_before.png) + - It means sensitive staff data has been sanitized and proper Role-Based Access Control (RBAC) has been successfully implemented. + +## Important Section: +- After applying the fix to sanitize unauthorized staff information from the, it was observed that the OnTrack frontend login functionality is impacted. +- Specifically, no users (Students, Tutors, Admins, Convenors) are currently able to successfully log in, and a `419 No authentication details provided` error is thrown. +- This indicates that the frontend is tightly coupled with previously exposed staff object data, and further backend/frontend adjustments are required to properly align authorization models with user session handling. +![error](Resources/error.png) \ No newline at end of file diff --git a/docs/OnTrack/Fix Vulnerabilites/Resources/POST_login_req.png b/docs/OnTrack/Fix Vulnerabilites/Resources/POST_login_req.png new file mode 100644 index 000000000..eced13b28 Binary files /dev/null and b/docs/OnTrack/Fix Vulnerabilites/Resources/POST_login_req.png differ diff --git a/docs/OnTrack/Fix Vulnerabilites/Resources/error.png b/docs/OnTrack/Fix Vulnerabilites/Resources/error.png new file mode 100644 index 000000000..64304d518 Binary files /dev/null and b/docs/OnTrack/Fix Vulnerabilites/Resources/error.png differ diff --git a/docs/OnTrack/Fix Vulnerabilites/Resources/staff_data_before.png b/docs/OnTrack/Fix Vulnerabilites/Resources/staff_data_before.png new file mode 100644 index 000000000..800375381 Binary files /dev/null and b/docs/OnTrack/Fix Vulnerabilites/Resources/staff_data_before.png differ diff --git a/docs/OnTrack/Fix Vulnerabilites/Resources/step_1.png b/docs/OnTrack/Fix Vulnerabilites/Resources/step_1.png new file mode 100644 index 000000000..b7027bfd0 Binary files /dev/null and b/docs/OnTrack/Fix Vulnerabilites/Resources/step_1.png differ diff --git a/docs/OnTrack/Fix Vulnerabilites/Resources/step_2.png b/docs/OnTrack/Fix Vulnerabilites/Resources/step_2.png new file mode 100644 index 000000000..af10d8a89 Binary files /dev/null and b/docs/OnTrack/Fix Vulnerabilites/Resources/step_2.png differ diff --git a/docs/OnTrack/Fix Vulnerabilites/Resources/step_3.png b/docs/OnTrack/Fix Vulnerabilites/Resources/step_3.png new file mode 100644 index 000000000..da6a2e5bc Binary files /dev/null and b/docs/OnTrack/Fix Vulnerabilites/Resources/step_3.png differ diff --git a/docs/OnTrack/Fix Vulnerabilites/Resources/step_4.png b/docs/OnTrack/Fix Vulnerabilites/Resources/step_4.png new file mode 100644 index 000000000..018893e08 Binary files /dev/null and b/docs/OnTrack/Fix Vulnerabilites/Resources/step_4.png differ