Chciałbym załatać sklep Magento za pomocą SUPEE-9767. Dokumentacja SUPEE-9767 mówi mi, aby wyłączyć Symlinks ustawienie przed nałożeniem plastra:
Przed zastosowaniem poprawki lub aktualizacji do najnowszej wersji należy wyłączyć ustawienie Symlinks ... Ustawienie, jeśli jest włączone, zastąpi ustawienie pliku konfiguracyjnego, a jego zmiana wymagać będzie bezpośredniej modyfikacji bazy danych.
Ale używam modmana do zarządzania modułami, a ponieważ niektóre moduły używają plików szablonów, ustawienie Symlinks jest włączone zgodnie z sugestią README modmana. Czy pozostawienie włączonej opcji Symlinks jest bezpieczne jako jeden z postów w poprawce bezpieczeństwa SUPEE-9767 - Możliwe problemy? sugeruje (nie mogę jeszcze komentować postów, ponieważ jestem nowym użytkownikiem)?
Użytkownicy używający modmana do zarządzania modułami Magento 1.x powinni upewnić się, że nie wyłączają dowiązań symbolicznych, ponieważ spowoduje to wyłączenie modułów modmana.
Jeśli pozostawię włączone ustawienie Symlinks, czy sklep nie będzie narażony na APPSEC-1281: Zdalne wykonanie kodu za pomocą dowiązań symbolicznych , zagrożenie bezpieczeństwa, które łatka ma naprawić?
Czy istnieją inne sposoby używania modmana z plikami szablonów po tej łatce? (Znam opcję „poprawionej wersji Mage / Core / Block / Template.php”, o której wspomina README modmana, ale łatanie pliku rdzenia wydaje się niebezpieczne.)
źródło
Odpowiedzi:
Oto kilka wyjaśnień dotyczących tej zmiany:
Najpierw przeczytaj to wyjaśnienie od Petera O'Callaghana, aby uzyskać doskonałe zrozumienie: https://peterocallaghan.co.uk/2017/06/appsec-1281-dangerous-symlinks/
Kolejną interesującą lekturą jest ten post Maxa Chadwicka https://maxchadwick.xyz/blog/what-allow-symlinks-actally-does
Ta modyfikacja naprawdę polega na wywołaniu treści do przesłania (takich jak obrazy) za pomocą dyrektyw szablonów.
Problem związany z dowiązaniami symbolicznymi można wykorzystać tylko w przypadku dostępu administratora, a Magento dodał także trochę więcej ochrony przed przesyłaniem obrazów.
Pamiętaj, że oprócz samego ustawienia są to niektóre zabezpieczenia przed znanym sposobem wykorzystania.
Jeśli więc rozumiesz związane z tym ryzyko, możesz pozostawić włączone dowiązania symboliczne.
Jeśli chcesz włączyć je dla nowej instalacji, możesz uruchomić:
źródło
Problemem nie są dowiązania symboliczne, problemem są ścieżki, które osiągają wyższe poziomy, takie jak
../../../../../media/tmp/hahaha.png
. Jeśli się mylę, proszę, oświeć mnie. Poprawka została zatytułowana „Zezwalaj na dowiązania symboliczne”, a włączenie tej opcji wyłącza sprawdzanie, które zostało zaimplementowanerealpath()
. Moim zdaniem poprawką, która jest równie bezpieczna, wydajniejsza i nadal kompatybilna z dowiązaniami symbolicznymi jest użyciestrpos($path, '..')
i / lub sprawdzenie, czyrealpath()
pasuje do niektórych ryzykownych katalogów, takich jakmedia
ivar
. Jeśli zostanie zaimplementowany w ten sposób, nie musi być konfigurowalny, może po prostu zawsze być włączony i nadal nie powodować awarii tysięcy sklepów.Niezależnie od tego użytkownik serwera WWW nie powinien mieć dostępu do zapisu plików w katalogach kodów źródłowych (tak jak robi to Magento Connect ...), dzięki czemu jest to kolejny sposób na uniknięcie gdzieś złośliwego kodu i wykonanie go jako szablonu bloku.
Tak więc ten atak na dowiązania symboliczne jest po prostu źle skierowany i istnieje lepsza poprawka. W rzeczywistości, pod warunkiem, jeden ponad rok temu i nie jest nawet link do niego w modman github README.
źródło
Jeśli w dodatku do pliku kompozytora ustawisz magento-deploystrategy na kopiowanie, twoje pliki zostaną skopiowane z folderu dostawcy, a nie z Symlinks.
Następnie możesz zmodyfikować dane core_config_data, aby ustawić wartość dev / template / allow_symlink na 0
Zasób do informacji
źródło
Możesz zastąpić zmiany SUPEE-9767 na różne sposoby, patrz:
Jak włączyć dowiązania symboliczne po instalacji SUPEE-9767 V2?
źródło