Session hijacking vulnerability in XOOPS 2.0.7.3 [Xoops Bug Reports]

1

Session hijacking vulnerability in XOOPS 2.0.7.3

2004/11/11 16:10
andersa
Just popping in
Posts: 45
Since: 2004/5/27

If you send a link to an article or forum post to someone, and the link contains the PHPSESSID, the recipient will be able to post under your name whether he is a member or not.

Shouldn't a session id be associated with some kind of other security check on the server side, for instance an IP number?

2

Re: Session hijacking vulnerability in XOOPS 2.0.7.3

2004/11/11 17:09
ackbarr
Posts: 1449
Since: 2002/10/2

the PHPSESSID you speak of is something added by PHP, not by XOOPS. If you are on a hosted server adding this to the beginning of mainfile.php should modify php's settings:


ini_set('session.use_trans_sid', false);

If you are running XOOPS on your own server, you can make this setting the default for PHP apps by changing this setting 'session.use_trans_sid' in your php.ini. You'll need to restart apache for this change to take effect.

This is well discussed online, I have included a forum post discussing the issue from a webhosting forum as reference:

http://www.webmastershome.com/detail18.html

3

Re: Session hijacking vulnerability in XOOPS 2.0.7.3

2004/11/11 17:31
tl
Friend of XOOPS
Posts: 999
Since: 2002/6/23

You may have to add
ini_set("url_rewriter.tags","");
before
session_start();
in include/common.php, if your php is compiled as Apache module.

The best way as ackbarr suggested is to set
session.use_trans_sid off in php.ini, if you can of course.

4

Re: Session hijacking vulnerability in XOOPS 2.0.7.3

2004/11/24 5:21
chrisis
Just popping in
Posts: 17
Since: 2004/7/2 2

My site has had this done to it... and unfortunately someone posted the link it an irc channel.

I've made the changes suggested here, but ppl still have that link and it still works....!! If I login, and someone tries the link, they get access to the site as my username!

Is there any way of locking my site down so that the PHPSESSID string has no effect, after the fact?

Thanks for your help -- my site is down for now and I can't bring it back up till I have a solution. :(

5

Re: Session hijacking vulnerability in XOOPS 2.0.7.3

2004/11/25 23:42
chrisis
Just popping in
Posts: 17
Since: 2004/7/2 2

Can nobody help me with this, please? My site is still down becuase I don't know how to prevent the bug exploiting my site once the url is already out there.

PLEASE help -- I'm totally stuck atm.

Quote:

chrisis wrote:
My site has had this done to it... and unfortunately someone posted the link it an irc channel.

I've made the changes suggested here, but ppl still have that link and it still works....!! If I login, and someone tries the link, they get access to the site as my username!

Is there any way of locking my site down so that the PHPSESSID string has no effect, after the fact?

Thanks for your help -- my site is down for now and I can't bring it back up till I have a solution. :(

6

Re: Session hijacking vulnerability in XOOPS 2.0.7.3

2004/11/26 0:19
DonXoop
Posts: 1171
Since: 2003/11/27

Won't the session id expire when you logout? Are you using a "remember me" hack or a really long session timeout? I would think that you could logout properly and then get a new session id next time. Clear out the caches and your local cache and cookies.

It is safer to not use a remember me hack for the admin logins. Even better to make a dedicated webmaster that you don't use for day to day browsing of your own site.

Good luck.

7

Re: Session hijacking vulnerability in XOOPS 2.0.7.3

2004/11/26 0:28
ajaxbr
Quite a regular
Posts: 276
Since: 2003/10/25

Hi chrisis,
What is the uid affected?

If you know what the bad link is and have phpMyAdmin access to your XOOPS DB, go to the table xoops_session find the offending session that is referenced in your link and remove it.

If you don't know the bad link, I'd suggest 2 things: first, register a new user (don't login yet, just create a new user and finish registration), login as admin and quickly go to your URL/modules/system/admin.php?fct=preferences&op=show&confcat_id=1 and set "use custom session" to true, and even more quickly go to groups and add the new user to the webmasters group, then remove the affected admin user from it. Now, this can be dangerous, so if you can create a backup of your site and try these modifications in a test server, do it first.

Perhaps just deleting all sessions from that table will work too?

8

Re: Session hijacking vulnerability in XOOPS 2.0.7.3

2004/11/26 0:36
DonXoop
Posts: 1171
Since: 2003/11/27

Quote:

Perhaps just deleting all sessions from that table will work too?

This is what I would suspect could fix the problem. For sanity I'd back up the table then logout of the site then empty the table from a stand alone connection (phpmyadmin, command line, etc.).

9

Re: Session hijacking vulnerability in XOOPS 2.0.7.3

2004/11/26 2:26
chrisis
Just popping in
Posts: 17
Since: 2004/7/2 2

Thanks for the tips -- I'll give these a go.

10

Re: Session hijacking vulnerability in XOOPS 2.0.7.3

2004/11/26 5:19
chrisis
Just popping in
Posts: 17
Since: 2004/7/2 2

Quote:

DonXoop wrote:
Won't the session id expire when you logout? Are you using a "remember me" hack or a really long session timeout? I would think that you could logout properly and then get a new session id next time. Clear out the caches and your local cache and cookies.

It is safer to not use a remember me hack for the admin logins. Even better to make a dedicated webmaster that you don't use for day to day browsing of your own site.

Good luck.

I am using a "remember me" hack, implemented by a developer that helped set up the site. Unfortunately my users pretty much demanded it, which is why it is there.

I'll take this advice from here on out -- to not have the admin user remembered. That will protect me from someone getting admin access, but I still have the problem of the phpsessid. I've made the original changes, but being unsure of things, could someone look over this and tell me if I have the correct line in the correct place in mainfile.php?


//  You should have received a copy of the GNU General Public License        //

//  along with this program; if not, write to the Free Software              //

//  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA //

//  ------------------------------------------------------------------------ //



// added by Chrisis to combat session hijack via php

ini_set('session.use_trans_sid', false);



if ( !defined("XOOPS_MAINFILE_INCLUDED") ) {

    define("XOOPS_MAINFILE_INCLUDED",1);

Stats
Goal:	$100.00
Due Date:	Apr 30
Gross Amount:	$0.00
Net Balance:	$0.00
Left to go:	$100.00

Session hijacking vulnerability in XOOPS 2.0.7.3

Re: Session hijacking vulnerability in XOOPS 2.0.7.3

Re: Session hijacking vulnerability in XOOPS 2.0.7.3

Re: Session hijacking vulnerability in XOOPS 2.0.7.3

Re: Session hijacking vulnerability in XOOPS 2.0.7.3

Re: Session hijacking vulnerability in XOOPS 2.0.7.3

Re: Session hijacking vulnerability in XOOPS 2.0.7.3

Re: Session hijacking vulnerability in XOOPS 2.0.7.3

Re: Session hijacking vulnerability in XOOPS 2.0.7.3

Re: Session hijacking vulnerability in XOOPS 2.0.7.3

Login

Search

Recent Posts

Re: Rebuilding and Updating a 20 years old Xoops Website from 2.0.18? to 2.5.11

Rebuilding and Updating a 20 years old Xoops Website from 2.0.18? to 2.5.11

Re: NewBB v 5.1.0 b 6

Re: NewBB v 5.1.0 b 6

NewBB v 5.1.0 b 6

Re: XOOPS 2.5.11 search user is not working

Re: oledrion

Re: oledrion

Re: oledrion

Re: oledrion

Who's Online

Donat-O-Meter

Latest GitHub Commits

{{ record.sha.slice(0, 7) }} - {{ record.commit.message | truncate }}