Session Management OP Frame message origin assertion

Issue #1022 open
Filip Skokan
created an issue

From OpenID Connect Session Management 1.0 - draft 28#4.2. OP iframe

The OP iframe MUST enforce that the caller has the same origin as its parent frame. It MUST reject postMessage requests from any other source origin.

I understand the intention here but would like to raise a few questions/issues.

  1. cross-domain parent origin is not accessible, accessing window.parent.location.origin or window.parent.origin raises a DOMException and other means of reading the url are unreliable and inconsistent at best (accessing document.referrer and building the origin url out of it).
  2. the parent frame (tab) is not actually the source of the message, this would be the RP frame, same origin tho which might very well sit on a different subdomain, resulting in another origin.

I can see the example in the specification is not handling this either.

Steps to reproduce:

  1. Login with any username/password at RP https://tranquil-reef-95185.herokuapp.com, set to login with OP https://guarded-cliffs-8635.herokuapp.com
  2. Open console, switch to opframe js context
  3. Attempt to get parent origin via js to have are reference to compare message origin with

If anything this assertion of message origin should be mentioned in the RP frame, where the RP frame must assert the origin of the message is the OP frame origin, this origin can be easily formed by knowing the OP Frame location and can compare it to the message origin. The example rpFrame in the specification already does this.

