Cookies are specifically separated out per-domain. Your browser will not give a random website access to your auth cookies/localstorage for other websites. There are some awful companies which do set cross-website cookies (e.g. facebook, google, and other adware), but (1) those cookies are not auth credentials and are used mostly for fingerprinting and ad targeting, (2) should be filtered out by your browser’s tracking protection (hence “if your browser is set up correctly”).
Realistically there is still be a way for the website to fingerprint you enough to know who you are even without cookies, so the most adversarial outcome from clicking a link is that the attacker can know that you clicked that link, along with your general location (from geoIP) and some device info.
iirc that’s how the linux tech tips channel got into trouble.
Nah, that was pretty much an .exe sent out by a fake sponsor, which was downloaded and executed. It then stole all browser data (including google auth cookies). Opening a link ≠ running an unsandboxed exe.
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.
Cookies are specifically separated out per-domain. Your browser will not give a random website access to your auth cookies/localstorage for other websites. There are some awful companies which do set cross-website cookies (e.g. facebook, google, and other adware), but (1) those cookies are not auth credentials and are used mostly for fingerprinting and ad targeting, (2) should be filtered out by your browser’s tracking protection (hence “if your browser is set up correctly”).
Realistically there is still be a way for the website to fingerprint you enough to know who you are even without cookies, so the most adversarial outcome from clicking a link is that the attacker can know that you clicked that link, along with your general location (from geoIP) and some device info.
Nah, that was pretty much an .exe sent out by a fake sponsor, which was downloaded and executed. It then stole all browser data (including google auth cookies). Opening a link ≠ running an unsandboxed exe.
Linux tech tips guy opening a .exe file is oddly frustrating to me.
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.