Last modified: 2014-11-18 18:07:16 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 6464 - Logged on as someone else.
Logged on as someone else.
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
1.8.x
All All
: High critical with 7 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://startrek.acalltoduty.com/wiki/
:
: 6969 7103 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-27 14:02 UTC by Locutus
Modified: 2014-11-18 18:07 UTC (History)
12 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Locutus 2006-06-27 14:02:56 UTC
First of all, I'll leave the severity and priority fields unchanged because I
didn't take the time review this Bugzilla policy, however this bug should at
least be considered critical though as of now I'm still unable to repeatedly
reproduce it.

Every now and then on the above installation of Mediawiki (1.6.7 straight of the
box) I've found myself logged in as someone else as seen in the following screen
shots:

http://img483.imageshack.us/img483/6339/umm3ez.jpg
http://img163.imageshack.us/img163/5152/umm24jw.jpg

These encourages happen in what appears to be a random fashion and as of now
cannot be repeatedly reproduced, at least by me. From the brief discussion we
had on the Wiki it appears only me and another user are effected.

This seems to happen only when I'm logged already in and seems to stick across
multiple pages and will only return to normal if I log off again. I'm able to do
changes on his account and post as him. (Keep in mind that when I lop on again,
I'm back at my normal account)

One thing I should mention is that the wiki seems to have a cache problem, how
genuine this problem is though I'm not sure. (As seen below)

http://img509.imageshack.us/img509/1787/umm39bt.jpg

So far I've ignored this message and everything as been working as it should.

The user I'm logged on as reports that he finds himself logged in as me as well.
For now I'm not sure if this effected anyone else due to the fact that it isn't
a very active wiki, and most people won't even notice should they'll have the
same problem though you'll have to remember that myself and the other user only
get logged in as each other and not as someone else.

Keep in mind that this happened when I returned to the wiki after a period of
time and during normal operation on the board. Though I don't remember if it was
after a long pause or not.

I have cookies enabled and the "remember me" option turned on.

If you need any more information then please contact me.

P.S. I apologize if I'm posting a duplicate, I wasn't able to find a similar bug.
Comment 1 Brion Vibber 2006-06-27 15:25:42 UTC
Probably a bad caching proxy. Are the two of you on the same 
ISP / school / work web proxy perhaps?
Comment 2 Locutus 2006-06-27 16:48:49 UTC
No, different countries.
Comment 3 Locutus 2006-06-28 01:00:19 UTC
Same person just reported that he was just logged in as someone else beside me,
I should mention that the site I'm talking about was a 1.5.x mediwiki upgraded
to 1.6.7. 

I'm trying to find out if more users are effected by this on the wiki.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-10 19:46:55 UTC
*** Bug 6969 has been marked as a duplicate of this bug. ***
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-10 19:50:47 UTC
Some possibly useful datapoints from the other bug:

(bug 6969 comment #2)
> [[hu:User:Vince]] reported the same on huwiki a couple of hours ago. The links
> to the preferences and watchlist were missing from the personal toolbar,
> everything else was there. He remained logged in as another user after following
> a link. I'll try to get more details.

The bug reporter from bug 6969 gave dewiki as the link, so apparently that's two
or more independent occurrences on at least two different WMF sites.
Comment 6 Locutus 2006-08-11 14:48:07 UTC
Might as well mention that we're still getting the same bug though it seems to
occur more frequently now.

Though I did notice a pattern, it seems the user gets logged in as someone else
when the other user logs in at the same time the user issued a request from the
server.

As I said, it sounds like a cache problem to me.
Comment 7 Daniel Kinzler 2006-08-11 14:58:32 UTC
I copy my comment from bug 6969:

(In reply to comment #1)
> did you just see a page with anotehr user's name on it, or where you
> actually able to edit using the identity of this user? When navigating the wiki
> at random, do you stay logged in as "the other user"?
> 
> In case this happens again, please record the following, if you can: the IP
> address you got for the wiki site, the HTML page itself, the HTTP response
> headers and any cookies you have for the wiki's site. 

If the log in as the foreign user is persistent during navigation (as indicated
by teh reported of bug 6969), or even allows editing as that user (don't know if
it does), then it's *not* a caching issue but a *serious* bug. I would be
especiall interested to know what the user name cookie looks like when this happens.
Comment 8 Locutus 2006-08-12 00:16:19 UTC
(In reply to comment #7)
> If the log in as the foreign user is persistent during navigation (as indicated
> by teh reported of bug 6969), or even allows editing as that user (don't know if
> it does), then it's *not* a caching issue but a *serious* bug. I would be
> especiall interested to know what the user name cookie looks like when this
happens.

Then I can tell how it works here, sometimes you're able to post as that foreign
user, from personal experience I was able to alter the foreign user watch list,
change his personal configuration and I believe that if I tried I would have
been able to change his password.

Keep in mind that our users complained that they were sometimes logged in as the
admin user.

Again, I can confirm you that it only happened when that same user was accessing
the site at the same time.

Keep in mind that sometimes when you're logged in as someone else all it takes
is to refresh the page to return to your own user session.

I'll try giving you the information you requested as soon as possible.
Comment 9 Daniel Kinzler 2006-08-19 13:51:40 UTC
The relevant function appears to be User::loadFromSession - there, the user
id/name from cookie and session could be compared, and if they mismatch, this
should be logged and the session terminated. I'd hope that could give us some
way to track down the problem - in case it's not purely caching.

I'm a bit scared to touch that code, though - I don't fully understand the
implications.
Comment 10 Rob Church 2006-08-19 16:17:10 UTC
I'm inclined to agree that we need to start logging this. If people are being
logged on as others, and the session is persisting, then that's a critical
security flaw and we need to find it and fix it, fast.
Comment 12 Schwalbe 2006-08-21 08:11:21 UTC
A similar thing happened to me on de: at about 21 Aug 09:30 (CEST). See
http://de.wikipedia.org/wiki/Wikipedia_Diskussion:Administratoren/Notizen#Sicherheitsl.C3.BCcke.3F
(with screenshot) for details. I was not able to edit with this account but do
not use the "remember me" option. I never saw the cache problem message
mentioned above.
Comment 13 bdk 2006-08-22 21:26:24 UTC
Just for the case the reporter's location may be of interest to narrow the problem down: 
There was another report on 8th of august by a german IP (Mac user), see:
http://www.mediawiki.org/w/index.php?title=Project:Support_desk&oldid=37786#Automatically_logged_in_as_an_unknown_user

----
Addition to #12 (permanent link):
http://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Administratoren/Notizen&oldid=20518732#Sicherheitsl.C3.BCcke.3F
Comment 14 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-23 18:59:28 UTC
*** Bug 7103 has been marked as a duplicate of this bug. ***
Comment 15 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-24 12:27:33 UTC
Suggestion from Nick Jenkins on Wikitech-l
<http://mail.wikipedia.org/pipermail/wikitech-l/2006-August/038270.html>:

> I've seen the same general type of problem (PHP app that confuses users with no
> immediately obvious explanation) happen exactly twice in a period of 6 years on
> some of my (non-MediaWiki) apps.
>
> I'm not 100% sure why, and it's so rare that it's _extremely_ hard to be sure,
> but my working theory is that by pure random fluke two session_id strings or
> two session file names/keys have clashed, resulting in user identity getting
> confused.
> 
> I recall reading an article in PHP|Architect around a year ago about how you 
> could store the first parts of the user's IP address + the usual session_id
> stuff to lessen the chance of something like this (not eliminate it however,
> since you could still have a large proxy supporting many users, or an
> especially active subnet, and potentially have the same thing) + other various
> tricks to switch the session_id if it looks like someone is trying to spoof it
> or if there's an accidental clash.
>
> As a disclaimer, I have only very superficially scanned some of MediaWiki's
> session handling code (so it could already have these guards, I honestly don't
> know), but *maybe* it's something like this? That's my first thought, anyway.
>
> Certainly the number of WP users is much higher, so the chances of clashes
> happening presumably are correspondingly greater too. (i.e. on a long enough
> time-scale, and with enough permutations, the statistically improbable becomes
> probable).
Comment 16 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-24 16:02:47 UTC
But Timwi gives good reasons for why that can't be the case:
<http://mail.wikipedia.org/pipermail/wikitech-l/2006-August/038302.html>
Comment 17 Platonides 2006-08-27 21:49:08 UTC
Reported at es: Village Pump. User Satesclop appearing logged as Ketamino.
Cookies were disabled. He then brwosed to RecentChanges and "the odd thing"
disappeared:

http://es.wikipedia.org/wiki/Wikipedia:Caf%C3%A9/Portal/Archivo/T%C3%A9cnica/2006/08#Algo_incre.C3.ADble
Comment 18 Daniel Kinzler 2006-08-27 22:16:13 UTC
Uh, with cookies disabled, login wouldn't be possible at all...
Comment 19 Platonides 2006-08-28 21:07:13 UTC
His words: "Not only it, but i also had cookies disabled". I guess he meant he
hadn't 'Remember me' feature enabled... :?
Comment 20 Brion Vibber 2006-08-29 11:29:42 UTC
This may be related to the Squid 2.6 ETag issue. If so, new cases _ought_ not to
show up since yesterday.
Comment 21 Locutus 2006-09-04 20:26:01 UTC
Not sure if this helps anyone but the cookies remain the same even when you're
logged in as someone else, they still point towards your original user even
while you're logged in as someone else. Tested with IE6, 1.6.7. The other user
details persist even while switching pages, and attempting to access the user
configuration page. I'll try to reproduce it with a more sane browser if I'll
get the same problem again.

(Keep in mind, I'm talking about a local installation and /not/ the official
wikipedia servers.
Comment 22 Platonides 2006-09-05 13:03:42 UTC
Then it's an intermal wiki problem, not related to the Squids (i assume you're
only using mysql, php, mediawiki & a browser to loaclhost, without more advanced
cahcing systems, right?).
Comment 23 Locutus 2006-09-05 18:16:51 UTC
MediaWiki: 1.6.7
PHP: 4.3.8 (apache2handler)
MySQL: 4.1.11 

I'm not sure about the latter though, we're talking about a mediawiki
installation that is accessible though the link I posted above.
Comment 24 Travis D 2006-09-18 14:16:07 UTC
We are also experiencing this bug at wikiHow, using MW 1.6.7. 

It does not appear to be a problem related to caching since the affected users
can actually edit pages under the username they appear to be logged in as. So
far, only 2 people can reproduce the problem.
Comment 25 Thomas Goldammer 2006-10-23 11:47:50 UTC
Maybe the same reason: On de.wikipedia, a user denies to have edited an article. He occurs in the history of the 
article, but on Special:Contributions the article does not occur. I guess, another user was logged in as him and 
edited there without noticing that he did that not as himself. Probably the database added the edits to the 
contributions of the one who really did the edits, but saved the wrong account in the history. Grtx.
Comment 26 Brion Vibber 2006-10-24 12:24:59 UTC
Thomas: if that's true, please email details directly to me IMMEDIATELY.
Comment 27 Locutus 2006-10-28 18:20:30 UTC
Maybe I didn't mention this before but people are able to edit articles and
change the user settings while logged as someone else. In fact the sessions
remains persistent until you log off.

The problem seems more consistent when using IE 6, at least from my personal
experience. There was a time I was able to reproduce it every time I visited the
Wiki. Perhaps when another used was preforming an action on the Wiki at the same
time?
Comment 28 Brion Vibber 2006-10-28 21:00:27 UTC
Locutus: please upgrade to 1.8.2, flush any proxy caches, and see if the issue persists.
I have a theory that this issue may have been caused by something which has been changed,
but since we cannot reproduce it we have no way to know without testing.
Comment 29 Travis D 2006-10-29 14:19:29 UTC
Hey Brion,

Is this something I could make a patch for to test out on 1.6.7? I could put it
in place, and ask anyone who experiences the problem again to let me know - our
users seem to run into it reliably. Upgrading is a huge process for us
unfortunately, and takes a few weeks to do.

Thanks.
Comment 30 Brion Vibber 2006-10-29 17:30:00 UTC
Here's the changes on trunk:
r1=16475&r2=16649&view=patch">http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/RawPage.php?r1=16475&r2=16649&view=patch

I haven't tested it on 1.6 but it does appear to apply cleanly.
Comment 31 Travis D 2006-10-30 16:23:49 UTC
Hi Brion,

Thanks. This patch seems to only affect situations where action=raw, correct?
Our users are having this problem just viewing pages normally, and can actually
edit articles while logged in as other users. I don't think anyone views the raw
version of our pages at all, logged in or not logged in. 

Comment 32 Locutus 2006-10-30 19:32:00 UTC
We can't update to 1.8.*, we don't have access to PHP5.
Comment 33 Brion Vibber 2006-10-31 12:18:45 UTC
Travis, I'm aware of what the patch changes, which is exactly why I recommend it to you.
If you like I can explain this in detail offline.

Locutus: PHP 5 is available for free under an open source license, and is already present
on countless thousands of hosting providers as well as anywhere you choose to install it.
If you choose to stick with older, buggier software that's your choice.
Comment 34 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-31 04:08:14 UTC
New sighting on the Japanese Wikipedia:
http://lists.wikimedia.org/pipermail/wikitech-l/2007-January/029303.html
Comment 35 wiki_tomos 2007-02-05 09:53:35 UTC
More instances are reported on Japanese Wikipedia. 

http://ja.wikipedia.org/wiki/User:Trashwriter reported that 
account mix-up happened to him again. 

The following edit was attributed to user:Gwkaakun, though 
it was his own.

http://ja.wikipedia.org/w/index.php?title=Wikipedia:%E5%89%8A%E9%99%A4%E4%BE%9D%E9%A0%BC/%E9%A7%90%E8%BB%8A%E5%A0%B4%E7%B6%9C%E5%90%88%E7%A0%94%E7%A9%B6%E6%89%80&diff=10376487&oldid=10374004

Trashwriter also reports that there are more than 10 edits in his 
contribution records that are not his own. 

Also, http://ja.wikipedia.org/wiki/User:%CE%A3%EF%BC%96%EF%BC%94
(I will call him Sigma64 hereafter) reported that he experienced 
this glitch four times in the past 2 days. 

He said one image was posted under his username, but it is done by 
someone else. He considers this problematic, though he 
does not mind to be attributed for edits on regular articles. 

He requested the image to be deleted. 

He said that he was once logged on as User:Annet152. User:Annet152, 
when asked by User:Sigma64, said that he, too, was affected by the glitch. 

User:Sigma64 thought User:Annet152 was the one who posted the image 
to Wikipedia, but User:Annet152 said he did not do that. 


---- 

User:Trashwriter reported his environment when the bug took effect:
-Windows XP 
-IE7.0.5730.11
-ISP: airH" with no proxy. 

I think airH" is a mobile internet service that typically routes packets 
from a computer (or other device) to a mobile phone, which in turn send it 
to the mobile phone company offering the service, and then to an ISP's 
dual-up service that the user is subscribed to. 

He saved a copy of cookie when the bug took effect, as requested by a developer. 
He wants to know how to send it, and to whom. 
Comment 36 Brion Vibber 2007-02-05 22:48:23 UTC
I made some more tweaks in r19795 which may or may not affect this issue;
said issue also may or may not be related to some temporary squid problems
we had a week or so ago, which may or may not be completely resolved and
may or may not have left some bad cached entries which may or may not
still have some effect.

Live code hasn't been updated yet, so give it some time.
Comment 37 Scott Gunther 2007-06-04 13:40:41 UTC
I would like to report a possible case of someone being logged in as me.

My username on the english wikidpedia is "Scotteaux" and on March 19 there was a contribution made with my username to "Private university."  I am certain that I did not make this change. I only access wikipedia from home and so I can't imagine how anyone would have been able to have access to my account.
Comment 38 Matt 2007-06-28 04:23:35 UTC
I've been reading through the code, and this definately sounds like session collisions - I met this problem on a previous PHP application I was running. A simple way to fix should be to store the client's IP in a session variable, then in  User::loadFromSession compare the session IP to the clients IP. Another option would be to salt the session key with the IP - however then you still have a chance of collision. This would also increase security, however it would mess up users whos IP changes while on the internet - as far as I know, this would be very hard to do under TCP/IP, and should not happen

-Matt

Comment 39 Brion Vibber 2007-06-28 13:23:23 UTC
Roaming IPs are not uncommon with AOL, which uses a very ugly proxy system.
Comment 40 Matt 2007-07-22 23:53:59 UTC
What about storing a "session key" in the user table, generated from something like this:

$sesskey = md5($_REQUEST['REMOTE_ADDR']) . md5($user->name . $user->id);

NOTE: I couldnt remember the exact feilds for name and id, but those seem accurate enough.
Store it in a cookie, then on pageload, compare the session key of the cookie to the one in the DB. If its incorrect, log the user out. The key would be updated in the DB on login. The only problem with this is the user cannot be logged in from two IP addresses at once - this is added security anyway, so no problem. The key may have to have more information to make it harder for collisions, but should be fine.
Comment 41 Platonides 2007-07-23 10:19:22 UTC
It would also conflict with the 'Remember me' option, failing to keep the used logged if it changes ips since first login (ie. a period of days).
Comment 42 Voyagerfan5761 / dgw 2007-09-21 15:27:30 UTC
Just as a general comment, IP salting would be rather frustrating, since I often change locations in the span of a day with the same computer. Having to log back into the software would definitely disrupt routine, in my case.
Comment 43 Aaron Schulz 2008-10-13 05:32:01 UTC
It would help a lot if loadFromSession() matched the user name to the ID
Comment 44 Matt Johnston 2008-10-13 08:43:40 UTC
Doesn't it do so on line 846?
Comment 45 Aaron Schulz 2008-10-13 14:19:03 UTC
(In reply to comment #44)
> Doesn't it do so on line 846?
> 

I mean checking the cookie username to the session username value
Comment 46 Aaron Schulz 2008-10-13 18:42:28 UTC
Cookie user ID checked in r42040 to limit accidents like the above

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links