已取消Mediawiki登录以防止会话劫持

我刚刚在AS400 IBM i机器上设置了MediaWiki 1.29.0页面。我使用MariaDB作为数据库。我使用PHP 37年5月5日已取消Mediawiki登录以防止会话劫持

每次我尝试登录到一个帐户，我得到的错误：

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.

很显然，我正在寻找的行为是登录

。

我已经试过：

改变$wgMainCacheType和$wgSessionCacheType到的各种排列CACHE_NONE，CACHE_ACCEL，CACHE_DB和CACHE_ANYTHING。
creating a tmp directory并设置其权限。
重建我的LocalSettings.php文件。
在php.ini

我检查了，我知道我启用了Cookie设置session.referer_check=off（我能叫document.cookie;和找回数据）。

此问题已在here之前询问，并且链接的问题在内，但没有解决方案解决了我的问题。他们还处理较旧版本的WikiMedia，但我不知道在这种情况下是否会产生影响。

编辑：我也尝试创建一个新帐户时得到相同的行为。但是，我可以在没有任何错误的情况下浏览wiki，创建页面和编辑页面。

这里是我的请求头：

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

这里是我的响应头：

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

来源

2017-08-08 Lord Farquaad

你能提供的'authentication'，'login'，'session'，'缓存的输出'和'objectcache' [日志频道]（https://www.mediawiki.org/wiki/Manual:$wgDebugLogGroups）以及尝试登录时的HTTP请求和响应标头？ – Tgr

这是您提交登录表单的请求吗？如果是这样，它缺少登录cookie。因此，MediaWiki没有设置它（出于某种原因，请检查上一个请求中的Set-Cookie头，最初显示登录页面的位置），或者由于某种原因，浏览器不保留它（[T151770]（https ：//phabricator.wikimedia.org/T151770）是Firefox的一个已知问题，可能导致这种情况）。 – Tgr

呃，对不起，我的意思是在登录页面显示给你的响应中检查“Set-Cookie”。所以它应该看起来像这样：'GET Special：UserLogin' - >'HTTP 200 Set-Cookie：SomeWiki_session：xxxxx' - >'POST Special：UserLogin Cookie：SomeWiki_session：xxxxx' - > HTTP 302 Set-Cookie ：SomeWiki_user：xxx位置：Main_Page' – Tgr

我终于找到了我的问题的问题。默认情况下，MediaWiki通过安全标志设置的<wikiname>_session cookie。从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.

所以我链接到MediaWiki安装正确创建和缓存会话令牌，它甚至还通过响应报头经过。但是，由于我的浏览器看到的是http而不是https，这就像令牌一样。 Set-Cookie行简单地被忽略。

在php.ini中有一个名为session.cookie_secure的设置，但MediaWiki忽略此标志。

相反，解决方案是这一行添加到我的localSettings.php文件的底部：

$wgCookieSecure = false;

来源

2017-08-24 13:07:55

我有类似的事情发生在不同的应用中，当SessionID的正在更新失序。

因此，通常您会请求一个登录表单，并使用sessionId创建一个会话，并将其存储在某个地方。

然后，您提交表单，将它绑定到原始sessionId中，检查您的身份验证，然后登录原始会话或创建一个新会话，并更新您的身份（通常使用您可以看到的HTTP Set-Cookie命令在网络日志中）。

但是，您可以通过查看当前Cookie中的sessionId和表单上的任何标记（以防止重放）并根据/ tmp/php-session-xxx文件（可能在/ var/lib/php）或其他存储会话的数据库。

什么使我了解到我的问题是在我准备提交表单时，使用特定的sessionid，sessionid，是不再有效。因此我没有通过重播检查，并且发现类似于您的错误。事实证明，在我的情况下，这是因为复制数据库的方式与下游访问方式不匹配，所以我可以尝试访问尚未创建的会话。

查看所有代码，sessionIds不匹配。 wpTokenLogin以510a85开头，但你的wiki会话在SetCookie开始于n7gs0c，并在你的日志中谈到6ov933 ...因此，假设你从不同的尝试中复制/粘贴，你需要从一个干净的状态中自己运行并检查一切就像它使用同一个会话一样。如果没有，试着找出你的会话发生了什么（如果它已被创建/更改），或者为什么你没有得到正确的，如果它被创建，但从来没有正确传递给你。

这么说，我只是把在看看登录到我们自己的MediaWiki版本的点播服务的客户端，并wpLoginToken，wikidb_session和JSESSIONID不匹配或者（虽然我希望他们中的一个，显示了维基日志，我也无法访问）。

如果必须，请查找您找到的错误消息的来源，然后插入error_log(__FILE__.':'.__LINE__.' '.var_export(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS), true));以找出工作备份堆栈，查看不匹配的内容以生成错误。

来源

2017-08-17 12:23:28 sibaz

已取消Mediawiki登录以防止会话劫持

回答

相关问题