Users get logged in automatically as different user

Question

This sounds very weird. But currently users of our site is seeing this behavior randomly.

When they browse anonymously the site they gets logged in as a different user. They got logged in as users which is actually currently logged into the system. They can perform all actions on behalf of that user.

Our system is built in with modx evolution 1.0.4. We have used WebLogin snippet for login system.

Is this behavior possible with man in the middle (MITM) attack?

Update

I have stored a list of cookie and ip received per request in server side. I see same session value from different ip's same time. This value is generated using session_id(). How it is possible different machines getting same value at the same time?

This definitely looks like a caching issue, as the other posters have pointed out in the answers. You can have MODX output the user's ID to see if they are logged in or not (anonymous should return a user ID of "0"). Just create a snippet called *getUserID*, containing the following code: `getLoginUserID();`. Then call it uncached on your site. — okyanet, May 12 '14 at 03:25
What is your session.hash_function value? Could you have proxies and/or caches in front of your app that (inadvertently) change/cache headers? Maybe you could get some clue by configuring your webserver to log request and response headers. — Levente Pánczél, May 22 '14 at 20:24
@chanchal118 Pleas accept an answer to finish the question process. Probable mine ;-) — SteAp, May 01 '22 at 21:56

score 2 · Answer 1 · answered May 09 '14 at 15:35

2

This sounds like a caching issue. Try calling weblogin uncached [!WebLogin!] instead of [[WebLogin]]

answered May 09 '14 at 15:35

orbitory

1,090
5
16
40

I have tried calling all snippets uncached. I have update my question with my new findings about session. – chanchal118 May 17 '14 at 06:28

score 2 · Answer 2 · answered May 09 '14 at 16:12

I agree with orbitory that it sounds like a caching issue. In addition to the WebLogin snippet, if you have any other snippets or chunks that contain personalized information, make sure they are called uncached as well. Otherwise, what happens is that if your site cache is cleared, and then a user logs in, any personalized content generated by a snippet for that user will get cached with the page, and all users will see it.

score 2 · Answer 3 · answered May 23 '14 at 18:35

I've seen this sort of thing happen before due to improper seeding of the random number generator (RNG). Does your application deal with random numbers? Do you seed the RNG yourself? Don't.

Your app may start up 10 processes and each one may get the same RNG seed, so they all start to produce the same series of random numbers, creating duplicate session tokens.

Processes may get the same random seed because you're seeding the generator before you fork or because they are all seeding at the same time from the current time of day, which will be identical for them all.

Best to just not seed the RNG yourself - it should take care of itself on any sane platform.

Unless there's some reason you want an identical series of random numbers, in which case you should create a separate pseudo-RNG that's distinct from default one.

I have set seesion_id() as cookie value. – chanchal118 May 24 '14 at 02:45 — chanchal118, May 24 '14 at 02:45

score 1 · Answer 4 · answered May 18 '14 at 10:39

I donot think this is related to cache, there might be multiple possible reasons.

First try these for generating a unique session:

//For successfully truncating a session
if (ini_get("session.use_cookies")) {
    $params = session_get_cookie_params();
    setcookie(session_name(), '', time() - 42000,
        $params["path"], $params["domain"],
        $params["secure"], $params["httponly"]
    );
}

//For generating a unique id for every session
session_regenerate_id(true);

Also, please check if the mysql resource is returning correct user identifiers every time, its just a wild guess, but make sure this might be a possible suspect.

score 1 · Answer 5 · answered May 22 '14 at 04:45

1

If you Edit This value in your php.ini file, it may solve the problem

session.use_strict_mode = 1

answered May 22 '14 at 04:45

Masum Nishat

358
1
15

I found it interesting if use_strict_mode made any difference here, since that only allows non-existing sessions to be started up (but those are uninitialized so they would not be sessions already logged in). If this step shows improvement for anyone, I'd love to see the causes. – Levente Pánczél May 22 '14 at 20:11

score 1 · Answer 6 · edited May 23 '17 at 12:11

Regarding man-in-the-middle attacks

Please note, that hijacking a foreign user session is perfectly possible if your site uses the HTTP protocol.

To protect against session hijacking attacks, you need to enable HTTPs.

HTTP transfers the data related to requests and replies as simple text (not encrypted).

Since the session ID is either kept in a cookie or in URLs (please don't use that option!), a MITM attacked simply reads out the session ID. Then, the MITM attacker sets the session ID cookie in his browser and owns the other user's identify.

To get a session ID, the MITM needs a privileged location regarding the client's network route to a server system. The attacker either needs to sit in-between the client system and the server system. Or it needs to sit in the client's network and mimic to be the default router of the client system.

Regarding the session issues

What value does modx' system property session_handler_class has?

If it is the default value modSessionHandler, modx uses database managed session. Leave the setting blank to instruct modx to enable standard PHP session handling.

Regarding cache issues

Caching typically persists and retrieves data sent to the client, e.g. HTML-code. Typically, you won't find cookies in cached files.

If an anonymous user X suddenly get's the session cookie of another logged-in user, modx needs to somehow find the other user's session.

If the session IDs are non-trivial long, it's quite unlikely to guess a session ID of another user. Likewise, it's very unlikely to grab the persisted session data of another user.

... unless modx somehow iterates through the set of all persisted sessions - instead of just grabbing the correct persisted session file.

Therefore: Lookout for search operation within the session handling of modx.

Trace execution using PHP's tick feature

As a very last resort, you might enable PHP's tick feature:

Do this at the beginning of your app (e.g. in index.php):

declare(ticks=1);
register_tick_function('traceStatements', true);

Then, define the tick function:

function traceStatements() {

      $traceInfo = debug_backtrace();

      // Use $traceInfo to identify the last method called
      // Trace the method to a central log file
      // Create a new log file per incoming http request

}

Using this code traceStatements() get's called at each executing PHP statement. You might use this mechanism to prepare several traces of different client requests - and compare each other.

Have a look here for some trace code, which might be of help.

Users get logged in automatically as different user

Update

6 Answers6