comments (not for humans)

In an IdP/SP (Identity Provider/Service Provider) Single Sign-On scenario, you might also want to have Single Sign-Out, meaning you can log out of all SPs with a single click.

The logout relies on a signout message being sent from the SP to the IdP. The IdP records all the sign-ons it performs during the user's session, and is using this list when performing the logout. A lot of the times the signout message is submitted via the users browser in order to clear the login cookies. So the site provides a set of img-tags or script tags, pointing to the logout location on the SPs. An example is the wsignoutcleanup1.0 request in the Microsoft Web Browser Federated Sign-On Protocol Specification.

The attack

What can be a problem with this approach is that it leaves the logout open for XSRF/CSRF attacks. The attacker can trick the user into visiting the logout url. If the attacker can provide an image url at some location on the site (or add this to a site) the user often visits, the user will be logged out when going there.

An example of this attack was performed against Myspace a few years back. An attacker could send the victim a private message, but if the victim tried to view his/her private messages, the victim would be logged out. So the victim was not able to delete the message, because the user was logged out when trying to access the inbox.

Risk

The severity of this problem depends on the application and it's surroundings. If, as in the myspace attack, it's easy for an attacker to place an image tag containing the logout location somewhere on the site (typically this could be a picture in a comment), it's easy to exploit this problem. Putting a link to it on a seperate site is easy, but it may not be easy to get the users to visit the page. You could use DREAD to help you determine whether this is something you should handle for your application.

Mitigation

Assuming you are using SAML or any other SSO-technology that allows you to include custom values, there is an easy fix. It's the same fix that is normally used to mitigate XSRF/CSRF, except we need to perform it in a slightly different way.

To authenticate the logout, we need to establish a shared secret for the session:

  1. During an SSO login, generate a nonce (secure random value) at the IdP
  2. Store this nonce in the user's session on the IdP.
  3. Put the nonce in the SAML token
  4. On the SP, extract and store the nonce in the user's session.

Now during the logout, include the nonce as a URL parameter at the IdP side. When the SP gets the request, the SP can validate the nonce with what's stored in the session, and perform the logout if the value is the same. An XSRF attack would not know the nonce, and could thus not construct a correct URL.

Comments closed for this post