6 ms·

Spotify – security team response time

43 points by algorithm_dk 13y ago

pilif 13y ago
The initial response was very quick, but honestly: Fixing such a simple XSS hole on a web application shouldn't take 7 days. In the age of automated testing and continuos deployment, escaping that parameter is trivial. Granted. If you have a systemic issue and you need to fix your framework to always escape unless told otherwise, that will take longer, but it won't prevent you from quick-fixing just the reported issue.
- algorithm_dk 13y ago
  It took them 7 days to fully test the patch. LinkedIn's team for instance responds in 2 hours.
- antsar 13y ago
  I had to do a double-take when I read the "7 days" part, because I wasn't sure why that should be a pleasant surprise. If it were their desktop client, that kind of turnaround would be understandable. For their website? I don't see why they couldn't have deployed a hotfix immediately. On the other hand, perhaps they had a quota of more serious security issues and were preoccupied with addressing those.
  - abjorn 13y ago
    It's likely that it was fixed sooner than that. I would bet they gave it 7 days before he could talk about it, so they could audit the rest of their site.
- JoachimSchipper 13y ago
  "We have fixed it" is easy to understand as "you're now free to blog about this flaw"; one could imagine why Spotify would want to take the time to properly audit the rest of the site. Also, Spotify is a serious business that doesn't want to go down, and likely has a testing/deployment process a bit more complicated than "just push to master".
- a1a 13y ago
  Indeed. I would like to add that the initial response was most likely automated (looks kinda generic). Kinda makes me want to send a dummy email and see if I get a similar response as fast. But in all fairness, 7 days is still acceptable. It's far from "best ever", but compared to others it's still great.
- rohansingh 13y ago
  I just checked our logs and we had a fix commit and built to stable within a day. We wouldn't wait around a week on something like this.
yeukhon 13y ago
edit: oops. Didn't know it was actually a Sweden based company. (minus 1000000000 chars below). Regarding the 7 days patch, that does look long. Not sure why. It'd be interesting to find out. By the way, I like your resume. Visually impressive; a pleasant to read. It'd be interesting to see that being a shirt.
- nbody 13y ago
  Actually Spotify is mostly Sweden-based but they seem to be ramping up on NY as well.
  - yeukhon 13y ago
    Oh! Thanks for the correction! I am surprised. They used to recruit a lot of U.S. based engineers last year as I was looking for job.
    - nirvanis 13y ago
      Yes, Spotify is a Swedish companies, but we have several engineering offices in the US and in Europe. The current openings are listed on spotify.com/jobs
billyhoffman 13y ago
From OP: "Spotify came to my attention because of that specific page as I'm currently looking to build a security portfolio." This is almost as foolish as it is illegal. Finding web security issues is much more complicated legally than finding security issues in desktop/server software. I can download and install Apache and test it on my local box and discover things like the Range Header DoS. There are no legal issues for me to worry about. I can't download and install "LinkedIn" and test it for web issues. I have to test against their site running on their computers. Immediately in the US the Computer Fraud and Abuse Act comes into play (though the OP lives in Denmark). "Hmmm, let me 'test' random website X for something that could cause a DoS" is insane. Even if a company has a formal "we are OK and authorize people to test our site for security issues" policy that is still extremely dangerous from a legal perspective. Maybe you are only authorized if you follow their specific disclosure policies. Maybe you are only authorized to do non-destructive testing. Every company is going to have some tipping point where, if you testing impacts X or caused Y downtime, that's enough damage where they will seek your prosecution. Building a "security portfolio" against websites is a stupid idea with some potentially huge negative consequences. If anyone insists on doing this, at least go looking for issues in projects that you can download and audit locally.
- korzun 13y ago
  He found a minor XSS flaw that was overlooked. You are reaching a bit too far, it's not like he hacked their database or accessed private data.
- algorithm_dk 13y ago
  Spotify agrees on security researching as long as it's not disrupting the service. Any disrupting analysis method is forbidden and I would not proceed in auditing something without permission before having a security audit contract signed by the company operating the service.
- icanhasfay 13y ago
  Have to disagree with a few points here. "Hmmm, let me 'test' random website X for something that could cause a DoS" The author was testing reflected XSS which is inherently client side, there should be no case of concern for DoS here. "Building a "security portfolio" against websites is a stupid idea with some potentially huge negative consequences." The author mentions Apple, Linkedin, Amazon and AT&T all of which have some type of vulnerability notification program. (See https://bugcrowd.com/list-of-bug-bounty-programs/ https://bugcrowd.com/list-of-bug-bounty-programs/ for a great list of programs) I would have to say that as long as the researcher was performing within the scope of the respective program, there should be no worry. I think it's the exact opposite of a stupid idea. Building out a portfolio within the scopes of the programs is a great way to build some security reputation.
korzun 13y ago
Response time is useless if it still takes 7 days to deploy a patch for a simple XSS issue.
- jsegura 13y ago
  Totally agree with that. The important time is the one between the disclosure and the fix, not the one between the disclosure and the first response. It could be a bot :)
  - nirvanis 13y ago
    Trust me, Nenad is not a bot :) We work hard on becoming better and faster at tackling these and other issues. We try to learn from incidents and mistakes in order to be faster next time. Thanks for the feedback.
