Reply to thread

Message

<blockquote data-quote="Hacker News" data-source="post: 71509" data-attributes="member: 365">_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.First of all: Why am I posting this on Hacker News instead of disclosing directly?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.The setting: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].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.The scoop: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.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.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.A full report can be found here for anyone interested: <a href="https://www.klgrth.io/paste/kmxof" target="_blank">https://www.klgrth.io/paste/kmxof</a>[1] <a href="https://www.crunchbase.com/organization/stytch-auth" target="_blank">https://www.crunchbase.com/organization/stytch-auth</a> [2] <a href="https://stytch.com/blog/announcing-series-b/" target="_blank">https://stytch.com/blog/announcing-series-b/</a> [3] <a href="https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#login-csrf" target="_blank">https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#login-csrf</a> [4] <a href="https://stytch.com/docs/passcodes#sms_auth" target="_blank">https://stytch.com/docs/passcodes#sms_auth</a><hr />Comments URL: <a href="https://news.ycombinator.com/item?id=33162854" target="_blank">https://news.ycombinator.com/item?id=33162854</a>Points: 25# Comments: 3<a href="https://news.ycombinator.com/item?id=33162854" target="_blank">Continue reading...</a></blockquote>

[QUOTE="Hacker News, post: 71509, member: 365"] _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. First of all: Why am I posting this on Hacker News instead of disclosing directly? 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. The setting: 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]. 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. The scoop: 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. Further I found that the OTP tokens sent via their "passwordless" 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. 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. A full report can be found here for anyone interested: [URL]https://www.klgrth.io/paste/kmxof[/URL] [1] [URL]https://www.crunchbase.com/organization/stytch-auth[/URL] [2] [URL]https://stytch.com/blog/announcing-series-b/[/URL] [3] [URL]https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#login-csrf[/URL] [4] [URL]https://stytch.com/docs/passcodes#sms_auth[/URL] [HR][/HR] Comments URL: [URL]https://news.ycombinator.com/item?id=33162854[/URL] Points: 25 # Comments: 3 [url="https://news.ycombinator.com/item?id=33162854"]Continue reading...[/url] [/QUOTE]

Verification