IDOR Vulnerability documentation ready to commit

[atharv02-git]

• Note: You can find a detailed technical documentation here: technical-documentaion

Description

• This Pull Request addresses the Insecure Direct Object Reference (IDOR) vulnerability found in the OnTrack system, which allows unauthorized access to sensitive staff information by students.
• The vulnerability was identified in the API response for unit information, where sensitive staff data (like tutor and convenor IDs) was exposed without proper authorization checks.

Fixes # (issue)

Type of change

• The implementation introduces Role-Based Access Control (RBAC) to ensure sensitive staff information is only exposed to authorized users (Admins and Staff).

• The backend files have been updated to apply conditional serialization of sensitive data based on the user’s role.

• Bug fix (breaking change which fixes an issue)

• Documentation (update or new)

How Has This Been Tested?

1. Login with a Student Role:

• Used Postman to simulate a POST request to authenticate a student user.
• Retrieved an auth_token to be used in the subsequent API requests.

2. API Request to /api/units/:id

• Sent a GET request to the vulnerable endpoint /api/units/:id.
• Ensured that sensitive staff data (e.g., tutor and convenor IDs) was excluded from the response.

3. Validation

• If the GET request response does not include sensitive data like staff emails, names, or IDs, it indicates that the RBAC and sanitization fixes are successfully applied.

Testing Checklist:

• Tested in latest Chrome

[lachlan-robinson]

Hi @atharv02-git ,

Strengths of the report:

• This documentation identifies the issue and explains the technical cause.
• The affected components are identified.
• Appropriate tools have been considered for testing the vulnerability (Postman & Burp)
• The remediation is well thought out and clearly addresses the vulnerability.
• Validation instructions are clear and should be easily repeated by reviewers.

Possible improvement:

• The coupling between the vulnerable api and the front-end needs to be explored further to identify what actions must be taken to ensure the issue can be resolved while maintaining app functionality.

Overall, this is a well-thought-out report.

[theiris6]

Your RBAC implementation fixes the security vulnerability but breaks authentication, as shown by the user-icon component errors in your screenshot. The frontend clearly depends on certain staff data fields that are now being filtered out.
I recommend:

• Preserving essential fields needed for UI components while still removing truly sensitive data
• Using a more surgical approach that filters specific sensitive fields rather than entire objects
• Adding conditional logic to return different data structures based on authentication context vs general data access

[ibi420]

Following your provided documentation, I have confirmed the presence of an Insecure Direct Object Reference (IDOR) vulnerability. This weakness permits unauthorized access to sensitive staff data via the API due to inadequate security measures. Using Postman, I successfully replicated this vulnerability by authenticating a student user, obtaining an auth_token, and subsequently executing a GET request to the vulnerable endpoint "/api/units/:id". Although the implemented Role-Based Access Control (RBAC) system mitigated the issue, it inadvertently disrupted frontend login functionality. While RBAC offers utility, migrating to Attribute-Based Access Control (ABAC) is recommended. ABAC's ability to assign attributes such as "is_student" and "is_tutor" would provide more granular access control and long-term maintainability by directly linking access permissions to specific attributes. Your documentation effectively outlines the vulnerability and its exploitation as an authentication mechanism, highlighting a significant security risk. Thank you for the opportunity to review your work.

[atharv02-git]

Following your provided documentation, I have confirmed the presence of an Insecure Direct Object Reference (IDOR) vulnerability. This weakness permits unauthorized access to sensitive staff data via the API due to inadequate security measures. Using Postman, I successfully replicated this vulnerability by authenticating a student user, obtaining an auth_token, and subsequently executing a GET request to the vulnerable endpoint "/api/units/:id". Although the implemented Role-Based Access Control (RBAC) system mitigated the issue, it inadvertently disrupted frontend login functionality. While RBAC offers utility, migrating to Attribute-Based Access Control (ABAC) is recommended. ABAC's ability to assign attributes such as "is_student" and "is_tutor" would provide more granular access control and long-term maintainability by directly linking access permissions to specific attributes. Your documentation effectively outlines the vulnerability and its exploitation as an authentication mechanism, highlighting a significant security risk. Thank you for the opportunity to review your work.

Hey @ibi420, This documentation that I outlined was a week before my actual implementation and it highlights my approach to what my initial plan was to fix the vulnerability, but later as I found out that the changes I made in multiple files (which I have highlighted in the document) to implement RBAC it disrupted the functionality of making changes at the backend broke the connnectivity with frontend and hence I had to come up with a new solution to fix the issue with as many minimal changes as I can, then I realised the data exposure occurred in the serializer layer, particularly in the Entities::UnitEntity class.
These entity class defines how backend models are converted into API JSON responses, and they were exposing sensitive fields attribute without checking user roles. The UnitEntity class is responsible for deciding what fields of the Unit model are exposed. Fields such as :staff, :main_convenor_id, and :overseer_image_id were conditionally exposed but lacked proper role validation. And I have implemented a new fix with as many minimal changes as I can for which the frontend and both backend works well. You can find the change here

[ibi420]

Following your provided documentation, I have confirmed the presence of an Insecure Direct Object Reference (IDOR) vulnerability. This weakness permits unauthorized access to sensitive staff data via the API due to inadequate security measures. Using Postman, I successfully replicated this vulnerability by authenticating a student user, obtaining an auth_token, and subsequently executing a GET request to the vulnerable endpoint "/api/units/:id". Although the implemented Role-Based Access Control (RBAC) system mitigated the issue, it inadvertently disrupted frontend login functionality. While RBAC offers utility, migrating to Attribute-Based Access Control (ABAC) is recommended. ABAC's ability to assign attributes such as "is_student" and "is_tutor" would provide more granular access control and long-term maintainability by directly linking access permissions to specific attributes. Your documentation effectively outlines the vulnerability and its exploitation as an authentication mechanism, highlighting a significant security risk. Thank you for the opportunity to review your work.

Hey @ibi420, This documentation that I outlined was a week before my actual implementation and it highlights my approach to what my initial plan was to fix the vulnerability, but later as I found out that the changes I made in multiple files (which I have highlighted in the document) to implement RBAC it disrupted the functionality of making changes at the backend broke the connnectivity with frontend and hence I had to come up with a new solution to fix the issue with as many minimal changes as I can, then I realised the data exposure occurred in the serializer layer, particularly in the Entities::UnitEntity class. These entity class defines how backend models are converted into API JSON responses, and they were exposing sensitive fields attribute without checking user roles. The UnitEntity class is responsible for deciding what fields of the Unit model are exposed. Fields such as :staff, :main_convenor_id, and :overseer_image_id were conditionally exposed but lacked proper role validation. And I have implemented a new fix with as many minimal changes as I can for which the frontend and both backend works well. You can find the change here

Hey @atharv02-git, I completely see my error; following our conversation, I reviewed your fix. You have implemented an attribute "is_staff" that addresses this issue instead of the RBAC I had initially thought and followed. This is what I initially referred to when I was reviewing your documentation.

[aNebula]

@atharv02-git Please raise this changes in a PR against doubtfire-astro