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
userparameter that is directly returned as part of the authorization response. These values are then used to populate theClaimTypes.Email,ClaimTypes.GivenNameandClaimTypes.Surnameclaims that are added to the resultingClaimsPrincipalinstance.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
userparameter. 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.GivenNameandClaimTypes.Surnameclaims 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.GivenNameandClaimTypes.Surnameclaims 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.