WilliamI.07520 (Customer) asked a question.
We have a custom User Activation email set up via
Admin > Settings > Email&SMS > Email > User Activation
That uses a URL like this to activate the user
href="${baseURL}/activate-account/${activationToken}?email=${user.login}"
My understanding is that that is is an OKTA API that is being hit here.
My issue is this - When this email gets sent to a user using Outlook.com who has "Bing preview" security set up as per
https://stackoverflow.com/questions/41699071/bingpreview-invalidates-one-time-links-in-email
Then Bing follows this email link. This causes the user to be activated without the user having actually logged in and clicked the link themselves.
This is a security issue - any user can activate any outlook.com email address that they do not have access to.
The issue seems to me to be one for Okta to fix if I understand correctly. The service at the end of the URL ${baseURL}/activate-account/${activationToken}?email=${user.login}" should implement code as described in
https://stackoverflow.com/questions/41699071/bingpreview-invalidates-one-time-links-in-email
to block activations from this automated system.
Is my understanding correct, and if so, does Okta have a plan to fix this?
Thanks for any help
Will
Hello William,
If this is indeed an issue, which would be news to us as we never received reports of such an occurrence, the issue would actually be in Microsoft's territory to fix, since they are employing BingPreview.
While it is true that an activation link is only valid until it's used for the first and only time, changing this behavior from our side would compromise our security posture.
If you happen to have an example case where this occurred, I recommend opening a case with Okta Support.
Hi @sebastian.petroi1.5665717802357122E12 (Vendor Management)
Thanks for the reply.
This is definitely an issue.
There is another thread discussing it here - https://stackoverflow.com/questions/62108517/clicking-outlook-safelink-protection-links-in-emails-seems-to-be-executing-the-c
Looks like people tend to work around this issue. It would be really nice if Okta made it so that we do not have to.
The solution there sounds quite simple
The Okta activation service on the end of the activation URL would check the HTTP method being used on the incoming request and only action it if it's a GET; returning a 405 Method Not Allowed status or similar if it's something else.
I would be so very grateful if you would consider this.
@sebastian.petroi1.5665717802357122E12 (Vendor Management) I don't agree that this is Microsoft's issue.
Many companies and email providers are implementing security bots to protect the mailboxes of their users.
In Microsoft's case it's very easy to distinguish if a BOT is checking the URL as it is making an HTTP HEAD request, Okta should not be performing account activation on HEAD requests (as it's certainly not a user's action), and only activate an account on a GET request (that is more likely to be originating from an actual browser).
Of course, other security bots may be more difficult to detect, but still, it is your activation process that is allowing the activation to happen in the background without direct users' interaction (which is kind of making the whole activation pointless).