1

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.

Daniel Phan
  • 227
  • 2
  • 8

2 Answers2

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?

Outlook Add-ins Team - MSFT
  • 8,906
  • 1
  • 9
  • 21
  • 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. – Daniel Phan May 01 '17 at 14:53
0

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.

Marc LaFleur
  • 31,987
  • 4
  • 37
  • 63
  • 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? – Daniel Phan Apr 28 '17 at 14:18
  • 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. – Marc LaFleur Apr 28 '17 at 14:58
  • 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? – Daniel Phan Apr 28 '17 at 16:30
  • Encrypting certainly wouldn't hurt but I'm not sure I follow the IFRAME scenario here. – Marc LaFleur Apr 28 '17 at 16:42
  • 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. – Daniel Phan Apr 28 '17 at 16:55
  • It does not receive them from the host application, it makes a call to the Exchange web service. – Marc LaFleur Apr 28 '17 at 17:13
  • 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? – Daniel Phan May 01 '17 at 16:10
  • 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. – Marc LaFleur May 01 '17 at 16:57
  • So http://stackoverflow.com/a/42033561/7385454 is not actually a concern? – Daniel Phan May 01 '17 at 17:22
  • 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. – Marc LaFleur May 01 '17 at 18:11