Unable to authenticate from an iframe

[JeromeFR]

Hello,

Since this morning I try to authenticate me for a <iframe>. Friday, I had no problems but now it doesn't work.
I have the following error message in the Chrome console:
Refused to display 'https://www.fitbit.com/oauth/authorize?oauth_token = ...' in a frame Because it set 'X-Frame-Options' to' SAMEORIGIN.

If I try to authenticate me without a <iframe>, it works.

Someone has an idea?

Thanks

[dduffy]

I have just experienced the exact same issue; I can no longer use an Iframe to display the content from FitBit becuase of the header response x-frame-options. Is their a possibility you can implement this reponse header by location rather than for the entire domain. I suspect you want developers to be allowe dto use Iframes for integration, therfore you cant implement such a resticition for all URLs / Locations. Most likely you are attempting to prevent clickJacking with this parameter; but this makes no sense when you want developers to integate fitbit authentication into a web app. As said above you should allow the URi [https://www.fitbit.com/oauth/authorize] an exception on the x-frame-options header.

Any update /  explaination from fitbit developers?

[JeromeFR]

Thanks for your response.

 But how can I do it ?

I have often seen this code in forums:

<?php
    header('X-Frame-Options: GOFORIT');
?>

I try to add this in the page but it doesn't work. Maybe I use wrong.

Thanks

[dduffy]

you cant change this. Instead the FitBit Web Administrators need to make this amendment, its a security setting to prevent clickJacking.

My question is direct to FitBit and I am asking them to make an exception for the specific URL mentioned above to allow iframe usage.

[afirsich]

Is there any update to this?

The developers should have been notified of this change prior to the update.  You have rendered our integration useless and during a holiday week where many people are on vacation, that is unacceptable.

[SunsetRunner]

We are looking into this.

[dduffy]

thanks Dan, much appreciated.

[JeremiahFitbit · Accepted solution]

I'm sorry that your integration has been adversely affected. Fitbit will always prioritize user security and I hope that you can understand our position.

Fitbit began setting the X-Frame-Options header to "SAMEORIGIN" in August 2012. This change was made to prevent "clickjacking" or "UI redress" attacks. (Learn more on OWASP.) We recently learned that this had reverted at some point and re-enabled it.

The authorization page <https://www.fitbit.com/oauth/authorize> allows Fitbit users to authenticate. We will not remove the X-Frame-Options header on this page for this reason.

The recommended and officially supported integration for web applications has always been to redirect the user away from your application to the authorization page in the primary browser window or a pop-up. The authorization page then redirects the user back to your application.

Iframes are not and have never been an officially supported integration method. We pre-announce backwards-incompatible changes for recommended and supported integration methods 30 or more days in advance. In situations where a security vulnerability could be exploited, we carefully review risk and user experience. As always, we welcome your feedback and suggestions.

[dduffy]

thanks for the update.

I do have a few points, I am a security Advocate who is familiar with OrangeBook, Saltzer & Schroeder principles, and strongly encourages younger developers to read  Craft of System Security by the very knowledgeable educators in Dartmouth 

1. from a user experience; iFrame is a better experience. its crap user experience to open a new browser window.

2. I am very familiar with OWASP; x-frame-options is an excellent approach which most modern browsers implement to some extent. However you raise the point of user security is always prioritized; this is already evident by requiring your authorization page to run 3 legged oAuth and by definition this is  SSL/TLS. Therefore it is reasonable to question the need to x-frame-options for this specific URi. Also, question why x-frame-options went and implemented allow-from in more recent approaches effectively implementing SAMEORIGIN approach but with a whitelist. This means "someone" thinks its better to use iFrame in some cases. 

3. As you have raised user security is prioritized, I cant agree fully with your point, simply because you accept REST APIs via HTTP mode when getting user content rather than HTTPS mode. if you truly believed user security outways everything then you would implement HTTP  mode ?

I therefore still believe x-frame-options is unnecessary in this instance for the URI in question.

 <https://www.fitbit.com/oauth/authorize>

[JeromeFR]

Hello,

Thanks a lot for yours responses. In the end, I use the recommended method (open popup) that works without problems.

Jerome

[JeremiahFitbit]

---

@dduffy wrote:

1. from a user experience; iFrame is a better experience. its crap user experience to open a new browser window.

---

We believe redirects and pop-up windows for authorization to be required for user security. I am unaware of any UX research that suggests the window method of the authorization prompt influences behavior.

---

@dduffy wrote:

2. I am very familiar with OWASP; x-frame-options is an excellent approach which most modern browsers implement to some extent. However you raise the point of user security is always prioritized; this is already evident by requiring your authorization page to run 3 legged oAuth and by definition this is  SSL/TLS. Therefore it is reasonable to question the need to x-frame-options for this specific URi. Also, question why x-frame-options went and implemented allow-from in more recent approaches effectively implementing SAMEORIGIN approach but with a whitelist. This means "someone" thinks its better to use iFrame in some cases.

---

Please review how a clickjacking or UI redress attack works. If X-Frame-Options is not sent, an attacker could display the <https://www.fitbit.com/oauth/authorize> page in an iframe, overlay a div with input fields styled to be invisible to the user, and capture a Fitbit user's email and password. We believe that any page with user input should be served with the X-Frame-Options header set to SAMEORIGIN, especially those where user credentials and account modification are input.

We are not considering implementing an option for third-party app developers to whitelist themselves, as an attacker could use this feature to whitelist their attack.

---

@dduffy wrote:

3. As you have raised user security is prioritized, I cant agree fully with your point, simply because you accept REST APIs via HTTP mode when getting user content rather than HTTPS mode. if you truly believed user security outways everything then you would implement HTTP  mode ?

---

The Fitbit API launched publicly in 2011. We have recommended use of, but not required, HTTPS since 2013. We currently are reviewing a migration strategy for HTTPS as an API integration requirement.

OAuth 1.0a is required to use the Fitbit API.

OAuth 1.0a requests that are not signed and use PLAINTEXT must use HTTPS. PLAINTEXT is a supported, but deprecated and not recommended implementation.

If requests are signed with HMAC-SHA1, they can be sent without TLS. The requests are trusted because they are signed with a user access token secret and client secret that only the client and Fitbit API know. The values sent could be intercepted by a man-in-the-middle attack, but not modified or replayed.

[dduffy]

thanks Jeremiah for taking the time to answer my points. I still standby; if you lock down some of the poor approaches in oAuth on top of SSL/TLS you dont need x-frame-options, i.e. if you follow the recommened approaches to oAuth as you have outlined then x-frame-options is not required.

Do you truely believe pop-ups via new windows is a better user experience or even at the same user experience level as a pop up div / x-frame? Show me how many new more modern sites use alert() v's some toastWindow implementation. Or show me a SaaS implementation where popup windows in new tabs are used. I dont think you will find many.

Anyway we could debate for a while; we will have to agree to disagree on this one. I will proceed to implement without iFrames.

[JeremiahFitbit]

---

@dduffy wrote:

I still standby; if you lock down some of the poor approaches in oAuth on top of SSL/TLS you dont need x-frame-options, i.e. if you follow the recommened approaches to oAuth as you have outlined then x-frame-options is not required.

---

The OAuth 2.0 spec explicitly says to not use iframes and to send the X-Frame-Options header set to deny or sameorigin: http://tools.ietf.org/html/rfc6749#section-10.13

[...am]

"><iframe>https://scanme.nmap.org:22