1

We have a web application, where other partners can include their pages as iframes. We implemented a server-to-server way of authenticating users for the iframes, but one partner doesn't want to implement it.

The bad thing is, they also don't want to display their login page in the iframe in order not to be vulnerable to javascript key loggers.

We always bind in iframes with sandbox="allow-forms allow-scripts allow-top-navigation-by-user-activation allow-same-origin" - that's of course to guarantee the security on our side, I couldn't find any place where the iframe server could request sandbox to be active. Is there a way for them to do it, or would they just have to trust us?

Also, does the sandbox attribute guarantee that we cannot log key strokes which were created while the focus was on their iframe? - I thought it would guarantee it, but I couldn't find it anywhere documented.

Regarding server making sure that the iframe can't be loaded into any malicious page, they could simply white list us with header https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options or?

  • Personally, I think the approach of iframes is wrong. If site X want to display data from site Y (assuming site Y allows this). This is what API's are used for. Would that be something to consider? – Jeroen Sep 17 at 14:51
  • the problem is - our webapp is kinda a hub for many different integrations, so they are using our API to fetch data from us. BUT - users want to see additional information and trigger additional actions on our UI. Because it wouldn't be feasible for us to implement all the possible use cases or extend our API to accommodate for their data, we chose the route with tiny targeted iframes to kinda polish the integration – peter Sep 17 at 14:58
1

Their best best is to turn on the X-Frame-Options header, as you mentioned.

While pointing this out won't help your cause, the reality is that if they haven't had that header on then they have been vulnerable to various iframe-related attacks this entire time anyway. You trying to load their site in an iframe doesn't make them anymore vulnerable - it just takes makes them aware of a threat that they have already been vulnerable to anyway. All that to say, them attempting to limit what you are doing probably doesn't make them more secure, because even though you are announcing your intent, attackers don't.

As a more general answer, due to the same origin policy, your site would not be able to listen to any keystrokes inside the iframe anyway (see this question for a starting point). As a result their immediate concerns are actually unfounded. With iframes you do have to be concerned about clickjacking, which is solved via the X-Frame-Options header.

However, that really isn't relevant here either. To boil it down, you are trying to implement a solution where users login to your site and then access a third-party site through your system. In essence, this is a variation on SSO. Understanding that, and looking at things from their perspective, your original proposal (server-to-server authentication) is really the ideal solution. The advantage for them is that they can easily log that a particular user session came from you. As a result, if anything "unusual" happens during that session, they can potentially (and accurately) hold you responsible for anything bad that might happen. Of course it may be that they simply (for whatever reason) do not want to participate in whatever it is that you are trying to accomplish. Obviously, they have the right to make that decision if they feel it is best for their business.

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.