Anulowano logowanie w Mediawiki, aby zapobiec przechwytywaniu sesji

Question

Właśnie utworzyłem stronę MediaWiki 1.29.0 na komputerze AS400 IBM i. Używam MariaDB jako bazy danych. Używam PHP 5.5.37

każdym razem, gdy próbuję się zalogować do konta, pojawia się błąd:

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.

Oczywiście, zachowanie szukam jest, aby zalogować się

.

próbowałem:

• zmieniając $wgMainCacheType i $wgSessionCacheType różnych permutacji CACHE_NONE, CACHE_ACCEL, CACHE_DB i CACHE_ANYTHING.
• creating a tmp directory i ustawienie jego uprawnień.
• odbudowywanie pliku LocalSettings.php.
• ustawienie session.referer_check=off w php.ini

Sprawdziłem i wiem, że moje pliki cookie są włączone (Jestem w stanie wywołać document.cookie; i uzyskać dane z powrotem).

To pytanie zostało zadane przed here, a powiązane pytania w ramach, ale żadne rozwiązania nie rozwiązały mojego problemu. Zajmują się również starszą wersją WikiMedia, choć nie wiem, czy to ma znaczenie w tym przypadku.

EDYCJA: Zachowuję się tak samo, gdy próbuję utworzyć nowe konto. Jednak jestem w stanie poruszać się po wiki, tworzyć strony i edytować strony bez żadnego błędu.

Oto moja prośba nagłówek:

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 

Oto mój nagłówek odpowiedź:

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

W końcu znalazłem problem z moim problemem. Domyślnie MediaWiki przekazuje plik cookie <wikiname>_session za pomocą bezpiecznego zestawu flag. Zrobione z 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.

Więc moja instalacja MediaWiki poprawnie tworzy i buforuje token sesji, a nawet nadal przekazuje ją poprzez nagłówku odpowiedzi. Ponieważ jednak przeglądarka widzi http zamiast https, to tak daleko, jak token dostaje. Linia Set-Cookie jest po prostu ignorowana.

W php.ini znajduje się ustawienie o nazwie session.cookie_secure, ale MediaWiki ignoruje tę flagę.

Zamiast rozwiązaniem było dodać tę linię do głębi localSettings.php pliku:

$wgCookieSecure = false;

Answer 2

miałem coś podobnego zdarzyć się w innej aplikacji, gdy sessionId był aktualizowany poza kolejnością.

Zwykle żądasz formularza logowania i tworzy on sesję z identyfikatorem sesji i zapisuje go gdzieś.

Następnie przesłać formularz, wiąże go z oryginalnym identyfikatorem sesji, sprawdza uwierzytelnienie i loguje się w oryginalnej sesji lub tworzy nowy i aktualizuje swój (zwykle za pomocą polecenia HTTP Set-Cookie, które można zobaczyć w dzienniku sieci).

Ale możesz śledzić wszystko, patrząc na sessionId w bieżących ciasteczkach i dowolny token w formularzu (aby zapobiec powtórkom) i sprawdzając go z plikiem/tmp/php-session-xxx (może w/var/lib/php) lub jakakolwiek baza danych, w której jest przechowywana sesja.

To, co naprowadziło mnie na mój problem, to stwierdzenie, że do momentu, w którym miałem przesłać formularz, z konkretną sesją, ta sesja była Nie jest już aktualny. W związku z tym nie udało mi się sprawdzić powtórki i dostałem błąd podobny do twojego. Okazało się, że w moim przypadku miało to miejsce w przypadku replikowania baz danych w sposób, który nie pasował do tego, w jaki sposób uzyskiwano do nich dostęp, więc mogłem spróbować uzyskać dostęp do sesji, która nie została jeszcze utworzona.

Patrząc na cały twój kod, identyfikatory sesji nie pasują do siebie. wpTokenLogin zaczyna się od 510a85, ale twoja sesja wiki w SetCookie zaczyna się od n7gs0c, aw twoim logu mówi o 6ov933 ... Zakładając, że skopiowałeś/wkleiłeś z różnych prób, musisz przejść przez to sam z czystego stanu i sprawdzić, czy wszystko wygląda tak jak przy użyciu tej samej sesji. Jeśli nie, spróbuj dowiedzieć się, co dzieje się z Twoją sesją (jeśli została ona utworzona/zmieniona) lub dlaczego nie otrzymujesz właściwej, jeśli została utworzona, ale nigdy nie przekazała ci prawidłowo.

Powiedział, że po prostu wziął w spojrzeniu na stronie klienta zalogowaniu do własnej wersji życzenie z MediaWiki, a wpLoginToken, wikidb_session i JSESSIONID nie pasują albo (chociaż będę oczekiwać jednego z nich, aby pokazać się w dziennik wiki, do którego też nie mam dostępu).

Jeśli musisz, przejdź do źródła dla znalezionego komunikatu o błędzie i wstaw error_log(__FILE__.':'.__LINE__.' '.var_export(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS), true));, aby znaleźć kopię zapasową stosu, aby zobaczyć, co nie pasuje, aby wygenerować błąd.