4 ms·

My understanding is that the token itself is fine and within spec. But they altered the flow to accept an email address in one of the request payloads which ope

My understanding is that the token itself is fine and within spec. But they altered the flow to accept an email address in one of the request payloads which opened the door for spoofing the email address. I've never seen an OAuth or OpenID flow that relied on the payload for identity.

donmcronald 6y ago
This is likely it IMO. They probably pass the preferred email around as a parameter and the user can jump into the flow and modify it.
SV_BubbleTime 6y ago
Wait... I don’t get it. Why was Apple signing a response JWT when the user only supplied an email? I’m not a web guy so I just don’t see what they were going for here.
- phamilton 6y ago
  The gap is that Apple fully verified identity via the normal OAuth flow, and then once identiy was verified they give the use control over what email to include in the token. The idea is that the user can include their email or an apple relay email (that forwards to their email). The bug seems to be in that step, and an attacker can provide an email that is neither their own nor an apple relay email. Your apple account is safe, but if a 3rd party trusts the signed apple payload without further verification of email, an attacker could sign in as you on the 3rd party app.
  - SV_BubbleTime 6y ago
    That makes sense. Seems little too obvious to exist, but people make mistakes. It’s just that with JWT/JSE/JOSE already questionable security options that you would be extra super careful if you are using it. (Biggest flaw off the top of my head is it literally says what encryption is used with a NONE option meaning you can just switch to “none” and forge jwts to anyone that didn’t know not to accept those, second would be that they mix symmetric and asymmetric encryption options)
    - catlifeonmars 6y ago
      I noticed after reading your comment that HS256 is marked as “required” for compliant implantations. In practice, I have only ever seen signers implement RS256 though...
      - sascha_sl 6y ago
        In OIDC you can actually specificy supported key types in the discovery process and the IdP always decides the key type anyway. HS256 relies in shared secrets, so anyone who can verify a token can also change it. RS256 allows you to download the IdP keychain every once in a while and verify tokens offline.
        catlifeonmars 6y ago
        Yes, that’s what I meant. I only see RS256 implemented by identity providers (and advertised via .well-known/openid-configuration). This makes sense, since most identity providers are decoupled from their clients and thus cannot feasibly share a symmetric key. I am confused what is meant in the JWA specification[1] by “HS256: required” under “implementation requirements” in the table of allowed values (the entry for RS256 reads “recommended” for that column). [1]: https://tools.ietf.org/html/rfc7518#section-3.1 https://tools.ietf.org/html/rfc7518#section-3.1
  - dwaite 6y ago
    Apple deviated from OpenID Connect, but... The third party is not supposed to link the information from an OpenID Connect client system by email address, which could change or go away at any time, and is also not guaranteed to be unique. Rather, they should use the 'sub' claim which is meant to be the same over the lifetime of the user account with the issuer.
    - hirsin 6y ago
      Yup, this is it. It's a super common issue though, and we see it all the time. An app expected the email of a user to be static and keys off of it. User gets married and loses their code access. At best it's a work stoppage when someone changes their email. At worst you make assumptions about reusability of emails and give data access to the wrong account.

donmcronald 6y ago

This is likely it IMO. They probably pass the preferred email around as a parameter and the user can jump into the flow and modify it.

SV_BubbleTime 6y ago

Wait... I don’t get it. Why was Apple signing a response JWT when the user only supplied an email? I’m not a web guy so I just don’t see what they were going for here.

phamilton 6y ago
The gap is that Apple fully verified identity via the normal OAuth flow, and then once identiy was verified they give the use control over what email to include in the token. The idea is that the user can include their email or an apple relay email (that forwards to their email). The bug seems to be in that step, and an attacker can provide an email that is neither their own nor an apple relay email. Your apple account is safe, but if a 3rd party trusts the signed apple payload without further verification of email, an attacker could sign in as you on the 3rd party app.
- SV_BubbleTime 6y ago
  That makes sense. Seems little too obvious to exist, but people make mistakes. It’s just that with JWT/JSE/JOSE already questionable security options that you would be extra super careful if you are using it. (Biggest flaw off the top of my head is it literally says what encryption is used with a NONE option meaning you can just switch to “none” and forge jwts to anyone that didn’t know not to accept those, second would be that they mix symmetric and asymmetric encryption options)
  - catlifeonmars 6y ago
    I noticed after reading your comment that HS256 is marked as “required” for compliant implantations. In practice, I have only ever seen signers implement RS256 though...
    - sascha_sl 6y ago
      In OIDC you can actually specificy supported key types in the discovery process and the IdP always decides the key type anyway. HS256 relies in shared secrets, so anyone who can verify a token can also change it. RS256 allows you to download the IdP keychain every once in a while and verify tokens offline.
      - catlifeonmars 6y ago
        Yes, that’s what I meant. I only see RS256 implemented by identity providers (and advertised via .well-known/openid-configuration). This makes sense, since most identity providers are decoupled from their clients and thus cannot feasibly share a symmetric key. I am confused what is meant in the JWA specification[1] by “HS256: required” under “implementation requirements” in the table of allowed values (the entry for RS256 reads “recommended” for that column). [1]: https://tools.ietf.org/html/rfc7518#section-3.1 https://tools.ietf.org/html/rfc7518#section-3.1
- dwaite 6y ago
  Apple deviated from OpenID Connect, but... The third party is not supposed to link the information from an OpenID Connect client system by email address, which could change or go away at any time, and is also not guaranteed to be unique. Rather, they should use the 'sub' claim which is meant to be the same over the lifetime of the user account with the issuer.
  - hirsin 6y ago
    Yup, this is it. It's a super common issue though, and we see it all the time. An app expected the email of a user to be static and keys off of it. User gets married and loses their code access. At best it's a work stoppage when someone changes their email. At worst you make assumptions about reusability of emails and give data access to the wrong account.