View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009664 | mantisbt | security | public | 2008-09-26 11:13 | 2008-10-23 10:29 |
| Reporter | seiji | Assigned To | jreese | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| OS | Gentoo Linux | ||||
| Product Version | 1.1.2 | ||||
| Target Version | 1.1.3 | Fixed in Version | 1.1.3 | ||
| Summary | 0009664: Logout without unsetting session cookie | ||||
| Description | MantisSession#destory() uses session_destroy(). But it does not unset session cookie. | ||||
| Steps To Reproduce |
| ||||
| Additional Information | 1.1.2 and 1.2.0 | ||||
| Tags | patch | ||||
| Attached Files | sessionid.patch.txt (1,178 bytes)
Index: core/authentication_api.php
===================================================================
--- core/authentication_api.php (revision 211)
+++ core/authentication_api.php (working copy)
@@ -265,6 +265,8 @@
auth_http_set_logout_pending( true );
}
+ session_clean();
+
return true;
}
Index: core/session_api.php
===================================================================
--- core/session_api.php (revision 211)
+++ core/session_api.php (working copy)
@@ -58,6 +58,8 @@
session_cache_limiter( 'private_no_expire' );
if ( isset( $_SERVER['HTTPS'] ) && ( strtolower( $_SERVER['HTTPS'] ) != 'off' ) ) {
session_set_cookie_params( 0, config_get( 'cookie_path' ), config_get( 'cookie_domain' ), true, true );
+ } else {
+ session_set_cookie_params( 0, config_get( 'cookie_path' ), config_get( 'cookie_domain' ), false, true );
}
session_start();
$this->id = session_id();
@@ -85,7 +87,10 @@
}
function destroy() {
- unset( $_SESSION );
+ if ( isset( $_COOKIE[ session_name() ] ) && !headers_sent() ) {
+ gpc_set_cookie( session_name(), '', time() - 42000 );
+ }
+ //unset( $_SESSION );
session_destroy();
}
}
| ||||
|
Why does it matter if the cookie is still on the client after session_destroy() has been called? At that point, the cookie links to nothing, so I don't understand what the security risk could be... |
|
|
See PHP Manual
|
|
|
I can see that deleting the cookie has a purpose, but I'm still not understanding what the security issue is with leaving the cookie on the client system. The session data is destroyed on the server, and a new session would need to be created at the next page load, so what's the security risk of leaving cookies client-side, especially considering that any client could simply ignore the cookie deletion request anyways... |
|
|
Certainly, the session data is destroyed. However, The old session id is used when logging in mantis again.
OWASP Session Management thanks. |
|
|
OK, that's the explanation I was looking for; thank you. And on your middle remark, it probably is a bug if it doesn't get called anywhere. I will work on getting this put in ASAP. |
|
|
Fix has been committed to SVN 1.1.x, r5594. |
|
|
This is now CVE-2008-4689 |
|
|
MantisBT: master cbd8c1e5 2008-09-27 10:23 Details Diff |
Fix 0009664: PHP session cookies were not destroyed, and session_clean() was never called. git-svn-id: http://mantisbt.svn.sourceforge.net/svnroot/mantisbt/trunk@5593 <a class="text" href="/?p=mantisbt.git;a=object;h=f5dc347c">f5dc347c</a>-c33d-0410-90a0-b07cc1902cb9 |
Affected Issues 0009664 |
|
| mod - core/authentication_api.php | Diff File | ||
| mod - core/session_api.php | Diff File | ||
|
MantisBT: master-1.1.x 9ddf7eef 2008-09-27 10:28 Details Diff |
Fix 0009664: PHP session cookies were not destroyed, and session_clean() was never called. git-svn-id: http://mantisbt.svn.sourceforge.net/svnroot/mantisbt/branches/BRANCH_1_1_0@5594 <a class="text" href="/?p=mantisbt.git;a=object;h=f5dc347c">f5dc347c</a>-c33d-0410-90a0-b07cc1902cb9 |
Affected Issues 0009664 |
|
| mod - core/session_api.php | Diff File | ||
| mod - core/authentication_api.php | Diff File | ||