Unverified Sign in with Apple callback parameter can override verified ID token claims

## Summary Acceptance of Extraneous Untrusted Data With Trusted Data vulnerability in the Sign in with Apple strategy in pow-auth Assent allows an unauthenticated remote attacker to impersonate another user via the `user` parameter of the authorization callback. Apple posts the user's name to the callback endpoint in a `user` form parameter that the browser submits and the client controls. `Assent.Strategy.Apple.callback/2` in `lib/assent/strategies/apple.ex` decodes that parameter, and `fetch_user/2` merges it over the claims of the verified ID token, so the unverified map wins. An attacker who completes a Sign in with Apple login with their own Apple ID and edits the `user` parameter can replace `sub`, `email`, and any other claim. Applications that look up, link, or authorize accounts by the returned subject or email then act on the attacker's values. This issue affects assent: from 0.1.25 before 0.3.2. ## Details **1. Unverified input.** Apple's `form_post` response mode delivers `code`, `id_token`, `state`, and on the first authorization a `user` parameter that holds a JSON object with the user's name and email. The browser submits this parameter and Apple does not sign it, so the client controls its content. **2. Merge over verified claims.** `Assent.Strategy.Apple.callback/2` decodes the `user` parameter with `Helpers.decode_json/2` and stores the map in the config under `:user`. After `Assent.Strategy.OIDC.fetch_user/2` has validated the ID token, `Assent.Strategy.Apple.fetch_user/2` calls `Map.merge/2` with the verified claims first and the decoded parameter second. Keys from the parameter overwrite keys from the token, including `sub` and `email`. **3. Result.** `normalize/2` reads `sub` and `email` from the merged map and sets `email_verified` to true, so the application receives attacker-chosen identity fields marked as verified. **4. Fix.** Version 0.3.2 ignores the parameter by default. With `include_unverified_name: true`, only `given_name` and `family_name` are taken from it, and the verified claims are merged over them. ## Proof of concept 1. Start the Sign in with Apple flow of an application that uses `Assent.Strategy.Apple`. 2. Authenticate at Apple with an Apple ID the attacker controls. 3. Intercept the `form_post` request to the application's callback URL and set the `user` parameter to a JSON object that carries the victim's values, such as `{"sub": "<victim subject>", "email": "victim@example.com"}`. 4. The application calls `Assent.Strategy.Apple.callback/2`. It validates the attacker's ID token and returns a user map whose `sub` and `email` are the victim's values, with `email_verified` set to true. ## Impact An attacker with any Apple ID can sign in to an application that uses the Apple strategy as any other user whose Apple subject or email they know. Account lookup, account linking, and email-based access control then act on the attacker-chosen identity. ## Workarounds Remove the `user` parameter from the callback parameters before you pass them to `Assent.Strategy.Apple.callback/2`, for example with `Map.delete(params, "user")`. Without the parameter, `decode_user_params/2` yields an empty map and the verified ID token claims pass through unchanged. The user's name is then unavailable, because Apple delivers it only through this parameter.