API Crash Course: Broken Object Level Authorisation Found in Coursera
July 2021 by Paulo Silva, Security Researcher, Checkmarx
In a year where “remote everything” became the norm, on-demand and e-learning courses, and the vendors powering these services, saw exponential growth. With this and as part of our ongoing mission to help organisations develop and deploy more secure software and applications, the Checkmarx Security Research Team decided to analyse the security posture of Coursera in accordance with the company’s Vulnerability Disclosure Program.
According to its website, “Coursera partners with more than 200 leading universities and companies to bring flexible, affordable, job-relevant online learning to individuals and organisations worldwide.” The Coursera network includes “82 million learners, 100+ Fortune 500 companies, and more than 6,000 campuses, businesses, and governments.”
Coursera’s Vulnerability Disclosure Program specifically notes that access control issues are a major concern: “We [Coursera] consider security issues to be issues when you can perform:
Access data that you are otherwise not authorised to access normally as a learner (...) Affects another learner outside of normal interactions on the platform (...)
· Accessing Coursera’s internal administrative control systems.”
Through our research, we discovered multiple API issues, such as user/account enumeration via the reset password feature, lack of resources limiting on both a GraphQL and REST API, and a GraphQL misconfiguration. But specifically, the Broken Object Level Authorisation (BOLA) issue we found perfectly fits Coursera’s access control concerns. Impact Summary
The BOLA API vulnerability our team discovered affected the users’ preferences. Even anonymous users were not only able to retrieve their preferences, but also change them. Some of these preferences, such as recently viewed courses and certifications, also leaked some metadata (e.g. activity date/time).
This vulnerability could have been abused to understand general users’ courses preferences at a large scale, but also to somehow bias users’ choices, since manipulating their recent activity affected the content rendered on Coursera’s homepage for a specific user. What We Found
While interacting with Coursera’s web application as regular users (learners), we noticed that recently viewed courses were displayed in the user interface. To render this information, we spotted several GET API requests to the same endpoint: /api/userPreferences.v1/USER_ID PREFERENCE_TYPE.
The USER_ID was almost obvious and of course we started playing with it to test API1:2019 Broken Object Level Authorization. After several successful requests to retrieve preferences of several user accounts controlled by us, we were able to enumerate ten different preference types (PREFERENCE_TYPE): ONBOARDING, INVITATION, PAYMENT, saveCreditCard, HONORS, S12N_UPGRADE, ADMIN_SELECTED_PARTNER, PROMOTION_LANDING_PAGE, GENERIC, RECENTLY_VIEWED_XDP.
It was obvious that we were dealing with an authorisation issue: one user was accessing another user’s data – and not only its preferences, but also some metadata such the exact date/time of its activity. As next step we started stripping the original request of cookies and headers, to come up with the conclusion that even anonymous users would have access to any user preferences (see Figure 1).
Figure 1: Anonymous request to retrieve arbitrary user recently viewed courses
But we were not done yet. Due to the predictability of REST APIs, the next natural step would be to replace the HTTP verb from GET to PUT to test whether we were also able to modify the user preferences. No special creativity was needed to craft a valid payload: we took it from one of our GET requests and replaced courses’ identifiers and timestamps. As shown in the picture below, the request payload was sent back in the HTTP response, suggesting preferences were successfully set.
Figure 2: Modifying another user’s recently viewed courses
You can watch the proof-of-concept video here. Risk Assessment
Unauthorised users’ data access is critical by definition, becoming even more relevant when it is also possible to manipulate such data. Authorisation issues directly impact data privacy, data integrity, user trust, and ultimately business reputation. The risk is increasingly high depending on what type of data unauthorised users get access to, or are able to manipulate (e.g., financial/payments). Recommendations
Authorisation issues are, unfortunately, quite common with APIs. It is very important to centralise access control validations in a single, well and continuously tested and actively maintained component. New API endpoints, or changes to the existing ones, should be carefully reviewed regarding their security requirements. Summary of Disclosure and Events
The Checkmarx Security Research Team responsibly notified Coursera, providing a detailed security advisory with research findings, instructions to reproduce the issues, and recommendations, which Coursera followed to address and mitigate the security issues.
October 5, 2020 – Checkmarx sent full report to Coursera’s security team.
October 26, 2020 – Coursera acknowledged receiving the report and working on it.
December 18, 2020 – Coursera wrote it resolved all issues.
January 2, 2021 – Checkmarx sent a re-test report with one new issue.
May 24, 2021 – Coursera confirmed all issues are fixed.
July 8, 2021 – Public disclosure.
It was a pleasure working with the Coursera security team. Their professionalism and cooperation, as well as the prompt ownership they took, are what we hope for when we engage with software companies. Kudos!
Generally speaking, API access control issues are one of the biggest security problems facing APIs. As vulnerable APIs increasingly fall into adversaries’ sights, it’s critical that developers receive proper education on best practices for embedding security into their design from the get-go - which CxCodebashing can help with.
This type of research activity is part of the Checkmarx Security Research Team’s ongoing efforts to drive the necessary changes in software security practices among organisations who offer online services in an effort to improve security for everyone overall.