Require user interaction on email based link workflows when cross device
Description
Link checkers such as Outlook Safelinks wreak havoc on email based workflows where you send a user a clickable link that will automatically perform an action w/out user interaction.
Example workflows that may be broken by Outlook Safelinks, or other corporate links checkers:
Email based passwordless login
Email verification
Registration verification
Change password (email based reset) when the user has MFA enabled
We have tried to solve this in various ways with some success, but from reports from our clients, Outlook Safelinks may still defeat all of solutions. The ways in which we have tried so solve this is by taking the GET request from the user clicking on a link in an email client, and returning an HTML form and submitting it via JS to convert the GET into a POST. In most cases, web crawlers, or link checkers will perform a HEAD request, optionally followed by a GET request. If that is all the link checker does - this strategy will prevent the link checker from invalidating the URL and the user will still get the desired result.
However, we have had clients demonstrate that Outlook Safelinks is actual performing the GET and submitting the form to cause a POST request to be used before the user is presented the page. This means that the link is invalidated - so the user will end up at a screen indicating the link is no longer valid. This seems really aggressive, and as far as I know Microsoft does not document any legitimate way to defeat this, or indicate that the link should not be followed and submitted. This makes sense to some degree as it would allow a malicious actor to defeat the checks as well.
I believe URLs, or specific domains can be configured as allowed by Outlook in order to bypass these checks. It is not clear to me if this is a complete solution, or if all clients will have the option to configure Outlook this way.
One option would for FusionAuth add a configuration to require user interaction in these workflows in order to cause the link checker to dead end before the link is invalidated.
For example, today the passwordless workflow is as follows:
User requests a passwordless login via a form submit
User receives an email
User clicks a link in the email which performs a GET request to FusionAuth
The GET is converted to a POST and the user is logged in. This request conversion is seamless, and the user is essentially logged in as the result of clicking the link. This is a pretty standard email based passwordless workflow.
We could modify this workflow such that when the user clicks the link, they are taken to a page that requires the user to submit a form to complete the login request. This adds some friction to the process but I think it would make FusionAuth immune to these corporate link checkers.
Link checkers that try to protect users against malicious links in emails will follow links and even execute JavaScript on the destination pages, sometimes invalidating single-use codes used for passwordless login, email verification, and password changes.
This enhancement introduces a new confirmation page in these workflows, which is shown to users when the request from the external link does not originate from the same browser that initiated the original workflow (e.g. clicking on a forgot password link or button).
A default page will be shown to users. If you are using a custom theme, you'll need to copy this new template, named Confirmation required to your theme.
robotdan
commented
4 months ago
Require user interaction on email based link workflows when cross device
Description
Link checkers such as Outlook Safelinks wreak havoc on email based workflows where you send a user a clickable link that will automatically perform an action w/out user interaction.
Example workflows that may be broken by Outlook Safelinks, or other corporate links checkers:
We have tried to solve this in various ways with some success, but from reports from our clients, Outlook Safelinks may still defeat all of solutions. The ways in which we have tried so solve this is by taking the
GETrequest from the user clicking on a link in an email client, and returning an HTML form and submitting it via JS to convert theGETinto aPOST. In most cases, web crawlers, or link checkers will perform aHEADrequest, optionally followed by aGETrequest. If that is all the link checker does - this strategy will prevent the link checker from invalidating the URL and the user will still get the desired result.However, we have had clients demonstrate that Outlook Safelinks is actual performing the
GETand submitting the form to cause aPOSTrequest to be used before the user is presented the page. This means that the link is invalidated - so the user will end up at a screen indicating the link is no longer valid. This seems really aggressive, and as far as I know Microsoft does not document any legitimate way to defeat this, or indicate that the link should not be followed and submitted. This makes sense to some degree as it would allow a malicious actor to defeat the checks as well.I believe URLs, or specific domains can be configured as allowed by Outlook in order to bypass these checks. It is not clear to me if this is a complete solution, or if all clients will have the option to configure Outlook this way.
One option would for FusionAuth add a configuration to require user interaction in these workflows in order to cause the link checker to dead end before the link is invalidated.
For example, today the passwordless workflow is as follows:
GETrequest to FusionAuthGETis converted to aPOSTand the user is logged in. This request conversion is seamless, and the user is essentially logged in as the result of clicking the link. This is a pretty standard email based passwordless workflow.We could modify this workflow such that when the user clicks the link, they are taken to a page that requires the user to submit a form to complete the login request. This adds some friction to the process but I think it would make FusionAuth immune to these corporate link checkers.
Known offenders
Related
Community guidelines
All issues filed in this repository must abide by the FusionAuth community guidelines.
Release notes
Link checkers that try to protect users against malicious links in emails will follow links and even execute JavaScript on the destination pages, sometimes invalidating single-use codes used for passwordless login, email verification, and password changes.
This enhancement introduces a new confirmation page in these workflows, which is shown to users when the request from the external link does not originate from the same browser that initiated the original workflow (e.g. clicking on a forgot password link or button).
A default page will be shown to users. If you are using a custom theme, you'll need to copy this new template, named Confirmation required to your theme.