Impact
As encouraged by Apple's non-standard OpenID Connect implementation, the aspnet-contrib Apple provider for ASP.NET Core extracts the email address and the first/last name of the logged in user from a special user
parameter that is directly returned as part of the authorization response. These values are then used to populate the ClaimTypes.Email
, ClaimTypes.GivenName
and ClaimTypes.Surname
claims that are added to the resulting ClaimsPrincipal
instance.
Unfortunately, this parameter is not cryptographically signed and can be easily tampered with by an attacker to inject any forged value. While the email address returned by an external provider should never be used as a lookup identifier, applications doing so could be at risk and may be vulnerable to elevation of privilege attacks.
Patches
This vulnerability has been patched in 3.1.8 and 6.0.10 by removing built-in support for the non-standard user
parameter. Other versions are no longer supported and won't receive fixes.
After applying the fix, developers are encouraged to review their use of these claims and ensure their applications were not targeted by an attacker.
Note: due to an Apple limitation, the ClaimTypes.GivenName
and ClaimTypes.Surname
claims will no longer be populated after migrating to a patched version.
Workarounds
While patching remains the recommended action, this security issue can be worked around by removing any use of the ClaimTypes.Email
, ClaimTypes.GivenName
and ClaimTypes.Surname
claims or avoiding any security-sensitive decision based on their values.
References
For more information, visit #713.
Acknowledgments
Special thanks to Roy Zhang for his report.
Impact
As encouraged by Apple's non-standard OpenID Connect implementation, the aspnet-contrib Apple provider for ASP.NET Core extracts the email address and the first/last name of the logged in user from a special
user
parameter that is directly returned as part of the authorization response. These values are then used to populate theClaimTypes.Email
,ClaimTypes.GivenName
andClaimTypes.Surname
claims that are added to the resultingClaimsPrincipal
instance.Unfortunately, this parameter is not cryptographically signed and can be easily tampered with by an attacker to inject any forged value. While the email address returned by an external provider should never be used as a lookup identifier, applications doing so could be at risk and may be vulnerable to elevation of privilege attacks.
Patches
This vulnerability has been patched in 3.1.8 and 6.0.10 by removing built-in support for the non-standard
user
parameter. Other versions are no longer supported and won't receive fixes.After applying the fix, developers are encouraged to review their use of these claims and ensure their applications were not targeted by an attacker.
Note: due to an Apple limitation, the
ClaimTypes.GivenName
andClaimTypes.Surname
claims will no longer be populated after migrating to a patched version.Workarounds
While patching remains the recommended action, this security issue can be worked around by removing any use of the
ClaimTypes.Email
,ClaimTypes.GivenName
andClaimTypes.Surname
claims or avoiding any security-sensitive decision based on their values.References
For more information, visit #713.
Acknowledgments
Special thanks to Roy Zhang for his report.