Cookie Hijack

[soliveira]

I've notice this behavior:

• After Login on STS I save the idsrv cookie.
• Log out the application
• Import the cookie to the browser
• Access the application and I'm logged.

Is this the expected behavior, or am I missing something? Doesn't this expose the applications to cookie hijacking? How to mitigate this.

thks

[brockallen]

Can't you do that with any web application that issues cookies for authentication?

[soliveira]

Doesn't facebook uses cookie authentication? I couldn't do it there.

Isn't this a security concern?

[brockallen]

My point is that you could do the same for any other website that uses cookies. That's how we do authentication. IdentityServer works the same way.

[JesseKlaasse]

I know this issue is quite old, but it's still open, and I'm having the exact same problem. Our application (which consists of multiple server side applications (a Drupal portal and two separate .NET MVC applications) and IdentityServer3).

We have recently had a Pentest done for this application set, and one of the issues is exactly the one the issue starter describes. The comments of the tester were:

Expected Result: Once the user clicks logout, the session cookies should destory instantly and should not remain valid anymore.

Actual Result: The session cookies remains valid even after logging out. It can lead to ACCOUNT TAKEOVER, an attacker can get the victim's cookies through XSS or similar method and then would easily keep logging-in to the victim's account even if the victim logsout.

How to handle this?

[brockallen]

If you're using cookies, then where did you get it from? An external provider?

[JesseKlaasse]

No, we're using local authentication in an implementation of the IUserService. The service authenticates against a local user database. Is this enough background information, or do you need more?

[brockallen]

Well, IdMgr is not the same as IdSvr.

I guess what I need to know -- is the user logging out of IdMgr or somewhere else?

[JesseKlaasse]

We don't use IdMgr (yet).

We are using Drupal with a custom module to replace the standard authentication and session management by OAuth2/OpenID Connect using the IdentityServer3. When a user clicks on 'logout' in Drupal, he gets redirected to the end_session endpoint. In the IdSrv log, I can see the logout is completely successful. Also, the Drupal session is destroyed. In Cookie Manager, I can see that 3 of the 4 IdSrv cookies are deleted. 1 remains, the idsrsv.xsrf cookie.

When I restore the IdSrv cookies (using the Firefox Cookie Manager plugin), and request a Drupal page, I get redirected to the authorize endpoint, which is successful:

2016-03-01 08:55:00,431 [6 ] INFO Core.ResponseHandling.AuthorizeResponseGenerator - Creating Hybrid Flow response. 2016-03-01 08:55:00,447 [8 ] INFO Core.ResponseHandling.AuthorizeResponseGenerator - Creating Implicit Flow response. 2016-03-01 08:55:00,447 [8 ] DEBUG Services.Default.DefaultTokenService - Creating access token 2016-03-01 08:55:00,447 [8 ] DEBUG Services.Default.DefaultTokenService - Creating JWT access token 2016-03-01 08:55:00,447 [8 ] DEBUG Services.Default.DefaultTokenService - Creating identity token 2016-03-01 08:55:00,447 [8 ] INFO Services.Default.DefaultClaimsProvider - Getting claims for identity token for subject: 5087 2016-03-01 08:55:00,462 [8 ] DEBUG IdentityServer.Helpers.UserService - Requested claim types: sub role company_id name email company_id 2016-03-01 08:55:00,462 [8 ] DEBUG Services.Default.DefaultTokenService - Creating JWT identity token

The user gets redirected to Drupal. After that, a token request is done by Drupal, which is also successful. The user is now logged in, and gets redirected to Drupal again.

[brockallen]

We don't use IdMgr (yet).

Yep, my apologies. I had misread the repo we were on (I get switched around a lot).

AuthorizationServer (this repo that you're asking about) relies upon external authentication using a SSO provider. When the user logs out of the SSO provider then you need to configure the provider such that it contacts this app to cleanup the cookie.

[JesseKlaasse]

Thanks, Brock. Do you mean that the SSO provider should call the end_session_endpoint? I'm asking this, because we are already doing this:

(this is the Chrome network tab filtered on 'Other' and 'Doc')

I can see in the IdSrv log that de cookies are already cleaned (which is also reflected by the Cookie Manager): 2016-03-03 12:13:00,282 [29 ] INFO Core.Endpoints.AuthenticationController - Logout prompt for subject: 15607 2016-03-03 12:13:00,282 [29 ] INFO Core.Endpoints.AuthenticationController - SignOutMessage present (from client drupal_sso) and RequireSignOutPrompt is false, performing logout 2016-03-03 12:13:00,282 [29 ] INFO Core.Endpoints.AuthenticationController - Logout endpoint submitted 2016-03-03 12:13:00,282 [29 ] INFO Core.Endpoints.AuthenticationController - Logout requested for subject: 15607 2016-03-03 12:13:00,282 [29 ] INFO Core.Endpoints.AuthenticationController - Clearing cookies

Maybe I just don't understand it completely, but isn't the whole point that the cookies are in fact destroyed, but when the user restores the saved cookies, the cookie is still treated as valid, and the user is logged in again?

[brockallen]

Also as a side note, I see a request to "report" in there -- I think you might have some CSP issues there.

[brockallen]

So for the issue, I'm just not sure on what's happening in your environment.

Also, I'm not clear on why you use AuthorizationServer and IdentityServer3 -- IdSvr3 includes the features of AuthorizationServer.

[JesseKlaasse]

Actually, I'm not using or intending to use AuthorizationServer, as far as I know. It's not listed in my NuGet packages. What is the indicator for you to say I'm using AuthorizationServer?

(As a side note: I'll look into the CSP stuff.. Thanks for pointing it out.)

[brockallen]

Because you're posting in the "IdentityModel/AuthorizationServer" issue tracker (look above).

[JesseKlaasse]

Oooops, my mistake.. I'm sorry! Actually, I'm only using IdSrv 3.

[brockallen]

Open an issue there, please.