Comments (19)

  1. Edmund Jay

    Filip,

    Is seems there that you are proposing:

    1. Delete modify the OP iframe assertion statement.
    2. Modify the OP iframe assertion to say something along the lines of "OP iframe MUST enforce that the caller is from an approved/known origin"
    3. Add a corresponding assertion statement to the RP iframe.
    4. Add CORS language to OP/RP frames? (unknown if this will support the call of window.parent.location.origin)

    or all/combination of above?

  2. Filip Skokan reporter

    Edmund,

    1. Yes - because asserting message origin being the same as parent (or rather RP frame origin, parent is not the sender) origin is not possible due to CORS restrictions.
    2. No - Same as above, to do something like this OP frame would either have to
      • have all known origins of all RPs in the rendered page ready to be asserted to include current message origin presence
      • or rely upon accessing external resources, doing so would beat the mobile friendly nature of session management messages
      • Content-Security-Policy header frame-ancestors section would seem like a good candidate but the OP frame parent is not the origin of the caller, that would be the RP frame origin, which cannot be checked using CSP.
    3. Yes - I believe the RP can take on this responsibility, it has all the necessary information at the time of rendering its frame to statically embed the assertion.
    4. Partially, with the above, the only thing left to do is remove // Validate message origin from OP Frame example and possibly wrap the receiveMessage body in a try / catch block resulting in responding with error

    It would be of great help if others who have also already undergone this implementation would share their findings.

  3. Michael Jones

    Filip, can you summarize the specific text changes you're proposing? I have some guesses but I'm not sure that my guesses are right.

    Also, a the in-person meeting at the beginning of April, the WG decided to take the logout specs to final status. If we're going to make any more changes, now's the time.

  4. Filip Skokan reporter

    Mike, i'm not comfortable proposing changes without having confirmation from others that this OK and that they've run into the same issue. Understanding what the intention behind those statements in security considerations was or how they were intended to be implemented is needed as well as the possible impact of these proposed changes.

    Nevertheless here's a proposal and my comments on why

    Removal of "The OP iframe MUST enforce that the caller has the origin as its parent frame."

    1. it is not possible to reach x-domain for the parent frame origin (DOMException) and it is not possible to embed the expected origin in the frame html since the server does not have the information available.
    2. it is possible the parent frame and caller origins are actually different, i.e. example-rp.com as the main window, example-op.com as the OP. When the redirect_uri was i.e. https://login.example-rp.com/cb (a subdomain, common pattern) then login.example-rp.com must be the rpFrame origin else op frame won't ever be able to calculate the correct state the RP has received in the authorization response. Now there are three origins in the mix and the OP can only read the caller origin.

    OP Frame Message Origin Assertion Removal
    The OP is not able to efficiently and reliably confirm the origin url of where the opFrame is embedded.

    1. same as the above
    2. in order to do this client side once a message is received the op frame would have to either
      1. embed all possible origins in the frame html - this turns out to be a problem for OPs with hundreds and thousands of clients where client information is loaded on-demand
      2. dynamically reach out to the server for validation - since client_id is part of the message this might be possible but would contradict one of the purposes of the spec it is desirable to be able to check the login status at the OP without causing network traffic
  5. Ryan Means

    We have been working on implementing this spec in the current draft form and ran into this same issue. Being unfamiliar with the WG and the process behind this draft to-date.. I'm wondering if another way to accomplish the goal here would be something like this:

    Given a check_session_iframe endpoint of /checksession on the IdP. The iFrame SHOULD be loaded with a query string of ?clientId={clientId}. The IdP when rendering the contents of the check_session_iframe SHOULD validate the clientId is valid and SHOULD reject requests to render the iFrame if the clientId is not provided or not valid. The IdP SHOULD generate the iframe dynamically such the iframe will check for post messages against a registered whitelist with the IdP for that client.

    That would keep things in the spirit of PostMessages and security best practices around the postmessage specification - that origins are always checked against a whitelist and non-white list messages are rejected. IdP's can then (and SHOULD) enforce this by requiring the iframe request to be loaded with a client ID query string which would allow the IdP to generate the contents of the JS within the iframe to match only registered origins for that client. The IdP could optionally support older versions of this draft by not requiring the clientId query string to be passed and as such, would not do a postmessage origin check.

    This would be essentially implementing what @Filip Skokan had suggested "[OP Iframe would have to] have all known origins of all RPs in the rendered page ready to be asserted to include current message origin presence"

  6. Filip Skokan reporter

    @Ryan Means, actually the normative language only says that

    The OP iframe MUST enforce that the caller has the same origin as its parent frame. It MUST reject postMessage requests from any other source origin.

    That, given the security boundaries and DOMException is simply not possible (even with knowing the client_id upfront).

    Question here is if the comment // Validate message origin in the spec's OP frame non-normative example is intended to do? The above? Not possible.

    However, if validating the message origin is a valid one would satisfy the original intent of the normative part above, I agree that adding a client_id would make that a possibility.

    The IdP SHOULD generate the iframe dynamically such the iframe will check for post messages against a registered whitelist with the IdP for that client.

    The registered whitelist being the unique origins (as per RFC6454) of the client's redirect_uris, correct?

  7. Ryan Means

    Yes @Filip Skokan - sorry, I was agreeing with your findings on how the normative language should be updated - as we have duplicated your findings in this original report.

    I do not believe it is possible, as you stated, to implement the spec in the current draft status due to the CORS issues you found and that we have duplicated. It was a google search that led us to this bug report in the spec after we were trying to figure out how others could have implemented this per the spec with browsers preventing the cross-origin lookup.

    I agree on on using the clients registered redirect_uris - the OP would parse the unique set of origins out of those redirect_uri's and use those to validate the caller. Then one could say something like:

    The OP iframe MUST enforce that the caller has an origin in the clients registered whitelist. It MUST reject postMessage requests from any other source origin.

    While not per the current draft - you could implement what I just stated without requiring that the OP iFrame be loaded with a query string of the clientId like I had suggested previously - thus not requiring any other OSS libraries that are already implementing the RP iframe to change (e.g. via a query string of the clientId like I had suggested).

    Instead, you could parse the the postMessage and per the spec:

    If the postMessage received is syntactically malformed in such a way that the posted Client ID and origin URL cannot be determined or are syntactically invalid, then the OP iframe SHOULD postMessage the string error back to the source.

    Then after that is parsed and a client ID is successfully extracted from the message - the OP iFrame would then retrieve the client ID's settings via an AJAX call (which is on the same origin that the OP Iframe is running on inside of the browser - thus no CORS problems) back to the OP for the set of allowed origins for that client ID. If the origin on the post message did not line up with an origin in that whitelist, then the message is rejected per the original normative language of:

    It MUST reject postMessage requests from any other source origin.

    While this is implementation specific on how this is done by each OP - similar to how the specification states that get_op_browser_state() is entirely up to OP, in order to relieve network traffic back to the OP from the OP Iframe, the OP IFrame could cache the results of the valid list of origins within the browser for that clientId (e.g. cookie, localstorage, or JS global variable)

    Within that spirit, one could implement this now still implementing to this part of the normative language:

    It MUST reject postMessage requests from any other source origin.

    The part that changes is this:

    The OP iframe MUST enforce that the caller has the same origin as its parent frame

    It would instead say:

    The OP iframe MUST enforce that the caller has an origin in the clients registered whitelist

    Where-as how it is done is entirely up to the OP ( network traffic back to the OP on every request OR have the OP Iframe cache the results in the browser for the valid set of origins for a given client)

    A non normative example for the pseudo-code OP iframe could change to this:

    window.addEventListener("message", receiveMessage, false);
    
      function receiveMessage(e){ // e.data has client_id and session_state
    
        // Validate message origin
        var client_id = e.data.split(' ')[0];
        var session_state = e.data.split(' ')[1];
        var salt = session_state.split('.')[1];
    
        // if message syntactically invalid
        //     postMessage('error', e.origin) and return
    
        // if client_id not contained in set of clientOrigins(client_id)
        //    return
    
        // get_op_client_origins(client_id) is an OP defined
        // function that returns the white list of origins for
        // a given client_id. How it is done is entirely up to
        // the OP.
        var clientOrigins = get_op_client_origins(client_id);
    
        // get_op_browser_state() is an OP defined function
        // that returns the browser's login status at the OP.
        // How it is done is entirely up to the OP.
        var opbs = get_op_browser_state();
    
        // Here, the session_state is calculated in this particular way,
        // but it is entirely up to the OP how to do it under the
        // requirements defined in this specification.
        var ss = CryptoJS.SHA256(client_id + ' ' + e.origin + ' ' +
          opbs + ' ' + salt) + "." + salt;
    
        var stat = '';
        if (session_state == ss) {
          stat = 'unchanged';
        } else {
          stat = 'changed';
        }
    
        e.source.postMessage(stat, e.origin);
      };
    
  8. Filip Skokan reporter

    Loading the list dynamically via unauthenticated ajax request is something I would not recommend or suggest and would rather the client_id be REQUIRED so that implementers can rely on this being present.

  9. Ryan Means

    I don't disagree - however, it cannot be considered as more secure to require the client_id in the query string for loading the OP iframe. Either way the full set of registered origins will be discoverable by a third party - either via an unauthenticated AJAX call that the OP iframe calls back to the OP server or simply by viewing the source of the rendered iframe with a given client ID... which can be programmatically driven from a third party to request the dynamic iframe to be rendered with a given client ID then extract the valid set of origins out it ... all server side by the third party.

    From a security perspective only, both are equivalent in terms of risk - both methods would require the iFrame have access to the complete set of white listed origins: either statically in the browser via a dynamically generated iframe on the server side OR programmatically from a static iframe where the iframe requests it over an un-authenticated AJAX call to get the dynamic set of allowed origins to use for that client_id

    I suppose you could run each origin thru a one way hash and then just compare hashes, perhaps where each origin is salted by the client_id. This would still need to be implemented by both solutions if you are trying to hide the set of white listed origins for a given client.

    This leads me to think my preference would be have the OP iframe handle it with the existing contract of how the OP iframe is loaded. This would allow all existing RP implementations to function as-is while denying any postMessages that don't come from an allowed origin.

  10. Filip Skokan reporter

    it cannot be considered as more secure to require the client_id in the query string for loading the OP iframe. Either way the full set of registered origins will be discoverable by a third party

    Completely agree, which makes me lean towards a simple straight forward solution of requiring client_id for this purpose even more. Personally, I am favouring simple straight forward OP solutions with no ambiguity over keeping the current contract.

    BUT, back to the root question tho, is that assertion actually needed? What does it bring, what does accepting a message from unverified source mean? The status sent back will ALWAYS be error or changed afterall anyway, since the postMessage event.origin is used for recalculating the state that's being compared.
    Can we focus on answering that first since it would mean not having to
    a) change the current contract or implementations (since the assertion cannot be achieved anyway)
    b) keep the logic completely client side and light weight as is one of the core goals of this feature.

  11. Michael Jones

    I'm all for clarifying the language in the Session management spec so that it is correct and actionable. That said, unless there's a compelling reason to change the interface, I believe we should not do so. There have been implementations of this in production for years and we haven't normatively changed Session Management since 2014. It's working fine as-is, as far as I can tell.

    The only reason we hadn't progressed it to being a final specification is that we were waiting for the other logout solutions to be ready to go at the same time. Given that we're preparing to make all three logout solutions final (after a couple of editorial improvements and a working group last call), now's the time to figure out what clarifications we should make to Session Management.

    Suggestions with actual proposed wording changes would be particularly appreciated.

  12. Filip Skokan reporter

    Just checked keycloak's implementation, they do an ajax request with the client_id and origin from within the rendered iframe once upon the receival of first valid formatted message but they're not validating the caller is the same origin as the parent frame. On the other hand they do not use the redirect_uri Origin for the session_state (just going through the spec again now i realized it is not a normative requirement to do so).

    The Session State value is initially calculated on the server. The same Session State value is also recalculated by the OP iframe in the browser client. The generation of suitable Session State values is specified in Section 4.2, and is based on a salted cryptographic hash of Client ID, origin URL, and OP browser state. For the origin URL, the server can use the origin URL of the Authentication Response, following the algorithm specified in Section 4 of RFC 6454 [RFC6454].

    Meaning they also DO NOT act on the normative language per se but implement what @Ryan Means suggested, but without the client_id request parameter extension.

    One way or the other verifying the caller origin is the same as parent origin is not possible. A proposed change would be (what Mike suggested earlier)

    OP iframe MUST enforce that the caller is from an approved/known origin.

    And check if there can be made an exception (allow omitting the above) when the redirect_uri Origin is used while calculating the session_state since the state returned would always be changed or error when used from other then intended origin.

  13. Log in to comment