6 ms·

Either I'm missing something here or the login CSRF explained in the report is a very weird and not exceptional impactful vulnerability. As described the author

Either I'm missing something here or the login CSRF explained in the report is a very weird and not exceptional impactful vulnerability. As described the author is talking about using a CSRF attack to force someone to authenticate to a service that uses Stytch. Regardless this is a HUGE stretch to say "has no CRSF-protection in their authentication API". You've shown one instance where they don't have CSRF protection on an endpoint that could be argued it's not necessary. Do they have CSRF protection on endpoints that let you adjust your account, perform actions in an app, or other legitimately concerning endpoints?

InitialBP 4y ago
I'd go a step further and stay the author is really making security researchers look bad. Can't really blame anyone for being concerned about corporate retaliation, but there are most certainly institutions that would send an email on your behalf to disclose vulnerabilities to a security@ email if you wanted to remain anonymous out of a sense of caution. On top of that you've made some inflated comments on the general security practices about this company with no real evidence and the vulnerabilities listed best-practices at best and inconsequential at worst. I question the motives behind a post like this: Does the author have some financial incentive to attempt to discredit Stytch? Does the author want to cause some panic/concern by making scary claims about Stytch? Does the author not truly understand the impact of their vulns and thing that this is a serious issue when it's not? I can't say but the whole situation really sits wrong with me.
- sam0x17 4y ago
  I'm all for this just being a disgruntled researcher as this is all really damning for the industry and for this startup if true, but the replay attacks on magic link login emails are really no small thing, especially for a SOC-2 caliber startup with this kind of valuation. All you have to do is sneak onto your target's gmail while they aren't looking (or phone), forward one of those emails within a week of them arriving, and you have 7-x days to compromise their account. This is very different from almost any other magic link which by convention are always consume-on-use with a short expiration and often a context cookie reqiurement. Imagine the CTO is screen sharing and a notification showing the code part of the link shows up without them noticing and now anyone on the call who noticed has a week to login as the CTO. This stuff can happen way easier than you think.
  - InitialBP 4y ago
    According to the report, the replay attack is only valid for 1 hour for login links, and 1 week for sign up links. I agree that there's some risk here, but the fix is probably straightforward (adjust timing to something more realistic or just invalidate them after use).
    - mcstempel 4y ago
      Hey there, I'm the founder/CEO at Stytch. I provided some more responses in this reply on the general post, but I'd also add that login and sign up links are invalidated after their first-time use https://news.ycombinator.com/reply?id=33164969&goto=item%3Fid%3D33162854%2333164969 https://news.ycombinator.com/reply?id=33164969&goto=item%3Fi...
    - mooreds 4y ago
      > just invalidate them after use I can't speak for Stytch, but I know at $CURJOB, we have run into issues with this where corporate phishing protection software invalidates one time use codes. I believe it does that because it retrieves links in emails before the user clicks on them. This was an issue several of our customers have raised. So it isn't as straightforward as you might think. There's more details, including the workaround we ended up using, on the GH issue: https://github.com/FusionAuth/fusionauth-issues/issues/629 https://github.com/FusionAuth/fusionauth-issues/issues/629 PS I agree they should absolutely have guidance around link lifetime as well as safe defaults. Converting the links to one-time use seems like a good start.
    - sam0x17 4y ago
      > the fix is probably straightforward Something I totally agree with before you've passed multiple audits. At this stage it's more a question of how the hell did this slip by 2 pen tests and 2 external audits (since they will have had to renew their SOC-2 by now. The "how this slipped through" is much more concerning than "what slipped through", though the "what slipped through" here is also rather serious imo.

InitialBP 4y ago

I'd go a step further and stay the author is really making security researchers look bad. Can't really blame anyone for being concerned about corporate retaliation, but there are most certainly institutions that would send an email on your behalf to disclose vulnerabilities to a security@ email if you wanted to remain anonymous out of a sense of caution. On top of that you've made some inflated comments on the general security practices about this company with no real evidence and the vulnerabilities listed best-practices at best and inconsequential at worst. I question the motives behind a post like this: Does the author have some financial incentive to attempt to discredit Stytch? Does the author want to cause some panic/concern by making scary claims about Stytch? Does the author not truly understand the impact of their vulns and thing that this is a serious issue when it's not? I can't say but the whole situation really sits wrong with me.

sam0x17 4y ago
I'm all for this just being a disgruntled researcher as this is all really damning for the industry and for this startup if true, but the replay attacks on magic link login emails are really no small thing, especially for a SOC-2 caliber startup with this kind of valuation. All you have to do is sneak onto your target's gmail while they aren't looking (or phone), forward one of those emails within a week of them arriving, and you have 7-x days to compromise their account. This is very different from almost any other magic link which by convention are always consume-on-use with a short expiration and often a context cookie reqiurement. Imagine the CTO is screen sharing and a notification showing the code part of the link shows up without them noticing and now anyone on the call who noticed has a week to login as the CTO. This stuff can happen way easier than you think.
- InitialBP 4y ago
  According to the report, the replay attack is only valid for 1 hour for login links, and 1 week for sign up links. I agree that there's some risk here, but the fix is probably straightforward (adjust timing to something more realistic or just invalidate them after use).
  - mcstempel 4y ago
    Hey there, I'm the founder/CEO at Stytch. I provided some more responses in this reply on the general post, but I'd also add that login and sign up links are invalidated after their first-time use https://news.ycombinator.com/reply?id=33164969&goto=item%3Fid%3D33162854%2333164969 https://news.ycombinator.com/reply?id=33164969&goto=item%3Fi...
  - mooreds 4y ago
    > just invalidate them after use I can't speak for Stytch, but I know at $CURJOB, we have run into issues with this where corporate phishing protection software invalidates one time use codes. I believe it does that because it retrieves links in emails before the user clicks on them. This was an issue several of our customers have raised. So it isn't as straightforward as you might think. There's more details, including the workaround we ended up using, on the GH issue: https://github.com/FusionAuth/fusionauth-issues/issues/629 https://github.com/FusionAuth/fusionauth-issues/issues/629 PS I agree they should absolutely have guidance around link lifetime as well as safe defaults. Converting the links to one-time use seems like a good start.
  - sam0x17 4y ago
    > the fix is probably straightforward Something I totally agree with before you've passed multiple audits. At this stage it's more a question of how the hell did this slip by 2 pen tests and 2 external audits (since they will have had to renew their SOC-2 by now. The "how this slipped through" is much more concerning than "what slipped through", though the "what slipped through" here is also rather serious imo.