Trusted way to get the host origin of an Office add-in

Question

I'm currently implementing an Outlook Add-in. It shows the user a pop-up window whenever the user is about to complete a potentially dangerous action, to protect against clickjacking attacks.

I was hoping not to have to show the user the pop-up window every time they use the add-in -- only the first time they use it from a new host origin. Is there a way to get the verified host origin of an Office add-in, so I can remember that the user trusts it for next time?

Right now I'm listening for the postMessages from the host (e.g. https://outlook.office.com) to the Office.js SDK and looking at the origin on the MessageEvents, but seems very fragile.

Lionize

Answer 1

I'm interested in knowing more about the vector of attack that you are describing here. Is it someone creating https://evilspoof/ and hosting your web app inside an iframe there. Then getting an end user to go to https://evilspoof/ and click on some things inside your add-in?

Are you authenticating your users in some way? And worried that if they log into your website legitimately...then when they go to the malicious site, they are already signed in, and thus clicks/actions on your page will work since they are already authenticated?

You may want to look at: https://dev.outlook.com/reference/add-ins/Office.context.mailbox.html#getUserIdentityTokenAsync

And associate the token when you log into the site. This call will go to the Exchange Server and give you back an identity token, that you can associate with the login. If the user logs in through OWA/Outlook, you can associate the token. When they go to the malicious site, they can spoof getUserIdentityToken, but the token returned will be different. And the user will be forced to re-enter their credentials. If the user re-enters credentials at that point, then you could be hosed. Or if the user only ever used the malicious spoofed site (and never the real one), then you would have problems...but if the user is entering their login into a spoofed site...doesn't the attacker have their login information anyway?

Prentiss

Yep, that is the scenario that I am trying to defend against. Currently, the add-in reuses the session cookie that I'm using on the rest of my website. Logging the user in via the token from getUserIdentityTokenAsync is something I was planning to do later, but I hadn't yet considered how it might help with a clickjacking attack, thanks! For now, I think storing an encrypted/unguessable turn-clickjacking-protection-off token in RoamingSettings, as suggested above by Marc LaFleur, is a working solution, which can be replaced by the getUserIdentityTokenAsync solution you described. – Lionize

Answer 2

Take a look at Roaming Settings. These settings are stored within the user's mailbox so they will follow them around regardless of the client they are using.

Siberson

Since I'm using the origin to avoid showing clickjacking protection, I'm not sure that roaming settings is appropriate. Couldn't a malicious site fake the roaming settings? – Lionize

The data is stored on the user's Exchange mailbox, and is accessible when that user logs into his or her account and runs your add-in. It is not accessible by another add-in. – Siberson

Not sure that other add-ins are relevant. In the scenario where I store dont_show_clickjacking_protection_popup = true in roaming settings, it seems like a malicious site could iframe my add-in and trick the Office SDK into returning the above from Office.context.roamingSettings.get. If I were to encrypt the value before putting it in RoamingSettings, it would certainly help (because the attacker wouldn't be able to guess at which value they have to put into the fake roaming settings in order to get my add-in to not show clickjacking protection). Is that what you're suggesting? – Lionize

Encrypting certainly wouldn't hurt but I'm not sure I follow the IFRAME scenario here. – Siberson

How does the Office.js SDK running on my add-in page know that the host page (the one framing my add-in) is actually a legitimate Outlook Web App, and not a malicious web site? I was under the impression that it doesn't -- which would mean that the RoamingSettings it receives from the host page cannot be trusted. – Lionize

It does not receive them from the host application, it makes a call to the Exchange web service. – Siberson

Hmm on thinking about this a little more -- doesn't the Office.js SDK get the EWS URL from the host application? How does it verify that the EWS instance isn't malicious? – Lionize

Add-ins for Outlook run within an Exchange context, they are installed and launched on the server. If your concerned about a false Exchange server, no pop-up would protect against that deep of an attack. – Siberson

So https://mcmap.net/q/1924752/-prevent-clickjacking-using-office-js is not actually a concern? – Lionize

Only in that you should validate that the user prior to showing sensitive information as in the end, your add-in is just a web page your hosting. I would be less concerned about someone setting up a fake Exchange server, getting users to switch to that Exchange server and then specifically faking your add-in. – Siberson