THis seems like a lot of effort over a shared server.

I mean...how do you gauge the file permission structure if the server is shared as such? It seems wise to take someones offer up on mirroring it...because this thread doesnt make sense and is causing undue alarm.

You ar insinuating its XOOPS. It's not.
You say you've modified files...but that it's too late to fix 'em. So how can someone help you?
---
(Im sorry if this sounds rude, I don't mean to be, it just seems that posting title "security problem" should be "my security problem".

-

Best of luck though and hopefully someone will be able to figure it out. But without root acces I dont see how.
But it will get resolved, have faith. I've seen murky depths too...but its turned out well in the end.

Perhaps you could tell us what modifications you have made to the XOOPS core files. If you are concerned about someone capitalizing on a vulnerability, you could PM your mods to a XOOPS Dev.

IMHO, no CMS is 100% secure, but out the four sites I manage, not one of them is exibiting this problem. Of course, I haven't tampered with the XOOPS core files either. I'm willing to wager that your problem resides in your modifications, not Xoops.

However, unless you share the details of your mods with the XOOPS Devs and try the suggestion of using someone's mirror, there's not much else that can be done.

BTW... Shared hosting for a University?!? I attend college at WVU-P [pretty small campus] and even we have our own Web and DNS servers. If you're really concerned about security, shared hosting is not the most secure route to go. Talk to your Network Admin and see if they can set you up with a secure server. It only takes a little bit and it could be the solution to your problem. Just a suggestion.

As i have mention many times the problem occured before the mods were put in place.

The site is a student run web site for the students, it came out that the administation was doing something and the student body wasnt happy so they made a web site. But then it got taken on that this site would replace the schools internal site.

The share server, is my server, I run a small hosting company and I run it on my server. There has been no security problems on this server.

My programming team will be finishing thier documentation soon, right now they are working their butts off to get the 2.0.7 update ready.

Basically from what i understand from my programmers the only major change they made to the core, was editing and adding some class files for our registration process.

Since we're having a hard time reproducing this behaviour, there's not much more we can do other then guessing. Do you have the login block cached? Do you have custom sessions turned on? Do you have the auto-login hack enabled? Did you check the database table integrity? Have you tried turning on debug and see if some error comes up when this happens? Anything that could give us a clue as to what is causing this.

Also, check the server setup with the other person who reported this happening with custom sessions on. Maybe it's a server issue we need to take into account in the future?

Changing the registration process could very well mess things up, as your users are reporting that they are logged in as someone else. Can you verify this issue with a clean install on the same server, but in a subdir, so it exists next to the current site?

Herko

i've tried many times to reproduce this problem and couldn't.

like as i mentioned previously in this thread i had a similar occurence but wasn't all the time i only ever had 2 reports from members on my site that it had happened and i actually saw it happen once to myself..

but even tho it said i was logged in as somebody else when i tried to click a link to view that users profile etc, it gave me an error message saying i don't have permission to ....... and then i hit refresh and i was back in my own account..

but this problem has never repeated itself at all, altho i have made lots of changes..

when it happened to me i was using XOOPS 2.0.6 and ipbm 1.3, but now using XOOPS 2.0.7 and ipbm 1.4d.

my server host also updated their servers a while back which took our site offline for a couple days till they had finished.. so there could be a number of factors.

i would do as suggested, remove all modules!!! and see if the problem exists then..

i would also try turning custom session off and actually changing the name of the cookie prefix too.. just to be sure, with a new cookie name, every1 will have to login again and be issued with a new cookie.. it's worth a try..

Quote:

Have you tried a default install of 2.0.7?

As I mentioned before, I have four sites that currently run 2.0.6 and I cannot reproduce this error. I strongly recommend that you take advantage of the offer of mirroring your site to rule out server configuration. I'm sure you're quite competent at what you do, but even the best overlook things sometimes.

Quote:

You may want to submit your modifications to the Devs to make sure they do not pose a security risk. Nobody knows XOOPS better than the people that made it.

Food for thought.....
The beauty of open source is that many eyes are searching for the needle in the hay stack. Even though you may have looked at an area 10 times and saw nothing, the other people who are looking may look in the same area and find the needle the first time.

If you share you files with those who made Xoops, you may find that your problem will be solved more efficiently.

Quote:
Well, I don't think that's entirely true. There is obviously something about the way XOOPS does sessions that, on certain servers, causes problems. If there wasn't, it wouldn't have happened on our site as well!

Just because it doesn't happen to everyone doesn't mean it's not a bug. We just have to figure out why it happens, and how to get rid of it.

Now, for us the solution was to turn custom session handling off. At least, no-one has reported the problem since then! So what is it about custom session handling that could cause this, and what are the common factors in the servers that have exhibited the problem? That's the line of questioning we should follow. I don't think it's terribly helpful to suggest that the original poster is at fault because it couldn't possibly be XOOPS

BTW, we modified no core XOOPS files.

Oh, and if you wanted to see 'undue alarm' you should've seen the other site admin and myself on Sunday night when we discovered the security problem, about an hour after the site went live!