29 ms·

I run an authorization service that allows to log-in using magic links and we managed to solve this. First approach was for the link opening GET request to do n

I run an authorization service that allows to log-in using magic links and we managed to solve this. First approach was for the link opening GET request to do not log the user in, but to include an HTML page with JavaScript that issued a POST request with a code from the link to log the user in. This worked well for a long time, because email scanners were fetching links from emails with GET requests but did not execute JavaScript on the fetched pages. Unfortunately, some time ago Microsoft tools indeed started to render the fetched pages and execute JavaScript on them which broke the links. What works now is to check if the link is open in the same browser that requested the link (you can use a cookie to do it) and only automatically login the user in these cases. If a link is open in a different browser, show an additional button ('Login as <email address>') that the user needs to click to finish the login action. MS tools render the login page but do not click buttons on it. The issue that MS tools introduced is broader, because it affects also email confirmation flows during signups. This is less visible, because usually the scanners will confirm emails that the user would like to confirm anyway. But without additional protection steps, the users can be signed up for services that they didn't request and MS tools will automatically confirm such signups.

szszrk 2y ago
> check if the link is open in the same browser that requested the link (you can use a cookie to do it) and only automatically login the user in these cases. If a link is open in a different browser, show an additional button ('Login as <email address>') that the user needs to click to finish the login action. Thanks for checking if it's the same browser. Some companies don't care about that (cough booking cough) so harmful actors just spam users with login attempts in hope a user will click by accident. And puff, random guy gets full access to your account. I got those every day, if I ever needed to login this way I would not be able to figure out which request is mine.
- vanviegen 2y ago
  Wouldn't that just log you in on the browser doing the clicking, instead of the attackers browser?
  - szszrk 2y ago
    You mean in the booking example? They logged in the browser that... requested access. So basically anyone that knew your login/email. I think it should check if browser requesting is the same as the one confirming, or just drop that whole dumb mechanism entirely.
keskival 2y ago
Ok, what if an email has "click this link if it was you who tried to log-in", or "if it wasn't you"? Will Microsoft automatically authenticate malicious actors, or block yourself from services built with assumptions that the email client won't auto-click everything?
- mixedbit 2y ago
  Login links from my service were automatically clicked and rendered and I know that other services discovered similar problems. Based on this I think that it is very likely the case with all the links in emails, but I don't know if there is any additional heuristic involved that would treat some links differently. See also this issue which suggests that all links are opened: https://techcommunity.microsoft.com/discussions/microsoftdefenderforoffice365/possible-major-problem-with-ms-defender-scanningclicking-links/3874918 https://techcommunity.microsoft.com/discussions/microsoftdef... Note that this doesn't affect all Outlook users, this Microsoft Defender for Office 365 is a separate product that only some companies use.
pmontra 2y ago
> But without additional protection steps, the users can be signed up for services that they didn't request and MS tools will automatically confirm such signups. Indeed it's a bad thing but how bad? The admins of some web service get a database of emails, send them those registration links, make their mail software create the accounts and? They end up with a service with accounts that they could create without sending those emails, before they send some emails to solicit users to perform some action on their (long forgotten?) account. There is no additional threat unless I'm missing something. The admins have only an extra thin layer of protection because of the confirmation step but I think that any court can see through it.
- mixedbit 2y ago
  The exploitation and potential damage would be service specific. Say a Dropbox like service for computer file syncing: An attacker creates an account for 'alice@example.org' and gets the signup email automatically confirmed. The attacker uploads some malware files to the account. After some time Alice attempts to create a valid account and resets password for 'alice@example.com'. Then Alice installs a desktop file syncing client provided by the service and malware files from the attacker get downloaded to her machine. Another example would be if a company hosted a web app for employees that allowed signups only from @company.com addresses. In such case an attacker could be able to signup with such an address.
  - pmontra 2y ago
    You are right. I didn't think about 3rd parties creating accounts on a service they don't control.
- aftbit 2y ago
  It defeats the email verification entirely. If that weren't necessary for something, why would the site require it?
ku1ik 2y ago
That check for the same browser is a great idea. Thanks!
- saagarjha 2y ago
  This can be annoying when you intentionally want to log in to a browser that is not the one making the request, such as an in-app browser.

szszrk 2y ago

> check if the link is open in the same browser that requested the link (you can use a cookie to do it) and only automatically login the user in these cases. If a link is open in a different browser, show an additional button ('Login as <email address>') that the user needs to click to finish the login action. Thanks for checking if it's the same browser. Some companies don't care about that (cough booking cough) so harmful actors just spam users with login attempts in hope a user will click by accident. And puff, random guy gets full access to your account. I got those every day, if I ever needed to login this way I would not be able to figure out which request is mine.

vanviegen 2y ago
Wouldn't that just log you in on the browser doing the clicking, instead of the attackers browser?
- szszrk 2y ago
  You mean in the booking example? They logged in the browser that... requested access. So basically anyone that knew your login/email. I think it should check if browser requesting is the same as the one confirming, or just drop that whole dumb mechanism entirely.

keskival 2y ago

Ok, what if an email has "click this link if it was you who tried to log-in", or "if it wasn't you"? Will Microsoft automatically authenticate malicious actors, or block yourself from services built with assumptions that the email client won't auto-click everything?

mixedbit 2y ago
Login links from my service were automatically clicked and rendered and I know that other services discovered similar problems. Based on this I think that it is very likely the case with all the links in emails, but I don't know if there is any additional heuristic involved that would treat some links differently. See also this issue which suggests that all links are opened: https://techcommunity.microsoft.com/discussions/microsoftdefenderforoffice365/possible-major-problem-with-ms-defender-scanningclicking-links/3874918 https://techcommunity.microsoft.com/discussions/microsoftdef... Note that this doesn't affect all Outlook users, this Microsoft Defender for Office 365 is a separate product that only some companies use.

pmontra 2y ago

> But without additional protection steps, the users can be signed up for services that they didn't request and MS tools will automatically confirm such signups. Indeed it's a bad thing but how bad? The admins of some web service get a database of emails, send them those registration links, make their mail software create the accounts and? They end up with a service with accounts that they could create without sending those emails, before they send some emails to solicit users to perform some action on their (long forgotten?) account. There is no additional threat unless I'm missing something. The admins have only an extra thin layer of protection because of the confirmation step but I think that any court can see through it.

mixedbit 2y ago
The exploitation and potential damage would be service specific. Say a Dropbox like service for computer file syncing: An attacker creates an account for 'alice@example.org' and gets the signup email automatically confirmed. The attacker uploads some malware files to the account. After some time Alice attempts to create a valid account and resets password for 'alice@example.com'. Then Alice installs a desktop file syncing client provided by the service and malware files from the attacker get downloaded to her machine. Another example would be if a company hosted a web app for employees that allowed signups only from @company.com addresses. In such case an attacker could be able to signup with such an address.
- pmontra 2y ago
  You are right. I didn't think about 3rd parties creating accounts on a service they don't control.
aftbit 2y ago
It defeats the email verification entirely. If that weren't necessary for something, why would the site require it?

ku1ik 2y ago

That check for the same browser is a great idea. Thanks!

saagarjha 2y ago
This can be annoying when you intentionally want to log in to a browser that is not the one making the request, such as an in-app browser.