search

cloud-gov / cf-uaa-guard-service

[Alpha/experimental] UAA proxy as a service
Other
7 stars 6 forks source link

UAA Auth Route Service uaa-proxy-session cookies may be replayed indefinitely #16

Open commit-dkp opened 7 years ago

commit-dkp commented 7 years ago

As the team that is the main author of this repository, our team noticed a problem with the way that this service uses cookies. We’re writing it down here to let you know if you use (or are interested in using) the service, including if you might be interested in fixing the issue sooner than we can get to it. (Ping: @ArthurHlt and @dhrapson as recent contributors outside our team.)

The UAA Auth Route Service will accept uaa-proxy-session cookies it has issued even after the user has logged out of their session with the application. uaa-proxy-session cookies are not invalidated by logging out, and do not have an internal time-to-live. A default maxAge may be set, but this is only enforced by the client. Consequently, a user may copy their own uaa-proxy-session cookie and reuse it indefinitely. This may be a vulnerability in environments where sessions are required to have a maximum lifetime after which the user is challenged to provide their primary credentials for re-authentication and re-authorization.

For example, if you save the 'uaa-proxy-session' cookie, log off, log back in again, and replace the new 'uaa-proxy-session' cookie with the old one, that works, which is unexpected behavior and can be a security vulnerability.

The uaa-proxy-session cookie is hashed with a Message Authentication Code (MAC) so it cannot modified or forged for another user without knowledge of the secret, server-side key.

--@commit-dkp, @brittag, and fellow 18F/cloud.gov teammates

ArthurHlt commented 7 years ago

Hello there, Yes i found this issue, i didn't PR what I've done about it cause I will need your approval and discuss about the work I've made.

First, I decrypt information in the token which is jwt and you get user information inside this token. The token is actually base64 encoded information and user information are available in the third part of jwt (see code to get info). Inside you can found when the token will expire (by default uaa delivered a token which expired in 30min).

I store this information inside the cf-uaa-guard's cookie (see code) and I check if the session expired from the time I stored in the rootHandler (see code) if expired I redirect to the logout handler I've added.

This handler will simply clean data inside the token, put logged to false and remove user information and finally redirect to the auth handler (see code).

Finally, it will go back to the current chain and if token can be renewed it will be and if no go back to the login page.

Hope it helps.

commit-dkp commented 5 years ago

@ArthurHlt AFAIK, 18F/cloud.gov doesn't use this service anymore, so you shouldn't need their approval to send a PR. FWIW, if what you've done can pass a unit test where the example they described in the second-to-last paragraph cannot be realized, then I would consider the issue closed.

mogul commented 5 years ago

Sorry, I've only just seen this since I missed notification of @ArthurHlt 's comment back when he made it. As the person ostensibly in charge around here: Yes, PRs with a test welcome!