DUNA. Prevent phish attack in “switch_browser” flow. , Fixes AB#3250169

[p3dr0rv]

DOC: https://microsoft-my.sharepoint-df.com/:w:/r/personal/sedemche_microsoft_com/_layouts/15/Doc.aspx?sourcedoc=%7B29055A71-DD9A-4E95-9E2D-6DBFB77F7823%7D&file=DUNA-switch_browser-phish%20attack.docx&action=default&mobileredirect=true&share=IQFxWgUpmt2VTp4tbb-3f3gjAb1Z62agYgf-0Tl4zsGqDBE

The document highlights a security vulnerability where malicious applications can exploit the "switch_browser" and "switch_browser_resume" endpoints, leading to phishing attacks through mimicked UI pages. The proposed mitigations include adding a state parameter to prevent such attacks, ensuring that both actions occur within a valid authentication flow.

This state parameter allows the client application to validate the actions, by comparing the state in the in the authorization request against the state in the response (broker redirect).

AB#3250169

[github-actions]

❌ Work item link check failed. Description does not contain AB#{ID}.

Click here to Learn more.

[github-actions]

✅ Work item link check complete. Description contains link AB#3250169 to an Azure Boards work item.

[shahzaibj]

Is it possible to put this change behind a separate flight? I'm thinking just in case client changes for state go to prod before server changes then it would be good to have the ability to turn off just this flight and test the rest of the switch browser protocol.

Not necessary to put the whole change behind a flight but just the parts of code that validate the state and/or take a hard dependency on state param being present. Essentially turning off the flight should allow the flow to work (no exception thrown) even if state param is not returned by server. So client code can essentially proceed with assuming an empty string state param.