| Re: Session hijacking vulnerability in XOOPS 2.0.7.3 |
| by Mithrandir on 2005/5/8 21:46:53 you can disable session.trans_sid in your PHP settings, but since it is a PHP thing, we can not do much about it in XOOPS itself. Disabling the trans_sid will make it mandatory for users to enable cookies, which is a fair assumption for most sites, I'd say, but not one we can enforce completely in the XOOPS core as there may be situations where a webmaster will want to allow cookie-blocking users (I believe PDA's don't store cookies, but there may be other examples, too) and it would be rather annoying if XOOPS blocked this possibility altogether. |
| Re: Session hijacking vulnerability in XOOPS 2.0.7.3 |
| by javier on 2005/5/8 20:52:25 This problem is in XOOPS 2.0.10 too? Because i having the same problem in 2.0.10, exist any way to fix this? best regards |
| Re: Session hijacking vulnerability in XOOPS 2.0.7.3 |
| by LazyBadger on 2004/12/3 5:29:41 Quote:
You problem is more problem of your PHP-settings, than XOOPS, and even with fresh install or another CMS you can get same headache. Why not disable session.trans_sid totally? Or play also with sessions management (session type and session timeout)? Currently your sessions haven't timeouts |
| Re: Session hijacking vulnerability in XOOPS 2.0.7.3 |
| by chrisis on 2004/12/3 4:00:58 No, it's still the old link. The original link with a phpsessid in it STILL gets into the site as the last-logged-in person, despite emptying the sessions table. It's weird as. ANyway my site is about to die, it's been down over a week now. I'm going to try copy over the files on my site with a default clean set downloaded from here... if that doesn't work I will switch to a new CMS. |
| Re: Session hijacking vulnerability in XOOPS 2.0.7.3 |
| by ajaxbr on 2004/12/1 11:23:12 Well, let me see if I got this right: the old link, the one listed in an IRC channel, did stop working but now you can do it again with a new session value? If this isn't the case, we need to understand how/where the sessionid is being kept (could be a cookie?), but if you got a brand new sessionid... let's say we'll have to think a bit harder to try to solve that  I don't think that session hijacking needs the remember me hack, because when I monitor my xoops_sessions the same session is used for my IP when I log in again (same user, same IP). Now, since that table stores both session ID and IP, it seems logical that some kind of check using the IP should be happening and I'm not sure if it is (or whether the hack could have removed that). Again, if any of you want to explore this kind of issue in my server, PM me and we can work it out. |
Search
Recent Posts
Who's Online
Donat-O-Meter
| Stats | |
| Goal: | $15.00 |
| Due Date: | Jul 31 |
| Gross Amount: | $0.00 |
| Net Balance: | $0.00 |
| Left to go: | $15.00 |
|
|