discussion/proposal: disallow user-autologin to an application using SSO sessions

[elarlang]

Classical solution: There is an SSO, and if a user has a session in the SSO, then the user does not need to authenticate to each related application separately.

Often the application redirects non-authenticated users automatically to SSO and if the user has an SSO session, the user will be redirected back to the application and the user now has the valid session in the application.

Problem to solve: valid session in the application is a pre-condition for many attacks and it should not be possible to force the victim browser to create a valid session to the application without user interaction. For creating a valid session is enough to redirect user browser to the application.

Update a session vs createing a session - a widespread OAuth solution (for SPA) is for the browser to send access_token as the Bearer value in the 'Authorization' request header (field). When the (short-lived) access_token expires, the user/browser must renew or update this token. In this case, it's an update from a previous session and it is not creating a new one - the application should be able to tell the difference.

Proposal - disallow user auto-login to an application using SSO session, require user-interaction - one click is enough to take down the "auto-creating" scenario.

[tghosth]

What do we think about:

Verify that logging in to the application is protected against a CSRF-style attack where the user is forced to login.

[elarlang]

Ok, with this wording it feels too much duplicate of 50.3.1 (previously 4.2.2) and we should merge it there. I think the "CSRF requirement" needs some update anyway.

[tghosth]

I think that this is an unusual case because you would not necessarily expect this functionality to be sensitive (might even be a GET based redirect) but actually it is

[csfreak92]

Hey @elarlang, is this scenario only dealing with SSO specifically? If yes, then how about,

Verify that SSO auto-logins are disabled for extended periods of user session and forces the user to interact with the SSO to continue the authenticated session?

I now this is a bit wordy, but may need some wordsmithing if it fits what we need to solve the problem. In this way we are forcing the user to do that one-click interaction as you mentioned. What do you think?

[elarlang]

Something like this for finetuning:

Verify that creating a session for the application requires the user's consent and that the application is protected against a CSRF-style attack to create a new session for the application using an active session from SSO without user action.

ping @tghosth

[csfreak92]

@elarlang, I like the last one you have, just wondering if requiring the user's consent or was it an action like clicking a button that we want a user to do?

[elarlang]

To achieve the consent, you need user interaction (click). If we just ask for a click, we can "solve it with clickjacking" :)

[elarlang]

So, I would like to get the requirement (#1815 (comment)) to be suitable for the section "V3.2 Session Binding"

[tghosth]

Potential examples of this:
http://homakov.blogspot.com/2012/07/saferweb-most-common-oauth2.html
https://dev.clever.com/docs/il-security

My suggested wording:

Verify that creating a session for the application requires the user's consent and that the application is protected against a CSRF style attack where a new application session for the user is created via SSO without user interaction.

WDYT @elarlang ?

[elarlang]

Let's get it in. If we have some better ideas, we can improve it later.

[elarlang]

Proposal:

• Requirement: Verify that creating a session for the application requires the user's consent and that the application is protected against a CSRF style attack where a new application session for the user is created via SSO without user interaction.
• Section: V3.2 Session Binding
• Level: 1 (or 2?)
• CWE - none

[tghosth]

Level 2 I think, everything else is in: #1929