1. what sign in with apple is
2. sign in with apple is like oauth2
3. there's some bug (not explained) that allows JWTs to be generated for arbitrary emails
4. this bug is bad because you can impersonate anyone with it
5. I got paid $100k for it
1. what sign in with apple is
2. sign in with apple is like oauth2
3. there's some bug (not explained) that allows JWTs to be generated for arbitrary emails
4. this bug is bad because you can impersonate anyone with it
5. I got paid $100k for it
Note that when they give the POST request, they say "Sample Request (2nd step)".
But what is step 2? The diagram above shows step 2 as a response, not a request. At least that's how I interpret an arrow pointing back toward the user. So the write-up conflicts with the diagram.
How do you resolve that conflict? One guess is that "Sample Request (2nd step)" should say "1st step" instead.
Another guess is that the arrow directions don't necessarily always indicate whether a step is a request or a response, so that step 1 could be a request and response, and step 2 could be another request and response that POSTs to a secret URL that was learned about in step 1. (This guess could make sense because the request is a JSON message with just the email field. There must be credentials somewhere, so either it's redacted or some kind of credentials were given another way, like in step 1.)
If this second guess is right, then a follow-on guess is that the crux of the bug is that in step 1, you sign in with a particular email, then Apple says "OK, now here's a secret URL to call to get a JWT token", and then in step 2, you change email, and it doesn't notice/care that you changed emails between step 1 and 2.
> Here on passing any email, Apple generated a valid JWT (id_token) for that particular Email ID.
You need an additional bug on the relying party for this to allow someone to gain access - that they associate the apple account based on the unstable email address claim rather than the stable "sub" claim.