A few years ago (a little over three now to be exact), I brought up what I consider to be a rather obvious (and serious) security issue with the Universal Windows Platform (UWP): The ability to use its WebAuthenticationBroker to phish credentials from a UWP application.
I recently brought this issue back up and it has been confirmed that this is still an issue in UWP. I would consider this a security issue that someone could exploit via a phishing attack, so rather than continue the discussion there I am bringing it here to get better understanding around my perception around it.
Now I am by no means an expert in security, but I love learning about it and I always have my eyes and ears open for scenarios exactly like this one. I am grateful for having found out about this site which is why I am posting this here question now. If I had known about this site back on December 2012 when I originally posted this question, I would have posted my original question here rather than on the MSDN forums (where it was basically ignored and not taken very seriously, in my view).
With that said, my understanding of exploiting this process is as follows:
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.
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.
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.
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.
Deploy the application to the Windows Store. Get users to download it and use it (How exactly? That is where your creativity comes in).
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.
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).
Once you have obtained validated credentials, store the credentials for a later time, or use them for nefarious purposes immediately.
Rule planet Earth with your new-found powers (OK I made this one up).
First off, I would like to verify with certainty that my understanding on the above process is accurate (last step notwithstanding, of course -- or is it?!). Is there something that I am not accounting for that makes this a non-issue?
If I do understand this correctly, it seems like this is a possible security issue with UWP and one that has not been addressed for over three years now. The guidance given from the MSFT CSG is to open a UserVoice vote for this issue. However, it seems to me that a security issue is one you fix and not one that you vote to address.
So my question is: Is this a legitimate concern? Or am I making a big deal about nothing here? Or is there something I have completely misunderstood (quite possible) that makes this a non-issue?
Thank you in advance for any assistance and/or clarification to my understanding around this issue, and around security in general.