Po tygodniach oczekiwania na aktualizację dzisiaj (27.10.2015) została wydana: SUPEE-6788
Wiele rzeczy zostało załatanych, a także zachęca się do przeglądu zainstalowanych modułów pod kątem możliwych luk.
Otwieram ten post, aby uzyskać wgląd w to, jak zastosować łatkę. Jakie są kroki, aby zastosować łatkę? W moim rozumieniu są to następujące kroki:
- Napraw moduły za pomocą funkcji administratora, które nie znajdują się pod administracyjnym adresem URL
- Napraw moduły, które używają instrukcji SQL jako nazw pól lub pól zmiany znaczenia
- Bloki białej listy lub dyrektywy korzystające ze zmiennych takich jak
{{config path=”web/unsecure/base_url”}}
i{{bloc type=rss/order_new}}
- Rozwiązanie problemu potencjalnego wykorzystania dzięki niestandardowemu typowi pliku opcji (nie mam pojęcia, jak to zrobić)
- Zastosuj łatkę
Czy to jest poprawna procedura?
admin
security
patches
supee-6788
lloiacono
źródło
źródło
.htaccess.sample
, jak również.htaccess
. Ten ostatni jest dostosowany w większości sklepów, spowoduje to, że łatka się nie powiedzie => Musisz tymczasowo zastąpić go oryginalnym plikiem z Magento, zastosować łatkę, przywrócić własny .htaccess i zastosować zmianę, która chroni dostęp docron.php
ręcznie (nie t oczywiście użyć systemu produkcyjnego!)Odpowiedzi:
Ogólnie rzecz biorąc, możesz zastosować łatkę tak jak wszystkie poprzednie. Przejrzyj oficjalną dokumentację i sprawdź ten post SE . Ale tak, jest kilka dodatkowych punktów, które powinieneś sprawdzić, stosując tę łatkę. Byte / Hypernode ma fajny post na ten temat.
template/customer/form/register.phtml
lub niestandardowytemplate/persistent/customer/form/register.phtml
. W takim przypadku upewnij się, że zawiera onform_key
.layout/customer.xml
. W takim przypadku upewnij się, że wprowadziłeś niezbędne zmiany z łatki (customer_account_resetpassword
została zmieniona nacustomer_account_changeforgotten
).cron.php
HTTP? Upewnij się, że lepiej użyćcron.sh
. Jeśli nie jest to możliwe, przynajmniej upewnij się, że wywołujesz cron.php przez CLI PHP. Jeśli z jakiegoś powodu nie możesz skonfigurować prawdziwego kronika i musisz go uruchomić przez HTTP, zobacz to pytanie SEPodczas aktualizacji upewnij się, że plik został usunięty
dev/tests/functional/.htaccess
. Nie jest już obecny w Magento 1.9.2.2. Utrzymanie go oznacza, że nadal jesteś podatny na zagrożenia.W każdym razie po aktualizacji sprawdź swoją stronę w MageReport, aby sprawdzić, czy wszystko poszło dobrze.
Jest też post na blogu technicznym autorstwa Piotra , który opisuje najważniejsze zmiany.
źródło
Istnieje plik kontrolny, który pomaga zidentyfikować problemy: https://github.com/gaiterjones/magento-appsec-file-check
Zrobiłem z niego skrypt CLI. https://github.com/Schrank/magento-appsec-file-check
źródło
W przypadku Nginx upewnij się, że zablokowałeś dostęp do cron.php i folderu dev. Używamy tego bloku:
źródło
Właśnie zastosowałem łatkę na moim 1.10.1 EE, co powoduje skutki uboczne na ekranach natywnych, ponieważ rdzeń nie jest zgodny z APPSEC-1063:
Przykład:
W
app/code/core/Mage/Customer/Model/Entity/Attribute/Collection.php
Można znaleźć 2
addFieldToFilter
połączenia niezgodne z APPSEC-1063.Łamie to Klienta> Siatki atrybutów, więc musisz łatać łatkę, korzystając ze sztuczki zalecanej w pdf „SUPEE-6788-Technical% 20Details% 20.pdf” w sekcji APPSEC-1063
Zmieniam kilka
(gdzie pole $ zawiera złożone (PRZYPADEK ... GDY NASTĘPNIE ...) instrukcje sql)
w
Zarówno supee-6788-zestaw narzędzi rhoerr, jak i gaiterjones 'nie wykryły tego rodzaju problemów, sprawdziłem wszystkie pozostałe -> addFieldToFilter ($ i wydaje się, że żaden nie powoduje problemu.
Inne uszkodzone pliki podstawowe 1.10: (znalezione przez supee-6788-toolbox rhoerr)
Może być więcej.
źródło