This works because loggin in to outlook sets a cookie for login.microsoftonline.com which is reused by other Microsoft products. Each product requests a token from login.microsoftonline.com and as long as you have a valid cookie for that domain it will return a token that the app (outlook/teams/onedrive/etc) can use to access its own api.
The cookie itself stays bound to login.microsoftonline.com and it’s never shared with other domains and the service at login.microsoftonline.com will not provide tokens to requests from non-microsoft domains.
all i can say is that i need to log into outlook to log into teams, because logging into teams directly is broken, but the cross site cookie work…
Thankfully I don’t even have an MS account, but I do implore you to check out the cookies and see for yourself that they will have a specific list of domains they are valid for.
Open the browser developer menu on an Outlook tab (F12), navigate to “Storage” → “Cookies” (may be named slightly differently in different browsers), and look at the “Domain” column in the table.
and reading stuff like adFection really doesn’t instill confidence in opening random websites.
The problem there is website operators selling their adspace to a literal israeli spyware company, which meant injecting adversarial javascript into their own pages. It was not a case of “user opening a random link”, rather it was the website operator themselves forwarding the user malicious JS from the “ad company”. As a user there’s generally nothing you can do to prevent this kind of attack where the website itself was compromised; besides, without another vulnerability/attack vector the impact will be limited to the website in question.
all i can say is that i need to log into outlook to log into teams, because logging into teams directly is broken, but the cross site cookie work…
and reading stuff like adFection really doesn’t instill confidence in opening random websites.
but most probably you’re right for most cases.
This works because loggin in to outlook sets a cookie for login.microsoftonline.com which is reused by other Microsoft products. Each product requests a token from login.microsoftonline.com and as long as you have a valid cookie for that domain it will return a token that the app (outlook/teams/onedrive/etc) can use to access its own api.
The cookie itself stays bound to login.microsoftonline.com and it’s never shared with other domains and the service at login.microsoftonline.com will not provide tokens to requests from non-microsoft domains.
Thankfully I don’t even have an MS account, but I do implore you to check out the cookies and see for yourself that they will have a specific list of domains they are valid for.
Open the browser developer menu on an Outlook tab (F12), navigate to “Storage” → “Cookies” (may be named slightly differently in different browsers), and look at the “Domain” column in the table.
The problem there is website operators selling their adspace to a literal israeli spyware company, which meant injecting adversarial javascript into their own pages. It was not a case of “user opening a random link”, rather it was the website operator themselves forwarding the user malicious JS from the “ad company”. As a user there’s generally nothing you can do to prevent this kind of attack where the website itself was compromised; besides, without another vulnerability/attack vector the impact will be limited to the website in question.