4

Context:

I have two web servers ServerA (LAMP stack) and ServerB (ASP.NET stack). I think the technology (hopefully) does not matter. Both servers require authentication and supposedly doing their job well, if not that is out of scope in this question.

Task:

I would like to implement a page with iframe content. ServerA serves the outer content ServerB serves the inner content (the iframe). The servers are in different domain. When user X logs to ServerA and navigates to the page, I would like to show a personal and sensitive content coming from ServerB in the iframe. The content belongs to user X's identity in server B.

Proposed solution:

  • ServerA and ServerB has a shared secret (server side)
  • Users are replicated from ServerA to ServerB. Usernames match, passwords on ServerB random generated and not used at all. (keep reading)
  • ServerA authenticates the user via https using a form based authentication
  • Outer page contains the following html fragement where the .any extension in the url is configured to execute and respond in the server for example .aspx or .cshtml or .php etc:

.

<img src="https://serverb.com/dummy.any?parameter=crypted_username_and_date_using_the secret" style="display:none;" />

  • In ServerB when a request received to the dummy.any url it decrypts the parameter, does some checking then in the response sets a crypted cookie containing with the username. The crypting key could be the shared secret or better it can be a ServerB's private secret.

  • In ServerB when a request received to the inner page (the iframe) it should contain the cookie, what was set for this very same domain (https://serverb) if the cookie is there and the userX is existing, and say a 5 minutes the timeframe is all OK, then ServerB uses its authentication subsystem to log on the user programmatically (no password provided). (the authentication subsystem sets their own cookies or whatever, this hopefully black box in our point of view)

  • After this ServerB serves sensitive content which belongs to userX.

Please note I am a developer and not a security expert. That's why I am asking before implementing a security hole.

g.pickardou
  • 220
  • 1
  • 6
  • 2
    "sets an also decrypted cookie containing with the username" is that correct? if so, can't I just change that cookie value to log in as any other existing user? – Jay Mar 22 '16 at 13:21
  • 1
    Thx, no, I mean crypted.... going to edit – g.pickardou Mar 22 '16 at 13:22
  • what are you planning on using for the crypto? – Jay Mar 22 '16 at 13:49
  • I do not know yet, must find something what is easily available both in PHP for ServerA and in C# for ServerB – g.pickardou Mar 22 '16 at 13:56
  • @g.pickardou Looks good for me – Sravan Mar 22 '16 at 14:24
  • Another way is for outer page to POST a token in an invisible form targeting the iframe. This works even when third-party cookies are disabled and is very easy to code. If you make the token only valid for one request, you prevents any replay attacks or phishing websites iframing the page. – billc.cn Mar 22 '16 at 17:24

2 Answers2

1

I'm not sure this should be an answer, but I have too much to type for a comment...

What you are suggesting looks OK to me, with some assumptions:

  • The shared secret is good - no 'test123' etc.
  • The crypto you use is good. No ROT13 ;)
  • The usernames are case-sensitive, sounds obvious but I can imagine registering user abc and gaining access to user aBc's info

As a principal I think it works. The only thing I can think of is if a user is somehow able to register an account on server A that already exists on server B, but I'm sure you've thought of that.

Obviously if you have other security issues (vulns on either of the servers, the usual web attacks etc.) then all bets are off.

Jay
  • 1,565
  • 1
  • 10
  • 12
  • Thanks for your thoughts. About "...register an account on server A that already exists on server B..." Good point. Adding a "salt" like thing as a prefix may prevent this: so "userX" in ServerA is replicated to "ourothersecret-userX" on ServerB. – g.pickardou Mar 22 '16 at 16:02
  • sounds ok, as long as that mapping is foolproof it should work – Jay Mar 22 '16 at 16:11
1

The issue for me is that, in absence of session management, the request to serverB is susceptible to replay attacks. Hopefully ALL the communications between servers and client are via HTTPS, not just the authentication (otherwise that's a big security issue) so that reduces the possiblity of interception. However 5 minutes is a very long time for the token to be valid on the remote server. It also means you'll need to ensure that the clocks on the servers are synchronized.

Wouldn't it be simpler just to pass a single, timestamped, rapidly expiring token in the iframe URL?

An alternative solution would be for serverA to request a one time password from serverB when the outer page is requested, and include that in the URL for the iframe. But that doesn't scale so easily.

symcbean
  • 18,278
  • 39
  • 73
  • Thanks for your thoughts. About absence of session: There is session in ServerB see:"... then ServerB uses its authentication subsystem to log on the user programmatically ..." a session created for the iframe so no forther logins necessary. About "you'll need to ensure that the clocks": Yes as it necessary for a timestamped token. About "an alternative solution": Maybe its me but this seems way more complicated for me. (because that involves ServerA -> ServerB direct communication) – g.pickardou Mar 22 '16 at 17:15
  • Rethinking "...token in the iframe URL...". Yes this is simpler. However it is a web application with potentially many "outer pages" from serverA and many embedded content in iframes from ServerB. So this means I had to handle this token parameter in many places in ServerB not only a dedicated url – g.pickardou Mar 22 '16 at 17:38
  • Regarding sessions, yes, you have in effect *created* a session on serverB but you've not described any means by which this session is ended. – symcbean Mar 22 '16 at 21:57
  • Yes. There is no explicit session end defined in my proposed solution. (I mean: logout) So I think that session ends with timeout, just like any session when a user simply close the browser without explicitly logging out before. However in the case of ServerA logout and log in with other user, the new user will be logged in to ServerB too. – g.pickardou Mar 22 '16 at 22:05