Co zrobić po aktualizacji zabezpieczeń TYPO3 od 13.09.2016?

Question

Nie rozumiem poprawki zabezpieczeń z zeszłego tygodnia: https://typo3.org/teams/security/security-bulletins/typo3-core/typo3-core-sa-2016-022/. Mam starą instalację TYPO3 6.2. Obetnąłem wszystkie tabele cf_ * i otworzyłem strony z UID 2-6. Bez cHash. W rezultacie widzę 13 wpisów cf_cache_hash. Teraz otworzyłem stronę szczegółów ze strony z listą w interfejsie. Widzę niektóre parametry w adresie, takie jak akcja, kontroler, UID bieżącego wyświetlanego rekordu i powodują cHash. Następnie skopiowałem te parametry (z wyjątkiem id = x) do adresu URL moich stron 2-6. W cf_cache_hash mam wciąż 13 rekordów. Tak więc nie ma powodzi w pamięci podręcznej.

Albo jak mam zinterpretować ten cytat:

Powiązania z ważnego argumentu chash prowadzą do nowo wygenerowanej strony buforuje wpisy. Ponieważ cHash nie jest związany z określoną stroną, intruz może użyć prawidłowych argumentów cHash dla wielu stron, prowadząc do dodatkowych niepotrzebnych wpisów pamięci podręcznej stron.

Kolejny problem:

Jeśli używane są rozszerzenia takie jak realurl, wymagane jest, aby opróżnić swoje pamięci podręcznej (a TYPO3 buforuje również)

Czy możesz mi powiedzieć, które tabele Ja/powinniśmy wyczyścić?

• tx_realurl_urldecodecache
• tx_realurl_urlencodecache

może są OK. Ale co z tx_realurl_pathcache? Mogę to wyjaśnić, ale co ze starszymi wpisami do wcześniejszej konfiguracji realurl? Jeśli obetnę tę tabelę, te stare wpisy nie będą już ważne i nie zostaną ponownie utworzone. Dlatego stare wyniki wyszukiwarek są nieprawidłowe.

Pytanie jednego z naszych klientów: Czy wystarczy wyczyścić pamięć podręczną systemu w backendie, czy kliknąć opcję Wyczyść całą pamięć podręczną w Installtool? Miły. IMO, to nie wystarczy i tabele muszą zostać obcięte bezpośrednio na DB. Dobrze.

następny:

Oznacza to, że jeśli te adresy są indeksowane przez wyszukiwarki, goście z Ta wyszukiwarka nie skończy się na stronie nie pracuje prawidłowo.

Hej super. I teraz? Jakie jest rozwiązanie? Zachowaj to takim, jakie jest? IMO zależy od ustawienia InstallTool o nazwie: pageNotFoundOnCHashError. Dobrze?

Poinformuj nas, co masz robić, i dodaj więcej szczegółów, jak sobie z tym poradzić.

Stefan

Answer 1

Dla mnie to sprowadza się do (po zainstalowaniu zaktualizowanej wersji TYPO3):

Jeśli nie używać realurl: enable

$GLOBALS['TYPO3_CONF_VARS']['FE']['cHashIncludePageId'] = true; 

& i jesteś prawdopodobnie " Gotowe". Oczywiście wszystkie stare hity Google zostaną wykonane, ale na "publicznej" stronie jest całkiem prawdopodobne, że nigdy nie dbałeś o Google'a, jeśli nie uruchomiłeś realurl (lub podobnego)

Jeśli używasz Realurl 1.X na 6,2

nie pozwalają config (tam prawdopodobnie nigdy nie będzie odpowiednia łata)

dwie opcje:

1. podjąć ryzyko DDoS
2. użyć 1.x wersja od https://github.com/mogic-le/typo3-realurl Jeśli zrozumiem to poprawnie, ustawi TYPO3 na tryb no_cache, jeśli nie ma żadnego trafienia na tabeli buforowania; Mimo, że jest to problem z wydajnością, to zapobiec wpisy tabeli cache są wykonane (jako skutek uboczny)

Jeśli prowadzisz 7.6+ i realurl 2

1. Poczekaj na realurl 2.1 (i podjąć ryzyko ?)
2. Zmiana buforowanie ramy do czegoś podobnego memcached (to nieco zasugerował między wierszami: Jeśli masz backend buforowania, które nie mogą być używane na DDOS, naprawdę nie musisz się martwić)
3. Użyj f racy z helhum (choć myślę, że nie pomoże Ci jeden bit dotyczące starych linków)

Answer 2

Realurl> = 2.1.0 obsługuje tej funkcji rdzenia. Ale zaleca się aktualizację do wersji co najmniej 2.1.4, ponieważ rozwiązuje ona różne inne problemy związane z cHash.