24 ms·

These days there's also to consider that some Mail Threat Protection Tools (at least Microsoft Defender in Exchange Online does this) click links in Mails to ch

by ctm92 2y ago

These days there's also to consider that some Mail Threat Protection Tools (at least Microsoft Defender in Exchange Online does this) click links in Mails to check them. Recently ran into this issue as new mail accounts got confirmed automatically and magic links were invalid when the user clicked them, because Microsoft already logged in with it during checking.

aspect0545 2y ago
What can you do to prevent automatic confirmation in that case?
- sandermvanvliet 2y ago
  As far as I know there’s nothing. The alternative is to send an OTP in the mail and tell the user to enter that. In that way there is no link to auto confirm. However, if you do that ensure that you have a way to jump straight to the page to enter the OTP because (looking at you Samsung) the account registration process can expire or the app is closed (not active long enough) and your user is stuck
- miohtama 2y ago
  The link leads to a page where you need to press a button (HTTP POST).
- mixedbit 2y ago
  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.
robertlagrant 2y ago
That seems like a really thoughtless idea.
devnullbrain 2y ago
I've had this problem as a user, accidentally previewing a link in iOS by tapping for too long.
- tuetuopay 2y ago
  This is even worse for copying the link. On iOS the contextual menu comes with the preview, which will destroy the magic link.
