Mediawiki login cancelled to prevent session hijacking

Question

I have just set up a MediaWiki 1.29.0 page on an AS400 IBM i machine. I am using MariaDB as a database. I am using PHP 5.5.37

Every time I try to log into an account, I get the error:

There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again.

Obviously, the behavior I'm looking for is to log in.

I've tried:

• changing $wgMainCacheType and $wgSessionCacheType to various permutations of CACHE_NONE, CACHE_ACCEL, CACHE_DB, and CACHE_ANYTHING.
• creating a tmp directory and setting its permissions.
• rebuilding my LocalSettings.php file.
• setting session.referer_check=off in php.ini

I've checked and I know my cookies are enabled (I'm able to call document.cookie; and get data back).

This question has been asked before here, and the linked questions within, but no solutions fixed my problem. They also deal with an older version of WikiMedia, though I don't know if that makes a difference in this instance.

EDIT: I am also getting the same behavior when I try to create a new account. However, I am able to navigate the wiki, create pages, and edit pages without any sort of error.

Here is my request header:

Cache-Control: private, must-revalidate, max-age=0
Connection: close
Content-language: en
Content-Type: text/html; charset=UTF-8
Date: Thu, 10 Aug 2017 13:48:36 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Link: </<path>/resources/assets/logo.png?88d75>;rel=preload;as=image
Server: Apache
Set-Cookie: ZDEDebuggerPresent=php,phtml,php3; path=/
Set-Cookie: <wikiname>_session=n7gs0ct99ck5i2juq0togto9q7bfou6u; path=/; secure; httponly
Transfer-Encoding: chunked
Vary: Accept-Encoding,Cookie
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Powered-By: PHP/5.5.37 ZendServer/8.5.5
X-UA-Compatible: IE=Edge

Here is my response header:

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding:gzip, deflate
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Cookie:ZDEDebuggerPresent=php,phtml,php3
Host:tdidev:10080
Referer:http://<wikiepath>/index.php?title=Special:UserLogin&retirnto=Main+Page
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36

Answer 1

I've finally found the issue to my problem. By default, MediaWiki passes the <wikiname>_session cookie with the secure flag set. Taken from OWASP:

The secure flag is an option that can be set by the application server when sending a new cookie to the user within an HTTP Response. The purpose of the secure flag is to prevent cookies from being observed by unauthorized parties due to the transmission of a the cookie in clear text.

To accomplish this goal, browsers which support the secure flag will only send cookies with the secure flag when the request is going to a HTTPS page. Said in another way, the browser will not send a cookie with the secure flag set over an unencrypted HTTP request.

So my MediaWiki installation correctly creates and caches a session token, and it even still passes it through the response header. However, since my browser sees an http instead of https, that's as far as the token gets. The Set-Cookie line is simply ignored.

There is a setting in php.ini called session.cookie_secure, but MediaWiki ignores this flag.

Instead, the solution was to add this line to the bottom of my localSettings.php file:

$wgCookieSecure = false;

Answer 2

I had something similar happen on a different application, when the sessionId was being updated out of sequence.

So normally you request a login form, and it creates a session with a sessionId, and stores this somewhere.

Then you submit the form, it ties that into the original sessionId, checks your authentication, and either logs in the original session, or creates you a new one, and updates yours (normally with a HTTP Set-Cookie command you can see in the Network log).

But you can follow everything, by looking at the sessionId in your current cookies, and any token on the form (to prevent replays), and checking it against either your /tmp/php-session-xxx file (maybe in /var/lib/php) or whatever database it's storing the session in.

What tipped me off to my problem was identifing that by the time I was about to submit a form, with a particular sessionid, that sessionid, was no-longer valid. Hence I failed the replay checks, and I got an error similar to yours. It turned out in my case it was to do with the databases replicating in a way that didn't match how they were being accessed downstream so I could attempt to access a session, that hadn't been created yet.

Looking at all your code, the sessionIds don't match. wpTokenLogin starts with 510a85 but your wiki session in SetCookie starts with n7gs0c and in your log it talks about 6ov933... So assuming you copied/pasted from different attempts, you need to run through it yourself from a clean state and check that everything looks like it's using the same session. If not, try to figure out what's happening to the session you have (if it's created/changed) or why you're not getting the right one, if it's created but never passed out to you properly.

That said, I just took at look at the client side of logging into our own inhouse version of mediawiki, and wpLoginToken, wikidb_session and JSESSIONID don't match either (although I'd expect one of them to show up in the wiki log, which I don't have access too).

If you have to, grep the source for the error message you're finding, and insert error_log(__FILE__.':'.__LINE__.' '.var_export(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS), true)); to find out work back up the stack, to see what didn't match, to generate the error.