0

Authentification provider X is used by many non-related websites like A, B and C as (sole) authentification provider. X therefor provides a framework for athentification which includes a login form via an iframe into the website of A (or B/C) where the user puts in his credentials. (A/B/C are hosted under their own, unrelated domain.) Then the user clicks login and if the credentials for X are correct, he is authentificated for website A (or B/C). Alternatively he can click to open a new window from an URL from website X and enter his credentials there (he has to do this for every login).

In my opinion an attacker could make a website like a gaming forum G faking to use X for authentification and fake the iframe and send the entered credentials from user U to his own server and use the credentials of U to authentificate himself at A/B/C as U. U has no clue that they will be used to authentificate against A and not against G as they are the same and A and G are unrelated.

I told X about this but they just answered that entering the credentials outside their own website (outside includes the iframe) would be against their terms of usage but would have to use the new window version and so they don't consider it a security hole. It didn't matter that I showed them prove that nobody used the new window version in the last months (including their own staff).

Therefore I want to know if there is a guideline whether this is considered (in)secure?

(X is mostly used by websites in the areas of HIPA, financial data, sensitive personal information and X promotes himself as very secure for those but also normal areas)

Edit: I don't want to use the framework but I am a (forced) user like many others of the websites A and B and data about me are stored on C and concerned about my security and the security of my data.

  • I never used paypal so I don't know how it is done there. But in my example the attacker sets up a totally unrelated website like a gaming forum G using X but uses the credentials to access HIPA-site A as U. U has no clue that they will be used to authentificate against A and not against G as they are the same and A and G are unrelated. – H. Idden Jan 4 '16 at 22:18
  • The least they could have done is to add X-Frame-Options: SAMEORIGIN header to prevent iframe embedding. – Lie Ryan Jan 5 '16 at 0:15
  • @LieRyan The embedding as iframe is done by their framework to embed in other websites and is by design so X-Frame-Options: SAMEORIGIN would enterily disable it – H. Idden Jan 5 '16 at 0:19
  • 1
    try making responsible disclosure. Report the issue privately to the authentication provider, and then to users of their authentication service, clearly state that you will be taking this to public disclosure if they do not make reasonable attempt to fix it within a reasonable time frame (this could take months). If they do not respond well to this, then it is the responsible thing to do to disclose the security issue publicly so that everyone can avoid their service. – Lie Ryan Jan 5 '16 at 0:49
  • 1
    You might want to privately discuss this with another security expert though, for a second opinion of whether the issue is actually a security issue, and who can take over or guide you through the technical and legal process of responsible disclosure if you're not comfortable doing it yourself. – Lie Ryan Jan 5 '16 at 0:49
2

I think you see the problem that the user does not know how and where the login form gets submitted without actually inspecting the source code. And that it would be much better if there would be a separate window so that the user can see the URL, ideally together with a trusty looking green bar for https EV certificates.

And although this does not guarantee that the data are actually submitted to this site (i.e. XSS attacks or similar might affect the target or it might be a different target from start) it is better for the user if the same URL is displayed on all logins to the site because this way it can be easier checked if this is the same site as last time and thus if it is still trustworthy.

Therefore I agree with you that this is a usability problem which might make phishing easier and is thus a security problem too. You might point out in your argumentation against X that sites like Paypal never let their login dialogs be embedded into iframes but instead always want to have their own window with the trusty locking green bar and the familiar URL. And they actually teach users to watch out for these signs to detect phishing sites.

  • Thanks for the Paypal example :) I already told them similar but they said that this is of no concern to them as it would not be allowed to enter the credentials into the iframe by their terms of usage. – H. Idden Jan 4 '16 at 23:06
  • But at least the Paypal example will make a good point at them – H. Idden Jan 4 '16 at 23:23
-1

You have a lot in your brief explanation, and I think a little more guidance might help.

An iFrame is nothing more than an HTML tag which allows you to embed "documents" into your web page -- in your instance viewing a web page. There are some criticism on this method, but the concept isn't necessarily insecure.

The first thing that needs to be determined is who is responsible for the embedded iFrame. Is it done in house, third party built, off the self product?

Next, has it the application been tested (not the Authentication Application, but they should be able to give a report of compliance that is has if they are worth anything), but has your website that uses the iFrame, by either a team you hired, a third party hired, or the OOTB company hired tested the applicaiton?

Do you have a choice? I personally like to see a redirect to the Authentication Site and have them redirect back to the application.

Does the Authentication Application give you specifics on how to imbed the iFrame? If the application is designed for integration into other application, there is usually dev docs on the subject.

  • I don't want to use the framework but I am a (forced) user like many others of the websites A and B and data about me are stored on C – H. Idden Jan 4 '16 at 22:47
  • Are the sites (A,B) secured? Such as TLS/SSL. – Shane Andrie Jan 4 '16 at 22:59
  • A,B,C,X use EV SSL HTTPS – H. Idden Jan 4 '16 at 23:00
  • From what I found out by reverse engineering the new window approach just sets the session cookie and a javascript (from the framework) from site A does some sort of repeated cross site requests to X to check login state and then authentificates also for A. (The code is so much mess it is hard to find out what is really going on) – H. Idden Jan 4 '16 at 23:11
  • I think it needs to be clarified here, the concept of iframe isn't necessarily insecure, but the way it's used here is insecure, since the application requiring authentication is run by a separate trust entity than the authentication provider. Using SSL makes zero difference. – Lie Ryan Jan 5 '16 at 0:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.