- bestdayever 13y ago
  (You probably already saw this but if you didn't)Spotify employee already pointed out the bug was fixed within the day the original email was sent. 7 days was probably after an audit to check for the issue in other places and then after 7 days they felt comfortable letting the researcher talk about it. Cheers!
HERPDERPSD 13y ago
Did they reward you in any way, or simply recognize your name on this list?

43 points by algorithm_dk 13y ago

pilif 13y ago

The initial response was very quick, but honestly: Fixing such a simple XSS hole on a web application shouldn't take 7 days. In the age of automated testing and continuos deployment, escaping that parameter is trivial. Granted. If you have a systemic issue and you need to fix your framework to always escape unless told otherwise, that will take longer, but it won't prevent you from quick-fixing just the reported issue.

algorithm_dk 13y ago
It took them 7 days to fully test the patch. LinkedIn's team for instance responds in 2 hours.
antsar 13y ago
I had to do a double-take when I read the "7 days" part, because I wasn't sure why that should be a pleasant surprise. If it were their desktop client, that kind of turnaround would be understandable. For their website? I don't see why they couldn't have deployed a hotfix immediately. On the other hand, perhaps they had a quota of more serious security issues and were preoccupied with addressing those.
- abjorn 13y ago
  It's likely that it was fixed sooner than that. I would bet they gave it 7 days before he could talk about it, so they could audit the rest of their site.
JoachimSchipper 13y ago
"We have fixed it" is easy to understand as "you're now free to blog about this flaw"; one could imagine why Spotify would want to take the time to properly audit the rest of the site. Also, Spotify is a serious business that doesn't want to go down, and likely has a testing/deployment process a bit more complicated than "just push to master".
a1a 13y ago
Indeed. I would like to add that the initial response was most likely automated (looks kinda generic). Kinda makes me want to send a dummy email and see if I get a similar response as fast. But in all fairness, 7 days is still acceptable. It's far from "best ever", but compared to others it's still great.
rohansingh 13y ago
I just checked our logs and we had a fix commit and built to stable within a day. We wouldn't wait around a week on something like this.

yeukhon 13y ago

edit: oops. Didn't know it was actually a Sweden based company. (minus 1000000000 chars below). Regarding the 7 days patch, that does look long. Not sure why. It'd be interesting to find out. By the way, I like your resume. Visually impressive; a pleasant to read. It'd be interesting to see that being a shirt.

nbody 13y ago
Actually Spotify is mostly Sweden-based but they seem to be ramping up on NY as well.
- yeukhon 13y ago
  Oh! Thanks for the correction! I am surprised. They used to recruit a lot of U.S. based engineers last year as I was looking for job.
  - nirvanis 13y ago
    Yes, Spotify is a Swedish companies, but we have several engineering offices in the US and in Europe. The current openings are listed on spotify.com/jobs

billyhoffman 13y ago

From OP: "Spotify came to my attention because of that specific page as I'm currently looking to build a security portfolio." This is almost as foolish as it is illegal. Finding web security issues is much more complicated legally than finding security issues in desktop/server software. I can download and install Apache and test it on my local box and discover things like the Range Header DoS. There are no legal issues for me to worry about. I can't download and install "LinkedIn" and test it for web issues. I have to test against their site running on their computers. Immediately in the US the Computer Fraud and Abuse Act comes into play (though the OP lives in Denmark). "Hmmm, let me 'test' random website X for something that could cause a DoS" is insane. Even if a company has a formal "we are OK and authorize people to test our site for security issues" policy that is still extremely dangerous from a legal perspective. Maybe you are only authorized if you follow their specific disclosure policies. Maybe you are only authorized to do non-destructive testing. Every company is going to have some tipping point where, if you testing impacts X or caused Y downtime, that's enough damage where they will seek your prosecution. Building a "security portfolio" against websites is a stupid idea with some potentially huge negative consequences. If anyone insists on doing this, at least go looking for issues in projects that you can download and audit locally.

korzun 13y ago
He found a minor XSS flaw that was overlooked. You are reaching a bit too far, it's not like he hacked their database or accessed private data.
algorithm_dk 13y ago
Spotify agrees on security researching as long as it's not disrupting the service. Any disrupting analysis method is forbidden and I would not proceed in auditing something without permission before having a security audit contract signed by the company operating the service.
icanhasfay 13y ago
Have to disagree with a few points here. "Hmmm, let me 'test' random website X for something that could cause a DoS" The author was testing reflected XSS which is inherently client side, there should be no case of concern for DoS here. "Building a "security portfolio" against websites is a stupid idea with some potentially huge negative consequences." The author mentions Apple, Linkedin, Amazon and AT&T all of which have some type of vulnerability notification program. (See https://bugcrowd.com/list-of-bug-bounty-programs/ https://bugcrowd.com/list-of-bug-bounty-programs/ for a great list of programs) I would have to say that as long as the researcher was performing within the scope of the respective program, there should be no worry. I think it's the exact opposite of a stupid idea. Building out a portfolio within the scopes of the programs is a great way to build some security reputation.

korzun 13y ago

Response time is useless if it still takes 7 days to deploy a patch for a simple XSS issue.

jsegura 13y ago
Totally agree with that. The important time is the one between the disclosure and the fix, not the one between the disclosure and the first response. It could be a bot :)
- nirvanis 13y ago
  Trust me, Nenad is not a bot :) We work hard on becoming better and faster at tackling these and other issues. We try to learn from incidents and mistakes in order to be faster next time. Thanks for the feedback.
bestdayever 13y ago
(You probably already saw this but if you didn't)Spotify employee already pointed out the bug was fixed within the day the original email was sent. 7 days was probably after an audit to check for the issue in other places and then after 7 days they felt comfortable letting the researcher talk about it. Cheers!

HERPDERPSD 13y ago

Did they reward you in any way, or simply recognize your name on this list?