[Openid-specs-ab] Session Management: Security Considerations

[Breno de Medeiros]

On Wed, Aug 31, 2011 at 23:50, Andreas Åkre Solberg
<andreas.solberg at uninett.no> wrote:
> On 31. aug. 2011, at 19:22, Breno de Medeiros wrote:
>
> The check session endpoint MUST validate browser session matches the
> id_token.
>
> I probably did not explain my point very well. Let me try again.
> This does not even need to include the check session endpoint to perform the
> attack.
> The issue I'm referring to is the combination of leaking ID Token to the
> browser history log
> (something that could happen with the check session request)
> and
> accepting a new ID Token as an incoming front-channel request.
> (something that is done with the check session response)

Right -- this can be fixed using traditional XSRF protection
techniques. See the OAuth2 spec's security considerations section (we
will need one for OpenIDConnect eventually, but this is actually a
more general concern even at the OAuth2 level).

> The attacker would first need to obtain a ID Token for a another user, then
> establish a session at the RP as him self, and then make the RP issue a
> check session request. The reason that it needs it to generate a check
> session request is that the RP then presents a state; which makes it easy
> for the attacker to craft a valid response (without being in contact with
> the check session endpoint) by combing this state parameter with the id
> token jwt found in the browser cache.
> This attack would not be possible if the RP did a comparison of the user_id
> in the check session request and the response.
> And BTW; if "The check session endpoint MUST validate browser session
> matches the id_token."
> you should add that the to spec. In addition you have to explain what it
> mean to validate a browser session against an id_token. As there is no
> session identifiers involved in openid connect, I must admit it is not
> totally clear to me how that can be done. Should in example the provider
> cache all issued ID Tokens (or hashes of them)? Or is the session concept
> intensionally dropped, and comparing the user_id and authentication level is
> sufficient for comparing a ID Token with a 'browser session'.
> Andreas
>



-- 
--Breno