Consider Displaying URL/Location/Context to User in UWP Application During Authentication
(Administrator: I am listing this one as a bug, because I consider it a existing security issue that can be exploited at present, but please feel free to categorize it however you see fit, as always!)
There is what I consider a security issue in UWP applications, that I feel should be addressed. Namely, when the user goes to authenticate their application with a 3rd party authentication provider (e.g. Facebook, Google), the control that is used to handle the process does not display the URL to the user, so they do not know where the content is being loaded from and if it is trusted/authentic.
Therefore, malicious parties could use any URL/location they would like under their control for the WebAuthenticationBroker.Authenticate* calls to phish the credentials of users of this process, as users do not see/understand the URL in which the process is loading the content for the authentication workflow and therefore cannot validate its authenticity.
It would be great to see some improvements in this area to show the user exactly where the content is being loaded from, as well as any certificates (green/red/warnings -- the same you see in browsers) so that they get the "warm n' fuzzies" during the sign in process and know that they can provide their credentials in confidence to the application.
For context, here are the steps (as I understand them) that can be used to exploit this process:
1) Create a sign-in page that looks exactly like the signin page from Google or Facebook (or your authentication service provider of choice). For starters, you would create this by going to target provider's login page and saving the source of the file and use that as the starting point.
2) Modify the file made in the previous step so that it takes user input and passes it to the real authentication service provider. Account for when the credentials pass and for when they fail.
3) Find a server to host the above file, deploy the file(s) (perhaps multiple files, as it could involve server-side magic) to this host and get the URL to the deployed location that loads this file.
4) Create a UWP application that gets the user to login to a supported credential provider via the WebAuthenticationBroker. In the WebAuthenticationBroker.AuthenticateAsync call, provide the URL to the deployed location in the previous step.
5) Deploy the application to the Windows Store. Get users to download it and use it (How exactly? That is where your creativity comes in! ;) ).
6) Have the user sign into your page (thinking it is a legitimate credential location -- the one you are impersonating). Since it has been confirmed that UWP and WebAuthenticationBroker does not display the URL/domain the user is signing into, it can be anywhere that is under your control and the user will not know.
7) Validate credentials using the real authentication provider. If it works, pass the user on to the real sign in page (or better yet, simply set cookies on the user's session that makes it seem all is OK).
8) Once you have obtained validated credentials, store the credentials for a later time, or use them for nefarious purposes immediately.
9) Rule planet Earth with your new-found powers (OK I made this one up :) )
For reference, this is based on a thread started in the MSDN forums, which you can see here for additional information:
Thank you for any consideration!
Peter Sinke commented
This needs to be addressed. People are getting more and more scared of entering their login details. It needs to be crystal clear to the user where they are entering the information.
WebAuthenticationBroker is great for developers, now it just needs to be made clear to the user that it's safe to use.