Title: _TL;DR_: Stytch, a Login SaaS Unicorn, has no CRSF-protection in their authentication API and other questionable security practices, coupled with a nonexistent security policy.<p>First of all: Why am I posting this on Hacker News instead of disclosing directly?<p>From experience, a lack of security policies and of communication on existing vulnerabilities implies retaliatory practices when submitting vulnerabilities responsibly. Since MITRE CVE does not accept vulnerabilities for SaaS services, I figured that Hacker News would be the way to get Stytch aware of their issues without getting me in the crosshairs.<p>The setting:<p>A few weeks ago (in June 2022 to be exact) I was looking at different authentication services and Stytch was one of the services that got my attention. Stytch.com was founded in 2020 with over $125M [1] raised at a $1bn+ valuation [2].<p>Checking out what the fuzz was about I decided to look into their security practices. The lack of a bug bounty program (e.g. HackerOne), ethical disclosure policy, and security policy already left a bad feeling. But I was keeping an open mind and wanted to see what their API has to offer.<p>The scoop:<p>The most critical issue I came across was a complete lack of Cross-Site Request Forgery defenses. All of the provided authentication APIs (e.g. [4]) except for Social Sign-In are vulnerable to the most basic of login attack vectors: Login CSRF [3]. This can be used to steal credit card information, for example. CSRF is completely missing in all of the Stytchs API concepts, a major oversight in the API design.<p>Further I found that the OTP tokens sent via their &quot;passwordless&quot; email authentication were valid for up to 7 days and did not invalidate on use. Attackers may find old magic link tokens in the browser, chat, or email histories and use them to get a valid session. While this issue has been fixed since June 2022, the vulnerability was not disclosed to customers.<p>Recently, Stytch has introduced a concept from OAuth2 called PKCE - a spec that is difficult to master for everyday developers - into their non-standardized Magic Link API which does not use a three-legged delegation authorization mechanism. This is not a direct vulnerability per se, but at least a questionable choice in terms of security.<p>A full report can be found here for anyone interested: https:&#x2F;&#x2F;www.klgrth.io&#x2F;paste&#x2F;kmxof<p>[1] https:&#x2F;&#x2F;www.crunchbase.com&#x2F;organization&#x2F;stytch-auth
[2] https:&#x2F;&#x2F;stytch.com&#x2F;blog&#x2F;announcing-series-b&#x2F;
[3] https:&#x2F;&#x2F;cheatsheetseries.owasp.org&#x2F;cheatsheets&#x2F;Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#login-csrf
[4] https:&#x2F;&#x2F;stytch.com&#x2F;docs&#x2F;passcodes#sms_auth
Upvote: