View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0011296 | mantisbt | security | public | 2009-12-21 11:46 | 2024-01-31 05:49 |
Reporter | Buffer | Assigned To | |||
Priority | high | Severity | major | Reproducibility | always |
Status | acknowledged | Resolution | open | ||
Product Version | 1.1.8 | ||||
Summary | 0011296: Mantis BT is using fix cookies in the DB | ||||
Description | Dear Mantis developers, During testing Clientless SSL VPN vulnerability, with a malicious webpage to steal cookie through SSL VPN, I found something a little bit bizarre in Mantis BugTracker. In fact, the cookie for each user is fixed and never changes. As I remember, cookie must change for each server session, and must be unique for each server session. This is the not the case with your BT application, because cookie is simply fixed and stored in the database. Just for advise, I'm not sure this is the right design, as anyone can steal cookies using XSS or many other attacks' vectors. When the cookie is stolen, even if you click on logout, session never expired. With Tamper Data or any Firefox plugin, I just logged in as the user I want just by filling HTTP Cookie header with MANTIS_STRING_COOKIE right value, for targeted user (and even if the user logout before!). | ||||
Steps To Reproduce |
| ||||
Additional Information | Waiting for your update / ack or patch / release information before Full-Disclosure on SecFocus(BugTraq), as it's an important security issue. | ||||
Tags | No tags attached. | ||||
related to | 0010709 | closed | dhx | Use HttpOnly cookie flag to protect cookies from client-side Javascript manipulation/theft |
has duplicate | 0012277 | closed | dhx | Cookie tokens are constant for a particular user |
related to | 0027976 | closed | dregad | CVE-2009-20001: User cookie string is not reset upon logout |
related to | 0033587 | closed | dregad | "MANTIS_STRING_COOKIE" cookie reusable after user logout |
Any news / ACK to this potential vulnerability ? If no quick update, will be published next week on SecFocus FD Mailing ... |
|
We've done the work to protect the cookie in 1.2.0rc2 (issue 0010709). We currently change the cookie when the user changes their password. However, we could potentially do that more often, i.e. for each session. If we do that, we should make sure that a SOAP login doesn't log the user out of a web session. That would also mean that if a user logs in, the user would be automatically logged out on other browsers / computers. |
|
First, there is a user-controlled option already to limit sessions to a single IP address, and is allowed to be disabled by the user in cases where the user is behind a proxy setup with multiple exit points. Secondly, I think the real solution is to not store the user's cookie in the database. This is what the user's session ID is for, and I really think Mantis' existing concept of verifying the user's cookie from a value stored in the database is useless and outdated. The real question is exactly how do we proceed from this point forward? I personally would like to see the current cookie verification routines replaced by special handling in the session API. Thoughts? |
|
@jreese, I agree with your suggestion and I like the fact that it supports multiple sessions. However, I like the currently ability for a user to expire all their active sessions independent on the computer / browser by changing their password. The actual change of password doesn't affect the cookie, but at one point I've made this roll a new cookie. This is useful if a user remembers that he/she forgot to logout on some other machine they used. Hence, I think it would be great if we would be have a solution to support both. But, for simplification, I'm OK with compromising the remote logout feature if necessary. |
|
I've just read the Zend_Session class docs, in particular http://bit.ly/5m92La and they suggest regenerating a new session ID at each client request with the regenerateId() static method. I wonder if we could let our MantisSession class derive from Zend_Session, call regenerateId() early in the page generation and be done with this. |
|
The technique they are using looks good, but I expect that we are looking at fixing this for 1.2.x and maybe 1.1.x and hence we shouldn't be taking a dependency on ZF. |
|
One of the problems with using PHP sessions is that the lifetime of the PHP session cookies is (generally) set with a global PHP option. One of the use cases of MantisBT is that someone may leave a message half typed on a Friday afternoon with the expectation that they can finish it off on Monday and submit it. You may have PHP setup differently for another application where you want much shorter session expiry times. I'm fine with requiring them to reauthenticate due to an expired session cookie - as long as the data they're posting isn't lost. Users may login to the same account simultaneously from different devices (a mobile phone and a desktop computer for example). Therefore we can't just delete a session cookie that may still be in use by another device/login instance. We really need to remember a session key for each session (in the previous example, once for the mobile phone and then again for the desktop computer). Changing the session ID won't work as giallu suggested because users may open up 10 forms/pages in Mantis and submit them in any random order. We can't assume that users are browsing within their session using a linear one-page-at-a-time approach. Unless of course giallu was just referring to creating a new session key upon a new login, and using this key for all page requests until the user logs out. PHP's inbuilt session support would be the ideal method to use if we can figure out the maximum session lifetime correctly. In other words, we need to ensure all submitted forms remain intact while re-authentication is occurring. In the future I'd really like to add user audit logs that are viewable by not only administrators, but the users themselves. This would allow users to see the last 5 times they logged in, where those logins originated from, etc. The users would also be able to view all current sessions they've got open, with the ability to terminate any or all of them. |
|
Perhaps we could reuse the existing reauth methods, and combine the existing db-stored cookie with a per-session id. If the user's PHP session get's flushed/expired before submitting a form, we could pop the reauth dialog to make sure the user knows the correct password. This would also solve the underlying security issue, such that when a malicious user starts a new session with someone else's db cookie, it will trigger a reauth rather than simply giving them access. Thoughts? |
|
@dhx: I'm no expert here, but as I understand it, the approach Zend advocates is something like:
@vboctor, 1.1 is tricky but if we think the approach is good and the PHP requirement matches ours I can't see why we shouldn't; I checked and this particular class does not depend on anything else in the ZF. Alternatively, we could just grab the logic and implement it in our classes. |
|
Community-proposed PR https://github.com/mantisbt/mantisbt/pull/1653 As per my review comment, I think the proposed change is not acceptable as it prevents simultaneous sessions from multiple devices. |
|
Community-proposed solution (source: https://github.com/mantisbt/mantisbt/pull/1653#issuecomment-707803945) Currently, when a user logs into Mantis for the first time, or when the user changes their password, Mantis will generate a unique session key, store it in the database, and then set it as a cookie on the client. This has a few unintended security implications:
To fix this, we need a solution that:
Current designIn the Mantis database’s user table, there is a “session_cookie” column that stores a single, rarely-changing cookie. The database also stores the date and time of the user’s last visit, but there is no way to know when the cookie was first set, or from where the user logged in. Proposed designCreate a new table, named “mantis_session_table”, containing the following columns:
The user ID, IP address, and user agent will be used to uniquely identify each session, each of which will have a unique, randomly-generated session cookie. The date created and date last accessed will be used to expire session cookies when they become too old and/or when too much time has passed since they were last used. New options will be added to mantis_config_defaults_inc.php to specify two new settings:
Note that it is not necessary to delete sessions immediately when these thresholds are reached. We can wait until the session is next validated, at which point we decide if we continue to use it or delete it. |
|
MantisBT: master 6f369a5a 2021-02-13 12:33 Details Diff |
Reset user session cookie string upon logout When a user logs out from Mantis, we clear their session cookie string (i.e. set mantis_user_table.cookie_string column to an empty string). This ensures that anyone knowing its value is no longer able to login with it. On login, after successfully authenticating the user, when setting the cookies in auth_set_cookies() we check if the cookie_string is defined in the DB, and if not a new hash is generated and stored. While not a complete fix for issue 0011296, this does improve the situation by providing an easy and logical means for users to effectively invalidate all their previous sessions. Additionally, using an empty value to indicate an invalidated cookie string instead of directly generating a new hash makes it easy to: - identify user records which should be considered as logged out (e.g. last_visit older than $g_cookie_time_length) - invalidate login cookies (set them to '') Leveraging this is left for future improvements. Note: an empty string in the session cookie always triggers an anonymous login (or sends the user back to login page if anonymous login is disabled). Fixes 0027976 |
Affected Issues 0011296, 0027976 |
|
mod - core/authentication_api.php | Diff File | ||
MantisBT: master-2.24 79a78c09 2021-02-24 08:16 Details Diff |
Set a new random cookie string upon logout When a user logs out from Mantis, we reset their session cookie string. This ensures that anyone knowing its value is no longer able to login with it. While not a complete fix for issue 0011296, this does improve the situation by providing an easy and logical means for users to effectively invalidate all their previous sessions. Additionally, using an empty value to indicate an invalidated cookie string instead of directly generating a new hash makes it easy to: - identify user records which should be considered as logged out (e.g. last_visit older than $g_cookie_time_length) - invalidate login cookies (set them to '') Leveraging this is left for future improvements. Note: an empty string in the session cookie always triggers an anonymous login (or sends the user back to login page if anonymous login is disabled). Fixes 0027976 (cherry picked from commit d8181a548e5131eede5d3b891bec0df68b472ba9) |
Affected Issues 0011296, 0027976 |
|
mod - core/authentication_api.php | Diff File |