Security Flaw: Sign In With Apple
This post explains the recently announced security flaw with the Sign in with Apple feature, and some of the lessons learned.
Join the DZone community and get the full member experience.
Join For FreeWhat is Sign in With Apple?
You might have seen a lot of websites and mobile apps that allow you to “Sign in/Log in via” Google, Facebook or Twitter. “Sign in with Apple” is an addition to the same set of authentication providers. In this approach a user need not create an account on every individual website. Rather they can simply use their existing accounts in Google, Facebook, Twitter, or Apple to access the 3rd party website. This is called a 3rd party sign in. This website is called a 3rd party since the first two parties are the user and the authentication provider like Google.
The benefit to these websites is that they get to leverage the superior security protocols put in place by the tech giants. Additionally, they avoid the overhead of building any sort of authentication mechanisms themselves on their own websites.
What is JWT? How Does It Help With Sign in With Apple?
JWT (JSON Web Token) is a mechanism to achieve such 3rd party sign-ins. Simply put, on a 3rd party website/mobile app, when a user selects a “Sign in with Apple” option, they are redirected to Apple’s sign-in page. Once the user signs in to Apple (via password, security pattern, security code, fingerprint, or Face ID), Apple issues something called a JWT token to the user. This JWT token is what is allowed access to the 3rd party app. Sign in with Apple uses this JWT token approach for its 3rd party sign-ins.
What Was Vulnerable?
A bug bounty hunter identified a flaw in Apple’s 3rd party sign-in mechanism. The vulnerability was that there was a URL (or a variation of it) exposed by Apple that would return a JWT token based on just an email address and nothing else being mandated. This was not the core URL used for the JWT token generation, but was an orphaned URL. While the core URL performed all the checks, the vulnerable URL did not. So, as long as you have just the email address of the user, you would be able to access the 3rd party apps using the JWT token.
This flaw allowed access only to 3rd party app, but not to any of Apple’s own websites.
How Does Apple Claim That There Was No Misuse?
Thankfully, logging was implemented in the orphaned URL’s flow. This way Apple was able to reconcile if there was any misuse of this security flaw. Gratefully, there was no such misuse.
Lessons Learned
Effectively, the issue here was that there was a URL deployed without being tested. This could be either because:
- The URL was not supposed to be deployed at all. It could have been a temporary developer testing URL that was mistakenly deployed. This highlights the need for verifying the list of URLs that would be deployed as well to ensure that nothing untested is deployed.
There was a missing negative test for the actual URL that generates the JWT token. The missing negative scenario here would be requesting the JWT token with just an email address.
Despite the flaw, the one aspect that protected the reputation of Apple was proof that there was no misuse of this vulnerability. Hence, the need for appropriate logs for all exposed URLs too.
Published at DZone with permission of Taha Dalal. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
Effective Java Collection Framework: Best Practices and Tips
-
Microservices With Apache Camel and Quarkus
-
How To Approach Java, Databases, and SQL [Video]
-
Writing a Vector Database in a Week in Rust
Comments