-
Bug
-
Resolution: Answered
-
Low
-
3.5.4, 3.8.0, 4.0.0
-
Severity 3 - Minor
-
Problem
Closing a browser ends the user session. When the user re-opens the browser and accesses Crucible, there is no login prompt and Crucible treats it like an authenticated user. Any page loads after the initial will result in the user being directed to the login page.
Steps to Reproduce
- Have Crucible integrated with Crowd SSO
- Log into Crucible with an user from Crowd
- Close the web browser
- Re-open the web browser
- Checking the cookies, the crowd token is gone
- Access Crucible, notice that it returns data as if the user is logged in
- Easier to confirm if anonymous access is disabled
- Reload the page or access a separate Crucible page
- User is redirected back to login page
Cause
When the web browser is closed, the Crowd token is cleared, but the not the remember cookie. It seems that this cookie is used for some checks, making Crucible still return data even if not logged in:
- Attached 2 screenshots of what we see before closing the browser and what we see right after opening the browser (before accessing Crucible).
- Note that browser is not configured to re-open previous sessions
- When access Crucible for the first time, the headers look like this:
Request Header Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding gzip, deflate Accept-Language en-US,en;q=0.5 Connection keep-alive Cookie crucibleprefs1="D%3D1423697357467"; remember=crowdadmin:23:62ca5b2cc3ba57dfa76888e33583f601 Host localhost:8060 User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Firefox/34.0 Response Header Cache-Control private Content-Encoding gzip Content-Language en-US Content-Length 9239 Content-Type text/html;charset=UTF-8 Expires Thu, 01 Jan 1970 00:00:00 GMT Server Jetty(8.1.10.v20130312) Set-Cookie remember=crowdadmin:23:62ca5b2cc3ba57dfa76888e33583f601;Path=/;Expires=Thu, 11-Feb-2016 23:29:30 GMT;HttpOnly crucibleprefs1="D%3D1423697370050";Path=/;Expires=Thu, 11-Feb-2016 23:29:30 GMT FESESSIONID=1t7gkorlrltasczw2z0qgg2se;Path=/;HttpOnly atl.xsrf.token.slash=102cc2c85a7162c9e479c2c2cbe39e99d1c2cb6b;Path=/ Vary Accept-Encoding, User-Agent X-ASESSIONID 16q2zjr X-AUSERNAME crowdadmin X-UA-Compatible IE=Edge
- Notice the the cookie: remember=crowdadmin:23:62ca5b2cc3ba57dfa76888e33583f601
- Crucible treats this like a logged in user and displays the Crucible page
- When reloading the page, the headers change:
Request Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding gzip, deflate Accept-Language en-US,en;q=0.5 Cache-Control max-age=0 Connection keep-alive Cookie crucibleprefs1="D%3D1423697370427"; FESESSIONID=1t7gkorlrltasczw2z0qgg2se; atl.xsrf.token.slash=102cc2c85a7162c9e479c2c2cbe39e99d1c2cb6b Host localhost:8060 User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Firefox/34.0 Response Content-Encoding gzip Content-Language en-US Content-Length 9415 Content-Type text/html;charset=UTF-8 Server Jetty(8.1.10.v20130312) Vary Accept-Encoding, User-Agent X-ASESSIONID 16q2zjr X-AUSERNAME anonymous X-UA-Compatible IE=Edge - The remember cookie is gone and user is directed to the login page.
- is related to
-
CRUC-7588 Disable remember me option
- Closed
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
SER-218 Reduce the default rememberme/autologin cookie expiry from one year to two weeks
-
- Closed
-
[CRUC-7130] Crucible does not clear all Tokens when Browser is Closed
Hi David,
Thanks for the followup.
I hesitate to outright state concretely that the exact implementations as-worded at those URLs meet our contractual security requirements, but the overall idea is reasonable (IMO) and pretty common:
- An inactive session should time out. That session time out, by definition, should result in subsequent access requiring reauthentication.
- The "allowable period of inactivity before session timeout" should be configurable, ideally at "minute" granularity.
- Clicking "Log out" should end the session and, of course, require subsequent reauthentication
That said, we run the JIRA instance I've referenced above, but not the Confluence instance (separate dept). Both of them are configured somehow to time out sessions (and require re-authentication via username and password) after a period of time less than 1 day. Both also require reauthentication properly after clicking Log out.
I believe that's an overall "Yes", if pressed to answer 
jblaine1385138924 does the default remember me timeout of 30 days that is currently used in Confluence and JIRA, which is configurable as per https://confluence.atlassian.com/doc/confluence-cookies-160794071.html & https://confluence.atlassian.com/adminjiraserver071/jira-application-cookies-802593163.html, meet your requirements?
This also affects non-Crowd setups. We're using LDAP directly and have no capability to time out sessions (we've tried session-timeout in web.xml) or even effectively log people out when they choose "Log out".
In our experience, once we've logged in, we are permanently "logged in", even if we logout explicitly + close browser. Returning to out FE/CRU site logs us in with our normal privileges.
For example, my account has admin privileges. I can
- choose "Log out"
- close my browser
- open my browser
- visit the site
- never type a password
- ... and select my normal stuff from the "gear icon" admin menu.
Ultimately, this prohibits us from meeting contractual security control requirements. I'm not sure I agree with @dblack re: CVSS, but hey, I'm just some person.
We don't have this overall problem with JIRA 7.2.x or Confluence 5.7.x. We are able to time out those sessions fine and force re-authentication via password.
pswiecicki this should be handled as a standard bug and does not need a cvss score.
Yes, the problem is that:
- rememberme cookie is persistent cookie (set for one year), set every time user logs in. If there is Crucible licence this cookie is always set, if there is no Crucible licence the checkbox is presented on the login page so they user may decide if rememberme cookie should be set
- apart from that there is a sso cookie set, valid for a session only.
Now there is some weird FeCru behaviour we have to investigate further. when user logs in with rememberme cookie but without sso cookie (typical case for new browser session) FeCru renders first page as if the user was logged. But any subsequent requests redirect user to a login page, most likely because of the sso logic.
We need to decide what's the expected behaviour: - should the SSO flag, once enabled, rule out all the rememberme cookie? Or
- should we accept rememberme cookie, continue as if the user was logged in. We may at the same time consider recreating sso session for the user transparently if feasible.
And we obviously need to find out why the first request is authenticated and the others are not.
dblack do you think there is any CVSS required for this case now? Should we handle this as a security issue, or rather standard bug?
I think the problem is that at first, the browser seems to remember you, but then as soon as you attempt to do anything, you either get prompted for a login, or get an error message.
For instance, if you log in, do work, close browser, open browser, and then go directly to a review link, it appears to the user that they are logged in. However, if they then click on a file in the review, they get the error message
An error has occurred Error Anonymous users cannot mark files as read/unread.
It actually sounds like Crucible is working as intended. If a user closes their browser then any 'session' cookies are cleared. However, as the remember cookie is designed to persist (it is a persistent cookie and expires in the future) it will not be cleared by the browser unless the browser is configured to clear all cookie data on close. This is only a minor security bug if logging out does not clear the remember cookie.
Also, if I have misunderstood the description of this issue please do correct me. For example, if this issue is about an invalid remember me cookie token being accepted as a valid one then there is a larger security issue.
We are able to confirm the bug on FeCru 3.8.0-SNAPSHOT, with Crowd auth and SSO enabled.
Hi everyone,
We have recently reviewed this issue and the overall interest in the problem. As the issue hasn't collect votes, watchers, comments, or support cases from many customers during its lifetime, it's very low on our priority list, and will not be fixed in the foreseeable future. That's why we've decided to close it.
We want to be clear in managing your expectations. The Fisheye & Crucible team is focusing on issues that have broad impact and high value, reflected by the number of comments, votes, support cases, and customers interested. Please consult the Atlassian Bug Fixing Policy for more details.
If you still see this bug occurring in the latest release and a fix is very important for you, please don't hesitate to share your feedback in the issue comments and vote on it. We will continue to watch the issue for further updates.
Kind regards
Marek Parfianowicz
Development Team Lead