Hello, At en wikipedia, I clicked edit on Talk:British Isles (terminology) and received this message:
-- User is blocked
Your user name or IP address has been blocked from editing. You were blocked by Pathoschild for the following reason (see our blocking policy): Autoblocked because your IP address has been recently used by "Ilikesheeeeeeeeeeep". The reason given for Ilikesheeeeeeeeeeep's block is: "Violation of the Username policy (too long, confusing,
Your IP address is 72.14.192.5.
...etc. --
This was obviously some kind of database fart because it disappeared when I tried again, and because that IP address isn't close to mine :) Anyway, just thought I'd mention it.
Steve
Some days ago on de.wp a user reported that he suddenly was logged in as another user on Wikipedia. That happend on his own desk and in in his opinion it was not possible that anyone else was at his computer. Maybe this is associated with this problem? Imagine an anonymous is suddenly an admin ...
On 8/23/06, Pill wiki.pill@googlemail.com wrote:
Some days ago on de.wp a user reported that he suddenly was logged in as another user on Wikipedia. That happend on his own desk and in in his opinion it was not possible that anyone else was at his computer. Maybe this is associated with this problem? Imagine an anonymous is suddenly an admin
Dunno, but also in the last few days I'm suddenly finding I'm being logged out a lot at en. Normally, I don't ever have to log in at home or work - not for weeks on end. However, in the last few days, once I very clearly was logged in, clicked edit, and was suddenly editing in anonymous mode. Wonder what's going on?
Steve
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).
All the best, Nick.
-----Original Message----- From: wikitech-l-bounces@wikimedia.org [mailto:wikitech-l-bounces@wikimedia.org]On Behalf Of Pill Sent: Thursday, 24 August 2006 7:11 AM To: Wikimedia developers Subject: Re: [Wikitech-l] Weird block message
Some days ago on de.wp a user reported that he suddenly was logged in as another user on Wikipedia. That happend on his own desk and in in his opinion it was not possible that anyone else was at his computer. Maybe this is associated with this problem? Imagine an anonymous is suddenly an admin ...
-- -- Pill (wiki.pill@gmail.com) _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Pill schrieb:
Some days ago on de.wp a user reported that he suddenly was logged in as another user on Wikipedia. That happend on his own desk and in in his opinion it was not possible that anyone else was at his computer. Maybe this is associated with this problem? Imagine an anonymous is suddenly an admin ...
There's also a bug report for that:
http://bugzilla.wikimedia.org/show_bug.cgi?id=6464
-- L.
On 8/24/06, Nick Jenkins nickpj@gmail.com wrote:
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.
Talking out of my arse here, but if that happened, would you expect the problem to be cleared up simply by refreshing? Wouldn't it persist until you logged out?
Steve
Nick Jenkins wrote:
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 had that thought too, but Steve already explained why this is not the cause.
In addition, also note that the original posting that started this thread was talking about a block message. Blocks are per IP, not per session token, so this falsifies your theory too.
The original report shows that for some pageviews, the system thinks you're coming from a different IP than you really are.
My theory is that the system (either MediaWiki or the squids) mixes up two simultaneous connections. Two people requesting a page from the same server (or the same squid) at the same time, and both receiving the output that was meant for the other person.
As long as such pageview mix-up is extremely rare, there is next to no chance for anyone to exploit it maliciously, but it *is* possible, and it becomes more possible is this happens more frequently.
By the way, I have reason to believe that PHP makes sure that session tokens are unique when they are assigned.
Timwi
On 8/24/06, Timwi timwi@gmx.net wrote:
As long as such pageview mix-up is extremely rare, there is next to no chance for anyone to exploit it maliciously, but it *is* possible, and it becomes more possible is this happens more frequently.
Ok, brainstorming, I guess someone could constantly attempt to pageview a page that required administrative privileges (like unblocking themselves), and hope by sheer chance that an admin ended up getting their pageview? Interestingly there aren't really any privacy implications that I'm aware of, as there are almost no pages for which *read* access is restricted to certain users.
Steve
On 24/08/06, Steve Bennett stevage@gmail.com wrote:
Ok, brainstorming, I guess someone could constantly attempt to pageview a page that required administrative privileges (like unblocking themselves), and hope by sheer chance that an admin ended up getting their pageview? Interestingly there aren't really any privacy implications that I'm aware of, as there are almost no pages for which *read* access is restricted to certain users.
Depending upon your point of view, being able to nip into someone else's preferences and read their email address might be considered an exposure of private data.
Even if the problem *was* that other user's page views were being served up (as far as I'm aware, it's a credentials problem, right?) then the token mechanism we have in place should protect against that, theoretically.
Rob Church
On 8/24/06, Rob Church robchur@gmail.com wrote:
Depending upon your point of view, being able to nip into someone else's preferences and read their email address might be considered an exposure of private data.
Ah, preferences, didn't think of that.
Steve
Hello, I once had a similar problem, I never bothered to tell someone about it:
I logged in to de.wikip as Abzt. The message was: You are now logged in as !bzt. That was strange, and I just thought, "probably a bug, let's go to the main page. I was suddenly logged in as Elian, and I had all rights which elian had. I logged out immediately, and the message was "You are now logged in as Abzt". How could this be?
Hello, At en wikipedia, I clicked edit on Talk:British Isles (terminology) and received this message:
-- User is blocked
Your user name or IP address has been blocked from editing. You were blocked by Pathoschild for the following reason (see our blocking policy): Autoblocked because your IP address has been recently used by "Ilikesheeeeeeeeeeep". The reason given for Ilikesheeeeeeeeeeep's block is: "Violation of the Username policy (too long, confusing,
Your IP address is 72.14.192.5.
...etc.
This was obviously some kind of database fart because it disappeared when I tried again, and because that IP address isn't close to mine :) Anyway, just thought I'd mention it.
Steve _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
The message was: You are now logged in as !bzt. That was strange, and I just thought, "probably a bug, let's go to the main page. I was suddenly logged in as Elian, and I had all rights which elian had. I logged out immediately
If it happens to you or anyone else again, please do not log out.
Save a backup copy of the cookie file/details, jump onto IRC and do a /join #wikimedia-tech , and tell them that you're logged in as someone else when you shouldn't be.
I'm honestly not sure what'll happen then, but as far as I'm aware we have yet to capture this whilst it's happening (rather than after-the-fact).
All the best, Nick.
On 9/11/06, Nick Jenkins nickpj@gmail.com wrote:
Save a backup copy of the cookie file/details, jump onto IRC and do a /join
Can you explain what you mean by "cookie file/details"?
Steve
"Steve Bennett" wrote:
On 9/11/06, Nick Jenkins wrote:
Save a backup copy of the cookie file/details, jump onto IRC and do a /join
Can you explain what you mean by "cookie file/details"?
Steve
Cookies of the wiki site you currently have. You can use an extension like WebDeveloper to show them.
"Steve Bennett" wrote:
On 9/11/06, Nick Jenkins wrote:
Save a backup copy of the cookie file/details, jump onto IRC and do a /join
Can you explain what you mean by "cookie file/details"?
Steve
Cookies of the wiki site you currently have. You can use an extension like WebDeveloper to show them.
In Firefox, you can get to the Firefox Cookie Manager by going Tools -> Options -> Privacy -> Cookies -> View Cookies -> search on "en.wikipedia.org" -> gives a list of 4 "enwiki" cookie details, namely "Token" (a string like "190a876023442342327c4c63fac6234"), my "UserID" (a integer like 83912), my session id (generated by PHP, a string like "ce679422680757a63b324238cae08fcc"), and a UserName ("Nickj" in my case). (And just to be clear, I have modified those token / UserId / session values from their actual real values to prevent session hijacking).
Alternatively, you can look at the raw cookie file - it's just a text file : * In Internet Explorer, cookies are stored on a single file-per-cookie basis, and the path would be something like this: "%SystemDrive%\Documents and Settings%username%\Cookies%username%@en.wikipedia[1].txt" * In Firefox, it looks like they're all stored in one file, whose path is probably something like this on a Windows system: "%SystemDrive%\Documents and Settings%username%\Application Data\Mozilla\Firefox\Profiles%MOZ-PROFILE-NAME%\cookies.txt"
Essentially cookies are a form of persistent client-side storage for letting the server store simple state and having the client communicate that state back to the server in subsequent requests; in less jargony terms, it's what allows you open a browser, to log into the Wikipedia, close the browser, reopen the browser, go to the Wikipedia again, and still be logged in: it's remembering who you are. And that's why when it goes wrong, and people end up being treated as users that they're not, then getting the cookie details is the first port of call to see what's going wrong. It could also be good to have a look at the server-side cookie details (e.g. cookies can be stored on the server side in a database, on disk, etc.) for any open sessions for the user they've become, and for the user they're supposed to be. Where to go from there is less clear ;-) but that's probably where to start.
All the best, Nick.
wikitech-l@lists.wikimedia.org