0

I'm currently writing an Outlook Add-in and was implementing clickjacking protection by showing the user a confirmation pop-up window before they complete a potentially dangerous action in the add-in.

It doesn't seem necessary to show these pop-ups when my add-in is running outside of a browser, though (e.g. in Outlook for Mac, or Outlook 2016).

Is there a way to detect whether my add-in is running in a browser vs. running in a native app? I've thought about inspecting the user-agent, but that seems a little fragile.

Edit: This is not the same question as Trusted way to get the host origin of an Office add-in because this question is about whether the add-in is being iframed at all, whereas being iframed is one of the starting assumptions in Trusted way to get the host origin of an Office add-in.

Community
  • 1
  • 1
Daniel Phan
  • 227
  • 2
  • 8
  • Possible duplicate of [Trusted way to get the host origin of an Office add-in](http://stackoverflow.com/questions/43667426/trusted-way-to-get-the-host-origin-of-an-office-add-in) – Outlook Add-ins Team - MSFT May 04 '17 at 21:16

3 Answers3

3

https://dev.outlook.com/reference/add-ins/Office.context.mailbox.diagnostics.html#hostName

HostName should be either: Outlook, Mac Outlook, OutlookIOS, or OutlookWebApp

Outlook Add-ins Team - MSFT
  • 8,906
  • 1
  • 9
  • 21
  • Thanks! Is it possible that a malicious page could fake those values? – Daniel Phan Apr 26 '17 at 21:01
  • Would you mind describing the malicious page or attack scenario that you have in mind? – Outlook Add-ins Team - MSFT Apr 26 '17 at 21:34
  • The scenario I had in mind was that a malicious site can iframe my add-in and tell the Office.js SDK that the HostName is `Outlook`. Then, my add-in wouldn't show the popup (because the SDK would tell my add-in that it was not being run inside a browser), leaving the user vulnerable to a clickjacking attack. – Daniel Phan Apr 28 '17 at 14:20
  • Your question looks like a dupe of http://stackoverflow.com/questions/43667426/trusted-way-to-get-the-host-origin-of-an-office-add-in. Looks like you got your answer on the other post. – Outlook Add-ins Team - MSFT May 04 '17 at 21:15
0

You could use the OfficeJsHelpers to detect the platform info (online vs. PC vs. Mac, etc.), as described in In Excel Online, OfficeJS API is not passing the host_Info_ parameter anymore to Excel Add-In

That being said, if your concern is about a malicious host, they could just as well fake that behavior to return that the browser is in fact an add-in running on a PC version of Office.

Community
  • 1
  • 1
Michael Zlatkovsky - Microsoft
  • 8,424
  • 1
  • 33
  • 46
  • Thanks! I'm assuming the values at https://dev.outlook.com/reference/add-ins/1.1/Office.context.mailbox.diagnostics.html could be faked as well? – Daniel Phan Apr 26 '17 at 20:53
  • I don't have firsthand knowledge of that code, but I would 99% assume so. The add-in (and Office.js) only gets this info based on some parameter inputs that happen during initialization (whether via attributes on the iframe, on the URL, or whatever else). In all of these cases, it seems fake-able. – Michael Zlatkovsky - Microsoft Apr 26 '17 at 21:35
  • But to pop up one level: What is the exact scenario you're trying to achieve (or the exact attack vector you're trying to prevent)? – Michael Zlatkovsky - Microsoft Apr 26 '17 at 21:36
  • 1
    Basically my goal is to not show the clickjacking popups when the add-in is running inside a native host. As you described, the scenario I'm trying to protect against is where my add-in doesn't show the clickjacking protection popup because it thinks it's running on a native host, but in actuality, it's running in a browser on a malicious host page. I could imagine that detecting the host via a user-agent or origin from a postMessage would be possible to do securely, though. – Daniel Phan Apr 27 '17 at 15:27
0

I just check whether window.self === window.top to decide whether or not I should show the clickjacking protection popups.

Daniel Phan
  • 227
  • 2
  • 8