Academic Platform ‘Security Assessment’ 😉

The Story

During the COVID-19 pandemic, university coursework moved almost entirely online. Assignments, lectures, projects, and examinations were being handled through web-based academic platforms.

As a cybersecurity enthusiast, I became interested in understanding how securely these systems separated student and faculty functionality. I began testing the assignment and course-management platform using my own student account.

For roughly three months, I found nothing significant. The platform appeared reasonably well protected, so I continued looking at its functionality and request patterns rather than attempting to bypass controls aggressively.

The first major finding came from something simple: during a lecture, I noticed a professor-facing URL on the screen. I tried accessing the same URL with my own authenticated student session.

It worked.

I could access the course through the professor’s interface and interact with functionality that should have been restricted to faculty. I was able to manipulate course material and assignments and, notably, create new assignments.

That initial authorization failure led to a broader investigation.

The Vulnerability

Horizontal and Vertical Privilege Escalation

The application was not consistently enforcing authorization based on the authenticated user’s role.

Using my student session, I was able to access functionality intended for a professor. This represented both vertical privilege escalation—moving from student functionality to faculty functionality—and horizontal authorization weaknesses where access to resources belonging to another context was not properly restricted.

The important issue was not simply that a particular URL was accessible. The application was trusting the requested resource and session context without consistently verifying whether the authenticated user was authorized to perform the requested operation.

This exposed high-impact functionality such as course and assignment management.

Stored XSS Through Course Documents

While exploring the course-document functionality, I noticed that uploaded documents could use different formats without sufficiently restricting their content.

I tested the behavior conceptually with an HTML document and found that JavaScript could execute when another user opened the uploaded content.

This created a stored cross-site scripting attack path.

Had it been exploited against another authenticated user, the XSS could potentially have been used to perform actions in that user’s browser context, including session-related attacks depending on the application’s cookie and browser security controls.

I did not use the vulnerability to hijack anyone’s session. The discovery itself was sufficient to demonstrate the security impact.

The Examination Portal

The university’s end-semester examination system was a separate platform and was only available during examination periods. This significantly reduced the amount of time available for testing.

I therefore approached it primarily by observing application behavior and recording request patterns.

I proxied requests through Burp Suite and analyzed them after each examination. I paid particular attention to identifiers associated with examinations and where those identifiers appeared in requests and application routes.

After the first paper, patterns in the examination IDs became apparent. The next challenge was determining where those identifiers were being used.

Endpoint Discovery

I used controlled fuzzing to identify additional application routes. Some of the discovered endpoints accepted an examination identifier along with another identifier and returned examination-related documents.

Initially, I considered whether this could expose examination papers before or during an exam. That was not the path I ultimately pursued or exploited.

Instead, I investigated the second identifier.

I discovered that the additional identifier was assigned by the examination portal to individual students and was exposed as part of the student’s examination card.

Combining the information already available to a student with the newly discovered routes allowed me to access examination submission documents associated with other students.

This demonstrated an insecure direct object reference / broken object-level authorization issue: possession or knowledge of an identifier was enough to retrieve another student’s resource without an adequate authorization check.

The Grading Workflow

The most significant discovery came while following links and routes exposed by the examination system.

One of the newly discovered routes appeared to correspond to the examiner’s grading interface.

It did.

The workflow exposed functionality associated with grading examination submissions. Combined with the previously discovered submission functionality, this meant that a student could reach functionality that should have been restricted to examiners.

In practical terms, the chain of authorization failures potentially allowed a student to:

1. Access examination submission resources outside their own account.
2. Interact with submission-related functionality.
3. Reach the examiner-facing grading workflow.
4. Potentially influence or grade examination submissions.

This was the point at which the assessment moved from individual authorization bugs to a broader failure in the application’s role and object-level access-control model.

I did not modify other students’ submissions or manipulate grades.

Responsible Disclosure

After discovering the examination-system issues, I contacted my cybersecurity professor and demonstrated the complete case.

The professor and I were able to review the findings together, and I subsequently documented the vulnerabilities in a report and submitted the findings to the team responsible for the platform.

The testing had not been formally authorized by the platform team beforehand. I had informed my professor, and once the findings became significant, I stopped short of using the vulnerabilities to obtain academic advantage or modify other users’ data.

The objective was to demonstrate the security weaknesses and make sure they were addressed.

The findings were documented, fixes were proposed, and I followed up to ensure the identified issues were resolved.

Architecture & Security Analysis

The central issue across both systems was server-side authorization.

Authentication alone was not sufficient to protect sensitive functionality. The applications needed to establish authorization at every relevant operation:

flowchart TD
    A[Authenticated Student Session] --> B{Server-side Authorization}
    B -->|Correct role + resource ownership| C[Allowed Operation]
    B -->|Incorrect role| D[Access Denied]
    B -->|Incorrect resource ownership| D

    E[Student-facing Request] --> F[Object / Resource ID]
    F --> B

    G[Professor Functionality] --> B
    H[Exam Submission] --> B
    I[Examiner Grading] --> B

The assessment exposed several variations of the same underlying weakness:

• URLs were not always protected by role-based authorization.
• Resource identifiers could be manipulated without sufficient ownership checks.
• Student and faculty workflows were not consistently separated at the server.
• Uploaded content was not sufficiently constrained to prevent script execution.
• Sensitive examiner functionality was reachable from the broader application surface.

The key lesson was that hiding administrative URLs or relying on the frontend to determine which functionality a user should see is not an authorization boundary.

Impact

The findings demonstrated that a compromised or malicious student account could potentially cross multiple security boundaries within the academic platforms.

The most significant impacts included:

• Unauthorized access to faculty-level course functionality.
• Ability to create or manipulate course assignments.
• Stored XSS through uploaded course content.
• Potential browser/session compromise through the XSS attack path.
• Unauthorized access to other students’ examination submissions.
• Exposure of examiner-facing functionality.
• Potential ability to manipulate the grading workflow.

No grades were changed, no other student’s work was intentionally modified, and I did not use the discovered vulnerabilities to obtain academic benefits.

Lessons Learned

Authorization must be enforced server-side

The most important lesson was that authentication and authorization are separate problems.

A valid student session should not automatically grant access to a resource simply because the requested URL exists. Every sensitive operation needs to validate both the user’s role and their relationship to the requested resource.

Object identifiers are not authorization

Knowing or discovering an identifier should never be enough to access the corresponding object.

The examination portal demonstrated why object-level authorization needs to happen independently of whether an identifier is valid.

Small findings can form a larger attack path

The individual issues were serious on their own, but their combination was more important.

A role-boundary failure, weak object authorization, exposed examiner routes, and unsafe document handling collectively created a much larger security boundary failure than any one issue suggested.

Observation is often more valuable than exploitation

The examination portal was only available for limited periods, so I spent significant time recording requests and analyzing them later.

Burp Suite became useful not only for manipulating requests but also as a way to understand how the application represented examinations, submissions, and user actions.

In several cases, understanding how the application was structured was enough to demonstrate the vulnerability without causing damage.

Responsible disclosure matters

The most valuable outcome was not proving that I could abuse the system. It was documenting the vulnerabilities clearly enough for the responsible team to fix them.

The experience reinforced the importance of stopping once sufficient evidence has been collected, avoiding unnecessary access to other users’ data, and communicating findings responsibly.

Outcome

The vulnerabilities were documented and reported, fixes were proposed, and I followed up to ensure that the identified issues were addressed.

The project was an early practical security assessment that taught me how authorization failures, insecure object references, unsafe content handling, and exposed internal workflows can combine into a significant application-security problem.