Cross-Site Scripting

Nobody has claimed this yet.

**Description**
Throughout the course of testing, LMG identified multiple instances of reflected and Document Object Model (DOM) based cross-site scripting (XSS).

Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way, whereas Document Object Model cross-site scripting vulnerabilities arise when user input is rendered on the client side of the application, bypassing the need for delivered content from the server. A malicious actor can use the vulnerability to construct a request that, if issued by another application user, will cause JavaScript code supplied by the malicious actor to execute within the user's browser in the context of that user's session with the application.

The supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.

The security impact of cross-site scripting vulnerabilities is dependent upon the nature of the vulnerable application, the kinds of data and functionality that it contains, and the other applications that belong to the same domain and organization. If the application is used only to display non-sensitive public content, with no authentication or access control functionality, then a cross-site scripting flaw may be considered medium- or low-risk. However, if the same application resides on a domain that can access cookies for other, more security-critical applications, then the vulnerability could be used to attack those other applications, and so may be considered high-risk. Similarly, if the organization that owns the application is a likely target for phishing attacks, then the vulnerability could be leveraged to lend credibility to such attacks, by injecting Trojan functionality into the vulnerable application and exploiting users' trust in the organization in order to capture credentials for other applications that it owns. In many kinds of applications, such as those providing online banking functionality, cross-site scripting should always be considered high-risk.

**How to reproduce**
LMG identified XSS within the URL of the subdomain located at https://lookit.mit.edu/reset/set-password. The POST request generated when LMG inserted the Proof-of-Concept string into the vulnerable URL.

This string generates a JavaScript alert window that would be displayed in a web browser.

LMG also identified XSS within the “player_repo_url” DOM variable within the web page located at https://lookit.mit.edu/study/create. LMG inserted the Proof-of-Concept string into the vulnerable variable.

This string generated a JavaScript alert window directly on the end user’s browser.

**Additional context**
In most situations where user-controllable data is copied into application responses, cross- site scripting attacks can be prevented using two layers of defenses:

- Input should be validated as strictly as possible on arrival, given the kind of content that it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input that fails the validation should be rejected, not sanitized.
- User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including <, >, ", ', and =, should be replaced with the corresponding HTML entities (<, >, etc).

In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.

**LMG Document**
https://drive.google.com/file/d/18vNuBbHOTZCrTZYvgz7oAbVwzfAJwsdd/view?usp=share_link

Start by tracing the request handling for /reset/set-password and the client-side code for /study/create, focusing on the reported URL input and player_repo_url DOM variable. Reproduce the supplied proof-of-concept safely to identify both execution paths. Done means the reported inputs no longer execute JavaScript in either endpoint and the existing behavior remains intact.

Written by the indexing model from the issue text.