littlestymaar 2y ago
> These days there's also to consider that some Mail Threat Protection Tools (at least Microsoft Defender in Exchange Online does this) click links in Mails to check them. What an insane policy, why am I surprised Microsoft came up with it…
- sbarre 2y ago
  It's not actually insane if the application hosting the link follows the principle that GET requests should not mutate state. This problem is ~20 years old from when CMS platforms had GET links in the UI to delete records and "browsing accelerator" browser extensions came along that pre-fetched links on pages, and therefore deleted resources in the background. At the time the easiest workaround was to use Javascript to handle the link click and dynamically build a form to make a POST request instead (and update your endpoint to only act on POST requests), before the fetch API came along.
  - littlestymaar 2y ago
    It is insane because it brings literally nothing security-wise (an attacker can easily detect that the link is being opened from something else than an end-user's browser, and not deliver the payload) while actualy compromising the security of their users (by allowing an attacker to know which addresses exist and which do not, which is very useful if you want to attack companies).
    - saagarjha 2y ago
      The idea is that the pre-fetching is done by an environment that looks similar to the end-user's browser.
    - ctm92 2y ago
      It does not only show to attackers that your address exists, it also shows that it is hosted on Microsoft 365 and is ATP is licensed.
TeMPOraL 2y ago
Come to think of it, magic links by definition violate the principle that GET requests should not change state. Defender & preview tools are actually following the established norms here - norms that were established decades ago precisely because we hit the more broad problem with C, U & D parts of CRUD, and collectively agreed that doing destructive operations on GET requests is stupid.
- kragen 2y ago
  You can GET a <form> which POSTs when you click the "log in" button.
  - GTP 2y ago
    Yes, but the GET itself isn't changing any state. The state changes only after clicking on the button. This is OP's point.
    - kragen 2y ago
      TeMPOraL said, "magic links by definition violate the principle that GET requests should not change state". That is a reasonable thing to think, but it is not true, because you can GET a <form> which POSTs when you click the "log in" button, unless you think a link to such a <form> page should be excluded from the definition of "magic link".
      - Jolter 2y ago
        In your example, it seems to me that the POST request is the action that changes the state.
        kragen 2y ago
        Agreed.
      - TeMPOraL 2y ago
        > unless you think a link to such a <form> page should be excluded from the definition of "magic link". Yes. Linking to a form requiring user to press a button to submit an actual POST request is one proper way of doing it, and won't confuse prefetchers, previewers and security scanners - but it lacks the specific "magic" in question, which is that clicking on a link alone is enough to log you in. Can't really have both - the "magic" is really just violating the "GET doesn't mutate" rule, rebranding the mistake we already corrected 20+ years ago. (EDIT: Also the whole framing of "magic links" vs. passkeys reads to me like telling people that committing sins is the wrong way of getting to hell, because you can just ask the devil directly instead.)

by ctm92 2y ago

aspect0545 2y ago

What can you do to prevent automatic confirmation in that case?

sandermvanvliet 2y ago
As far as I know there’s nothing. The alternative is to send an OTP in the mail and tell the user to enter that. In that way there is no link to auto confirm. However, if you do that ensure that you have a way to jump straight to the page to enter the OTP because (looking at you Samsung) the account registration process can expire or the app is closed (not active long enough) and your user is stuck
miohtama 2y ago
The link leads to a page where you need to press a button (HTTP POST).
mixedbit 2y ago
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.

robertlagrant 2y ago

That seems like a really thoughtless idea.

devnullbrain 2y ago

I've had this problem as a user, accidentally previewing a link in iOS by tapping for too long.

tuetuopay 2y ago
This is even worse for copying the link. On iOS the contextual menu comes with the preview, which will destroy the magic link.

littlestymaar 2y ago

> These days there's also to consider that some Mail Threat Protection Tools (at least Microsoft Defender in Exchange Online does this) click links in Mails to check them. What an insane policy, why am I surprised Microsoft came up with it…

sbarre 2y ago
It's not actually insane if the application hosting the link follows the principle that GET requests should not mutate state. This problem is ~20 years old from when CMS platforms had GET links in the UI to delete records and "browsing accelerator" browser extensions came along that pre-fetched links on pages, and therefore deleted resources in the background. At the time the easiest workaround was to use Javascript to handle the link click and dynamically build a form to make a POST request instead (and update your endpoint to only act on POST requests), before the fetch API came along.
- littlestymaar 2y ago
  It is insane because it brings literally nothing security-wise (an attacker can easily detect that the link is being opened from something else than an end-user's browser, and not deliver the payload) while actualy compromising the security of their users (by allowing an attacker to know which addresses exist and which do not, which is very useful if you want to attack companies).
  - saagarjha 2y ago
    The idea is that the pre-fetching is done by an environment that looks similar to the end-user's browser.
  - ctm92 2y ago
    It does not only show to attackers that your address exists, it also shows that it is hosted on Microsoft 365 and is ATP is licensed.

TeMPOraL 2y ago

Come to think of it, magic links by definition violate the principle that GET requests should not change state. Defender & preview tools are actually following the established norms here - norms that were established decades ago precisely because we hit the more broad problem with C, U & D parts of CRUD, and collectively agreed that doing destructive operations on GET requests is stupid.

kragen 2y ago
You can GET a <form> which POSTs when you click the "log in" button.
- GTP 2y ago
  Yes, but the GET itself isn't changing any state. The state changes only after clicking on the button. This is OP's point.
  - kragen 2y ago
    TeMPOraL said, "magic links by definition violate the principle that GET requests should not change state". That is a reasonable thing to think, but it is not true, because you can GET a <form> which POSTs when you click the "log in" button, unless you think a link to such a <form> page should be excluded from the definition of "magic link".
    - Jolter 2y ago
      In your example, it seems to me that the POST request is the action that changes the state.
      - kragen 2y ago
        Agreed.
    - TeMPOraL 2y ago
      > unless you think a link to such a <form> page should be excluded from the definition of "magic link". Yes. Linking to a form requiring user to press a button to submit an actual POST request is one proper way of doing it, and won't confuse prefetchers, previewers and security scanners - but it lacks the specific "magic" in question, which is that clicking on a link alone is enough to log you in. Can't really have both - the "magic" is really just violating the "GET doesn't mutate" rule, rebranding the mistake we already corrected 20+ years ago. (EDIT: Also the whole framing of "magic links" vs. passkeys reads to me like telling people that committing sins is the wrong way of getting to hell, because you can just ask the devil directly instead.)