XOOPS 
Forum
Forum Index General Forums Community Support Modules Support Themes Support Development International Support Module Hack Reviews Theme Designer Talk
  1. Board index / 
  2. Xoops Development / 
  3. Xoops Bug Reports 
  4.  / Session hijacking vulnerability in XOOPS 2.0.7.3
Register
1
andersa
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
ackbarr
Re: Session hijacking vulnerability in XOOPS 2.0.7.3

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
tl
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
chrisis
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
chrisis
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
DonXoop
Re: Session hijacking vulnerability in XOOPS 2.0.7.3

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
ajaxbr
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
DonXoop
Re: Session hijacking vulnerability in XOOPS 2.0.7.3

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
chrisis
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
chrisis
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);
(1) 2 »

Login

Register now!  |  Lost Password?

Search

Advanced Search

Recent Posts

Who's Online

370 user(s) are online (266 user(s) are browsing Support Forums)

Members: 0

Guests: 370

more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Nov 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits