Skip to content
Advertisement

Mediawiki login cancelled to prevent session hijacking

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

Advertisement

Answer

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;

User contributions licensed under: CC BY-SA
6 People found this is helpful
Advertisement