Poprawka bezpieczeństwa SUPEE-10570 - Możliwe problemy?


45

Magento wydało nową łatkę bezpieczeństwa dla M1 oraz aktualizacje dla M1 i M2.

Na jakie problemy należy zwrócić uwagę podczas aktualizacji lub stosowania tej poprawki?

SUPEE-10570

SUPEE-10570, Magento Commerce 1.14.3.8 i Open Source 1.9.3.8 zawierają wiele ulepszeń bezpieczeństwa, które pomagają zamknąć zdalne wykonanie kodu (RCE), skrypty między witrynami (XSS i inne). Te wydania zawierają również małe poprawki funkcjonalne wymienione w Informacje o wydaniu.

AKTUALIZACJA BEZPIECZEŃSTWA MAGENTO 2.2.3, 2.1.12 I 2.0.18

Magento Commerce i Open Source 2.2.3, 2.1.12 i 2.0.18 zawierają wiele ulepszeń bezpieczeństwa, które pomagają zamykać skrypty krzyżowe (XSS), uwierzytelniać zdalne wykonywanie uwierzytelnionego administratora (RCE) i inne podatności. Wydania zawierają dodatkowe poprawki funkcjonalne. Aby dowiedzieć się więcej o poprawkach funkcjonalnych, sprawdź Informacje o wersji dla Magento Commerce 2.0.18, 2.1.12, 2.2.3 i Magento Open Source 2.0.18, 2.1.12, 2.2.3.


1
Wydaje się, że w Open Source / Community Edition 1.x nie są uwzględniane żadne zmiany szablonu interfejsu użytkownika , więc przynajmniej nie powinno to powodować zbyt wielu problemów. Jednak zdecydowanie zaleca się wykonanie kopii zapasowej bazy danych, ponieważ w tej łatce znajdują się dwa skrypty instalacyjne (uaktualniające). Więcej szczegółów może nastąpić po załataniu pierwszych środowisk.
— Christoph Farnleitner

1
Jeśli masz sklepy korzystające ze spersonalizowanej siatki adminhtml, która zawiera nazwę sklepu, łatka teraz prawdopodobnie ucieka od niej, aby naprawić niektóre potencjalne exploity na podstawie zmiany nazwy sklepu i renderowania.
— Andrew Quackenbos

Do tej pory załatałem bez problemu 2 witryny w wersji 1.9.0.1.
— asdfasdfasf

1
Na razie zastosowałem łatkę w wersji 1.9.3.0, 1.9.0.1 i 1.9.1.0 - żadnych problemów
— David

2
Pochodzi z bloga poświęconego bezpieczeństwu: magento.com/security/patches/supee-10570 UWAGA: Niektórzy klienci mają problem z kasą podczas próby utworzenia konta podczas kasy. Wkrótce będzie dostępna aktualizacja lub obejście tego problemu. Jeśli obecnie występuje ten problem, rozważ cofnięcie części kodu powodującej ten problem, stosując następującą łatkę: invalid_sesssion_fix.patch z Archiwum wydań, sekcja SUPEE-10570
— The Tankgirl

Odpowiedzi:


29

Oto lista zmodyfikowanych plików według poprawki SUPEE-10570:

app/Mage.php 
app/code/core/Mage/Admin/Helper/Data.php
app/code/core/Mage/Admin/Model/Block.php 
app/code/core/Mage/Admin/Model/Resource/Block.php 
app/code/core/Mage/Admin/Model/User.php 
app/code/core/Mage/Adminhtml/Block/Catalog/Category/Edit/Form.php 
app/code/core/Mage/Adminhtml/Block/Catalog/Product/Grid.php 
app/code/core/Mage/Adminhtml/Block/Newsletter/Template/Grid/Renderer/Sender.php 
app/code/core/Mage/Adminhtml/Block/Sales/Order/Grid.php 
app/code/core/Mage/Adminhtml/Block/Sales/Order/View/Info.php 
app/code/core/Mage/Adminhtml/Block/System/Store/Edit/Form.php 
app/code/core/Mage/Adminhtml/Block/Tag/Assigned/Grid.php 
app/code/core/Mage/Adminhtml/Block/Widget/Grid/Column/Renderer/Store.php 
app/code/core/Mage/Adminhtml/Block/Widget/Tabs.php 
app/code/core/Mage/Adminhtml/Model/Config/Data.php 
app/code/core/Mage/Adminhtml/Model/System/Store.php 
app/code/core/Mage/Adminhtml/controllers/Catalog/ProductController.php 
app/code/core/Mage/Adminhtml/controllers/CustomerController.php 
app/code/core/Mage/Adminhtml/controllers/System/BackupController.php
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php
app/code/core/Mage/Core/Model/Variable.php
app/code/core/Mage/Customer/Helper/Data.php
app/code/core/Mage/Customer/Model/Resource/Customer.php
app/code/core/Mage/Customer/controllers/AccountController.php
app/code/core/Mage/Customer/etc/config.xml
app/code/core/Mage/Customer/sql/customer_setup/upgrade-1.6.2.0.1.1.1-1.6.2.0.1.1.2.php
app/code/core/Mage/Downloadable/etc/config.xml
app/code/core/Mage/Downloadable/etc/system.xml
app/code/core/Mage/Downloadable/sql/downloadable_setup/upgrade-1.6.0.0.2.1.1-1.6.0.0.2.1.2.php
app/code/core/Mage/ImportExport/Model/Import.php
app/code/core/Mage/ImportExport/Model/Import/Entity/Product.php
app/code/core/Mage/Shipping/Model/Info.php
app/code/core/Mage/Widget/controllers/Adminhtml/Widget/InstanceController.php
app/design/adminhtml/default/default/template/catalog/product/attribute/set/main.phtml
app/design/adminhtml/default/default/template/customer/tab/view.phtml
app/design/adminhtml/default/default/template/customer/tab/view/sales.phtml
app/design/adminhtml/default/default/template/dashboard/store/switcher.phtml
app/design/adminhtml/default/default/template/downloadable/product/composite/fieldset/downloadable.phtml
app/design/adminhtml/default/default/template/downloadable/product/edit/downloadable/links.phtml
app/design/adminhtml/default/default/template/downloadable/sales/items/column/downloadable/creditmemo/name.phtml
app/design/adminhtml/default/default/template/downloadable/sales/items/column/downloadable/invoice/name.phtml
app/design/adminhtml/default/default/template/downloadable/sales/items/column/downloadable/name.phtml
app/design/adminhtml/default/default/template/newsletter/preview/store.phtml
app/design/adminhtml/default/default/template/report/store/switcher.phtml
app/design/adminhtml/default/default/template/sales/order/view/info.phtml
app/design/adminhtml/default/default/template/store/switcher.phtml
app/design/adminhtml/default/default/template/store/switcher/enhanced.phtml
app/design/adminhtml/default/default/template/system/convert/profile/wizard.phtml
app/design/adminhtml/default/default/template/tax/rate/title.phtml
app/design/adminhtml/default/default/template/widget/form/renderer/fieldset.phtml
app/locale/en_US/Mage_Catalog.csv
app/locale/en_US/Mage_ImportExport.csv
lib/Zend/Mail/Transport/Sendmail.php

EDYTOWAĆ

Wreszcie po wdrożeniu na mojej stronie produktu (CE 1.7.0.2) zauważyłem krytyczny problem z blokowaniem (proces kasy zablokowany).

Kontekst: po adresie kroku 1 bezpośrednio tworzę ORAZ loguję klienta, powinien zobaczyć tylko następny krok kasy.

Problem: po supee-10570 proces kasowania jest przerywany po kroku 1 (w przypadku utworzenia konta), a klient zostaje przekierowany na stronę główną (z pustym koszykiem + wylogowanym) = niemożliwe do zrealizowania kasy.

Awaryjna poprawka: jeśli napotkasz podobny problem z kasą / sesją klienta, skomentuj linie 414-430 z app / code / core / Mage / Core / Model / Session / Abstract / Varien.php (te dodane przez łatkę patrz poniżej).

//         if ($this->useValidateSessionPasswordTimestamp()
//             && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
//             && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
//             && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
//             > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
//         ) {
//             return false;
//         }

//         if ($this->useValidateSessionExpire()
//             && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
//             && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) {
//             return false;
//         } else {
//             $this->_data[self::VALIDATOR_KEY][self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP]
//                 = $validatorData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP];
//         }

EDYCJA (2)

Myślę, że następujący warunek zawsze zwróci false (Mage_Core_Model_Session_Abstract_Varien w liniach 414-419, szczególnie linie 417 + 418).

if ($this->useValidateSessionPasswordTimestamp()
            && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
            && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
            && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
            > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
        ) {
        return false;

VALIDATOR_PASSWORD_CREATE_TIMESTAMP będzie zawsze większy niż VALIDATOR_SESSION_EXPIRE_TIMESTAMP. Znacznik czasu „wygasania” sesji jest redefiniowany przy tworzeniu konta, więc nieuchronnie jest starszy niż init sesji.

Na przykład, jeśli utworzysz klienta podczas kasy, to zwróci fałsz, a klient zostanie po prostu wyrzucony (= zakończenie kasy, przekierowanie do strony głównej i pusty koszyk). Dość źle.

Zgłosiłem ten problem zespołowi magento. Dam jak najszybciej informację zwrotną.


EDYCJA (3)

Nowa łatka jest wip (na stronie pobierania łatki magento jest napisane „SUPEE-10570 dla CE 1.7.0.0 - OCZEKIWANIE NA ZAKTUALIZOWANĄ ŁATKĘ, NIE UŻYWAJ (0,06 MB)”).


EDYCJA (4) ~ 1 miesiąc po zgłoszeniu pierwszego problemu z blokowaniem

Cześć! Mam nadzieję, że wszyscy jesteście dobrami (i mam nadzieję, że do tej pory nie zachowaliście stanu początkowej łatki, chyba że dochody z firmy prawdopodobnie poważnie spadły ^^).

Zauważyłem następujące zdanie z oficjalnej strony: „Magento udostępnia teraz zaktualizowaną łatkę (SUPEE-10570v2), która nie powoduje już tego problemu. Pamiętaj jednak, że ta nowa łatka nie chroni już przed dwoma sesjami związanymi z obsługą sesji o niskim ryzyku problemy z bezpieczeństwem, które chronią przed SUPEE-10570. ” z oficjalnej strony supee-10570.

Na stronie wydania możemy wreszcie znaleźć plik v2 (PATCH_SUPEE-10570_CE_v1.7.0.2_v2-2018-03-29-08-52-37.sh).

Szczegółowo zbadałem modyfikacje. Wreszcie wydaje się, że zespół magento postanowił porzucić część bezpieczeństwa dotyczącą łatki. Mam nadzieję, że ta dziura w zabezpieczeniach nie spowoduje poważnych szkód (zgodnie z oficjalną notatką, jest mało krytyczna).

Po przywróceniu v1 + zastosuj v2, pamiętaj, że następujące pliki są przywracane do stanu początkowego (przed zastosowaniem v1):

app/code/core/Mage/Adminhtml/controllers/CustomerController.php
app/code/core/Mage/Customer/controllers/AccountController.php
app/code/core/Mage/Customer/Helper/Data.php
app/code/core/Mage/Customer/Model/Resource/Customer.php

PS: oczywiście niektóre inne pliki również są modyfikowane, sprawdź to odpowiednio.


1
@Icon: Właśnie zgłosiłem ten błąd do Magento. Opublikuję odpowiedź, gdy tylko otrzymam oficjalną informację zwrotną.
— DarkCowboy

4
@Icon / Soleil: Niestety nadal nie ma oficjalnej odpowiedzi ani poprawki dotyczącej mojej prośby o poprawienie błędu.
— DarkCowboy,

1
@DarkCowboy Właśnie zauważyłem, że po przejściu na stronę pobierania łatek zespół Magento dodał notatkę w łatce 1.7.0.0 i 1.7.0.2. Wygląda na to, że nadchodzi nowa łatka.
— Ikona

3
Cześć wszystkim. Widziałem, że dodano nową łatkę („PATCH_SUPEE-10570_CE_v1.7.0.2_v1-2018-02-28-04-54-53.sh”). Różnicę możesz zobaczyć tutaj (lewy panel to 1. łatka „PATCH_SUPEE-10570_CE_v1.7.0.2_v1-2018-02-23-06-28-18.sh”): diffchecker.com/uGON91aR . Więc nie ma poprawki w nowej łatce ?! Ponadto zniknął komunikat „... OCZEKIWANO ZAKTUALIZOWANĄ ŁATKĘ, NIE UŻYWAJ”. Trochę mylę więc, co robi zespół podstawowy Magento z tym problemem.
— DarkCowboy

1
Do Twojej wiadomości, wersja 2 łatki nadal wyświetla „SUPEE-10570_CE_v1.9.2.4 | CE_1.9.2.4 | v1” wapp/etc/applied.patches.list
— Łoś

9

(nie jestem pewien, czy było to w uwagach do wydania od samego początku)

Znane problemy

Te dwa znane problemy są związane z użyciem tagów HTML w atrybucie SKU produktu:

  • Jeśli spróbujesz zaimportować produkty zawierające tagi HTML w atrybucie SKU, Magento wyświetli ten błąd na etapie sprawdzania poprawności danych (to znaczy po kliknięciu Sprawdź dane ):
 Invalid value in SKU column. HTML tags are not allowed.
  • Jeśli spróbujesz utworzyć lub edytować produkt w panelu administracyjnym, a wartość atrybutu SKU produktu zawiera tagi HTML, Magento zgłasza ten błąd podczas próby zapisania produktu: HTML tags are not allowed in SKU attribute.

Z notatek o łatce :

Jeśli łatka nie zostanie zastosowana podczas łatania lib/Zend/Mail/Transport/Sendmail.php, może to oznaczać, że twoja instalacja Magento została wcześniej załatana SUPEE-9652v1 zamiast SUPEE-9652v2. Zalecanym rozwiązaniem jest przywrócenie poprawki SUPEE-9652v1 i zastosowanie SUPEE-9652v2 przed zastosowaniem SUPEE-10570.


7

Miałem ten sam problem, co @DarkCowboy po zastosowaniu poprawki do Magento CE 1.7.0.2.

Po wybraniu rejestracji jako nowy klient podczas realizacji transakcji, złożenie zamówienia powoduje utworzenie zarówno zamówienia, jak i klienta, ale zamiast wyświetlać stronę zamówienia, jestem przekierowywany na stronę główną i wylogowałem się.

Rozwiązaniem, które znalazłem, jest odwrócenie kolejności bloków kodu w zmianach do app/code/core/Mage/Core/Model/Session/Abstract/Varien.php.

Porównując łataną wersję z tym samym plikiem w Magento CE 1.9.3.8, znalazłem nowe bloki do sprawdzania ważności sesji i znacznik czasu hasła w innej kolejności.

Magento CE 1.9.3.8 - Linie 476-491:

    if ($this->useValidateSessionExpire()
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) {
        return false;
    } else {
        $this->_data[self::VALIDATOR_KEY][self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP]
            = $validatorData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP];
    }
    if ($this->useValidateSessionPasswordTimestamp()
        && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
        > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
    ) {
        return false;
    }

Magento CE 1.7.0.2 - Linie 414-430:

    if ($this->useValidateSessionPasswordTimestamp()
        && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
        > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
    ) {
        return false;
    }

    if ($this->useValidateSessionExpire()
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) {
        return false;
    } else {
        $this->_data[self::VALIDATOR_KEY][self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP]
            = $validatorData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP];
    }

Powoduje to, że wartość $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]jest większa niż $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime(), co oznacza, że ​​metoda zawsze zwraca false, a sprawdzanie poprawności kończy się niepowodzeniem.

Zmiana kodu w Magento CE 1.7.0.2 w celu dopasowania wersji w Magento CE 1.9.3.8 rozwiązuje problem.

Wynikowy kod dla Magento CE 1.7.0.2 - Linie 414-430:

​
    if ($this->useValidateSessionExpire()
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) {
        return false;
    } else {
        $this->_data[self::VALIDATOR_KEY][self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP]
            = $validatorData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP];
    }
    if ($this->useValidateSessionPasswordTimestamp()
        && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
        && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
        && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
        > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
    ) {
        return false;
    }

Sugerowałbym utworzenie własnego pliku łatki i zastosowanie bezpośrednio do pliku podstawowego (w ten sposób zwykle podchodzę do naprawiania błędów w rdzeniu). Ułatwi to przywrócenie, jeśli Magento wyda wersję 2 łatki.


Cześć dave. Wygląda na to, że napotkałeś ten sam problem niż ja. Jeśli chodzi o twoją poprawkę, przy inwersji drugi warunek w ogóle nie zostanie przetestowany ... Zbadam te dane sesji.
— DarkCowboy

4
Aktualizacja do wersji 1.7.0.2 oczekiwana w połowie marca. (v2 łatki), problem został potwierdzony.
— Piotr Kamiński

Czy ktoś sprawdził, czy to rozwiązanie faktycznie działa sprawdzanie znacznika czasu zmiany hasła, czy też ponownie otwiera lukę bezpieczeństwa, którą próbowali załatać? Uwaga: jeśli nie zależy Ci na korzyściach bezpieczeństwa, możesz po prostu wyłączyć sprawdzanie znaczników czasu zmiany hasła, useValidateSessionPasswordTimestamp()zwracając się false. (zmiana jednej linii w tym samym pliku)
— Eric Seastrand

Cześć. Oceniliśmy, że problem „przekierowania z pustym koszykiem” nadal występuje w przypadku zmienionej kolejności sprawdzania poprawności. Wyłączyliśmy sprawdzanie „useValidateSessionPasswordTimestamp” do momentu, aż magento utworzy aktualizację.
— Steven Fritzsche

6

Po zastosowaniu SUPEE-10570 i kompilacji zobaczyliśmy pustą stronę w / checkout / cart. Tylko dla wyjaśnienia: Z dezaktywowanym kompilatorem wszystko poszło dobrze, z aktywowanym kompilatorem widzieliśmy tylko pustą stronę koszyka po zalogowaniu bez żadnych wpisów w dzienniku (nawet po aktywowaniu wszystkich możliwych dzienników i trybu programisty).

Rozwiązaniem była zmiana funkcji getPasswordTimestamp()w app/code/core/Mage/Customer/Helper/Data.php(oczywiście oznacza app/code/local/Mage/Customer/Helper/Data.php:!) I użycie Mage::getSingleton('core/resource')zamiast Mage::getModel('customer/customer')lub Mage::getSingleton('customer/session'). Więc zamień całą funkcję np. Na następujące wiersze kodu:

    $resource = Mage::getSingleton('core/resource');
    $readConnection = $resource->getConnection('core_read');
    $query = 'SELECT * FROM ' . $resource->getTableName('customer_entity').' WHERE `entity_id` = '.$customerId;
    $results = $readConnection->fetchAll($query);
    $result=$results[0];
    $date_created = Varien_Date::toTimestamp($result['created_at']);
    return $date_created;

Po ponownej kompilacji problem zniknął. Ktoś jeszcze z tym problemem?

Wyjaśnienie w języku niemieckim tutaj .


Jest to na wiele różnych sposobów najgorsza rada i kod, jaki kiedykolwiek tu widziano. Proszę nie rób tego w domu.
— pong

Dokładnie tak samo ze mną. Ta poprawka nie działa z włączonym kompilatorem.
— Rafael Patro

W wersji 1.9.3.9 działa dla mnie dobrze.
— TonkBerlin

4

1.7.0.0

Łata: PATCH_SUPEE-10570_CE_v1.7.0.0_v1-2018-02-23-06-37-58.sh

Ten błąd występuje, jeśli wcześniej nie zastosowano SUPEE-9652 lub SUPEE-9767

patching file lib/Zend/Mail/Transport/Sendmail.php
Hunk #1 FAILED at 119.
Hunk #2 FAILED at 130.

Zastosuj te łatki, aby rozwiązać problem.


2
Upewnij się, że masz zainstalowane 9652 i 9767
— Ikona

Rzeczywiście testowaliśmy SUPEE-10570 na wszystkich wersjach waniliowych Magento od wersji 1.6.0.0 i wszystko działa. Ale tylko jeśli zastosujesz wszystkie poprzednie łaty. Tutaj możesz sprawdzić, które łatki są wymagane: docs.google.com/spreadsheets/d/…
— Jeroen Vermeulen - MageHost

4

1.7.0.0

PATCH_SUPEE-10570_CE_v1.7.0.0_v1-2018-02-23-06-37-58.sh Plik łatkiapp/code/core/Mage/Core/Model/Session/Abstract/Varien.php

Łatka dla wersji 1.7.0.0 dodaje tylko jedną stałą:

+    const VALIDATOR_PASSWORD_CREATE_TIMESTAMP   = 'password_create_timestamp';

Dodaje jednak użycie dwóch nowych stałych, zwłaszcza tej:

+        if ($this->useValidateSessionPasswordTimestamp()
+            && isset($validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP])
+            && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
+            && $validatorData[self::VALIDATOR_PASSWORD_CREATE_TIMESTAMP]
+            > $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] - $this->getCookie()->getLifetime()
+        ) {
+            return false;
+        }

Powoduje to błąd:

PHP Fatal error:  Uncaught Error: Undefined class constant 'VALIDATOR_SESSION_EXPIRE_TIMESTAMP' in 
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php:406
Stack trace:
#0 
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php(358): Mage_Core_Model_Session_Abstract_Varien->_validate()
#1 
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php(176): Mage_Core_Model_Session_Abstract_Varien->validate()
#2 
app/code/core/Mage/Core/Model/Session/Abstract.php(84): Mage_Core_Model_Session_Abstract_Varien->init('core', 'frontend')
#3 
app/code/core/Mage/Core/Model/Session.php(42): Mage_Core_Model_Session_Abstract->init('core', 'frontend')
#4 
app/code/core/Mage/Core/Model/Config.php(1354): Mage_Core_Model_Session->__construct(Array)

Poprawka:

Dodaj definicję tej drugiej stałej powyżej lub poniżej pierwszej stałej dodanej przez tę poprawkę.

const VALIDATOR_SESSION_EXPIRE_TIMESTAMP = 'session_expire_timestamp';

Do tej pory nie widziałem tego problemu w żadnym z 1.9. lub łatki 1.14.x, ponieważ poprawnie definiują stałą.


Zostało to załatane przez dodanie const VALIDATOR_SESSION_EXPIRE_TIMESTAMP = 'session_expire_timestamp';do górnej części pliku, podobnie jak w większości innych wersji tej poprawki.
— Tyler V.

Tak, wydaje się być specyficzny dla łatki
— 1.7.0.0

Tyler, czy możesz dodać poprawkę do swojej faktycznej odpowiedzi zamiast do sekcji komentarzy.
— danmentzer

1
Chciałbym również zauważyć, że wpływa to również na łatki dla wersji EE łatki, a także EE 1.12.0.0
— danmentzer

3

Najpierw sprawdź, czy wcześniej zastosowałeś poprawną wersję SUPEE-6788 lub SUPEE-7405, jeśli nie, przywróć niewłaściwą wersję, a następnie zastosuj poprawną wersję SUPEE-6788 / SUPEE-7405.

Następnie spróbuj ponownie zastosować SUPEE-10570.


2

Poniższe pliki są aktualizowane / dodawane po zastosowaniu poprawki SUPEE - 10570 w EE

@DarkCowboy dostarczył listę plików innych niż pliki EE :

    app/code/core/Enterprise/Cms/Block/Adminhtml/Cms/Hierarchy/Edit/Form.php
    app/code/core/Enterprise/Cms/Block/Adminhtml/Cms/Hierarchy/Widget/Chooser.php
    app/code/core/Enterprise/Cms/Block/Adminhtml/Cms/Page/Edit/Tab/Hierarchy.php
    app/code/core/Enterprise/Cms/Block/Hierarchy/Menu.php
    app/code/core/Enterprise/Customer/Block/Adminhtml/Customer/Attribute/Edit/Tab/Main.php
    app/code/core/Enterprise/GiftRegistry/Model/Observer.php
    app/code/core/Enterprise/Reward/Block/Adminhtml/Customer/Edit/Tab/Reward/Management/Update.php
    app/code/core/Enterprise/Rma/Model/Shipping/Info.php
    app/code/core/Enterprise/Staging/Block/Adminhtml/Backup/Grid.php
    app/code/core/Enterprise/Staging/Block/Adminhtml/Staging/Grid.php
 app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/edit.phtml
    app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/manage.phtml
    app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/scope/switcher.phtml
    app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/widget/radio.phtml
    app/design/adminhtml/default/default/template/enterprise/cms/page/preview/store.phtml
    app/design/adminhtml/default/default/template/enterprise/customer/website/switcher.phtml
    app/design/adminhtml/default/default/template/enterprise/invitation/view/tab/general.phtml
    app/design/adminhtml/default/default/template/enterprise/staging/log/information/create.phtml
    app/design/adminhtml/default/default/template/enterprise/staging/staging/edit/tabs/website.phtml
    app/design/adminhtml/default/default/template/enterprise/staging/staging/edit/tabs/website/store.phtml
    app/design/adminhtml/default/default/template/enterprise/staging/staging/merge/settings/website.phtml
    app/design/adminhtml/default/default/template/enterprise/store/switcher.phtml
    app/design/adminhtml/default/default/template/enterprise/store/switcher/enhanced.phtml
    app/design/adminhtml/default/default/template/merchandiser/new/page/html/top-buttons.phtml
    app/design/frontend/enterprise/default/template/cms/hierarchy/pagination.phtml

Kilka ważnych uwag

password_created_at utworzony w tabeli atrybutów klienta.

app/code/core/Mage/Adminhtml/controllers/CustomerController.php
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php
app/code/core/Mage/Customer/Helper/Data.php
app/code/core/Mage/Customer/Model/Resource/Customer.php
app/code/core/Mage/Customer/controllers/AccountController.php
app/code/core/Mage/Customer/sql/customer_setup/upgrade-1.6.2.0.5.1.1-1.6.2.0.5.1.2.php

Są to pliki używane do tworzenia i sprawdzania poprawności. problem z sesją występuje przy kasie lub kontroli logowania użytkownika, powyższe pliki są nadpisywane w lokalnej puli lub Dowolny password_created_atatrybut jest tworzony w tabeli atrybutów klienta, a odpowiednia wartość przechowywana w tej tabeli.


Nie mogłem znaleźć hasła_tworzonego_ hasła w bazie danych CE, w której podano również problem.
— TonkBerlin,

sprawdź ten plik app / code / core / Mage / Customer / sql / customer_setup / upgrade-1.6.2.0.5.1.1-1.6.2.0.5.1.2.php
— Rama Chandran M

2

Moja wersja Magento to ver. 1.9.1.0.

Po zastosowaniu SUPEE-10570 i kompilacji zobaczyliśmy pustą stronę w / checkout / cart. Tylko dla wyjaśnienia: Z dezaktywowanym kompilatorem wszystko poszło dobrze, z aktywowanym kompilatorem widzieliśmy tylko pustą stronę koszyka po zalogowaniu bez żadnych wpisów w dzienniku (nawet po aktywowaniu wszystkich możliwych dzienników i trybu programisty).

Przyczyna:

  1. funkcja getPasswordTimestamp wywoła się dwa razy po zalogowaniu i wejściu / kasie / koszyku.

  2. wyłączono kompilator zarówno prace wywołania.

  3. włącz kompilator tylko przy pierwszym wywołaniu, drugie wywołanie nie powiodło się.

czy ktoś może wyjaśnić i podać dobre rozwiązanie?


2

Problemy z 1.7.0.2 , które zauważyłem, są następujące:

  1. Dodaj produkt do koszyka i przejdź do kasy

  2. Kliknij „Zarejestruj się”

  3. Podaj wszystkie niezbędne informacje o zamówieniu, w tym szczegóły płatności itp.
  4. Kliknij opcję Zakończ zamówienie.

PROBLEM ROZPOCZYNA SIĘ TUTAJ

5. Automatycznie przekieruj do STRONY GŁÓWNEJ. Nie zobaczysz potwierdzenia numeru zamówienia. Ale w rzeczywistości zamówienie jest składane i tworzone jest konto klienta.


znalazłeś jakieś rozwiązanie? Mam do czynienia z tym samym problemem.
— Parth Thummar,

1
Wersja 2 łatki została wydana, problem rozwiązany
— Ikona

2

Spotkałem ten sam problem, Magento 1.9.3.8 dodał tę metodę do klasy Mage_Customer_Helper_Data

/**
 * Get customer password creation timestamp or customer account creation timestamp
 *
 * @param $customerId
 * @return int
 */
public function getPasswordTimestamp($customerId)
{
    /** @var $customer Mage_Customer_Model_Customer */
    $customer = Mage::getModel('customer/customer')
        ->setWebsiteId(Mage::app()->getStore()->getWebsiteId())
        ->load((int)$customerId);
    $passwordCreatedAt = $customer->getPasswordCreatedAt();

    return is_null($passwordCreatedAt) ? $customer->getCreatedAtTimestamp() : $passwordCreatedAt;
}

Jeśli przesłonisz tę klasę w folderze lokalnym (nie jest to najlepsza praktyka), możemy mieć błędy generowane przez tę klasę.


2

Ta poprawka zepsuła część menedżera hierarchii CMS dla użytkowników EE.

Wynika to z następującej linii łatki, która jest odpowiedzialna za ucieczkę od nazw sklepów / stron internetowych i naprawienie APPSEC-1873/1979/1980.

diff --git app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/manage.phtml app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/manage.phtml
index e45298c..8bee617 100644
--- app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/manage.phtml
+++ app/design/adminhtml/default/default/template/enterprise/cms/hierarchy/manage.phtml
@@ -36,7 +36,7 @@
             <div class="cms-popup-description"></div>
             <div class="fieldset">
                 <div class="cms-hierarchy manage-form">
-                    <?php echo $this->getFormHtml() ?>
+                    <?php echo $this->escapeHtml($this->getFormHtml()); ?>
                 </div>
             </div>
         </div>

Powinien pokazywać selektor sklepu po lewej, ale zamiast tego pokazuje HTML po prawej. Jeśli naprawdę potrzebujesz tej funkcji, musisz sprawdzić połączenie bezpieczeństwa z funkcjonalnością, co nie jest świetne.

pokaż złamaną hierarchię


0

Taki sam dokładny błąd, co w przypadku Tylera w patchu Magento 1.9.2.4 PATCH_SUPEE-10570_CE_v1.9.2.4_v1-2018-02-28-04-53-53.sh

checking file lib/Zend/Mail/Transport/Sendmail.php
Hunk #1 FAILED at 119.
Hunk #2 FAILED at 129.
2 out of 2 hunks FAILED

sprawdź, czy zainstalowałeś poprzednią łatkę. w szczególności łatka 9767
— Rama Chandran M

Sprawdziłem na www.magereport.com i potwierdziło, że wszystkie łatki zostały zainstalowane. 9767
— Roy Toledo

Sprawdzę i dostarczę ans
— Rama Chandran M

1
@royToledo Upewnij się, że zastosowałeś również poprawkę SUPEE-9652
— Tyler V.

0

Jeśli masz jakieś narzędzie do wykrywania poprawek, prawdopodobnie musisz zmodyfikować wykrywanie, SUPEE-9562 ponieważ SUPEE-10570modyfikuje ten sam plik:

lib/Zend/Mail/Transport/Sendmail.php

0

Łatka została cicho zmieniona przez Magento. Tutaj pokazano z łatką dla Magento 1.8.1.0-1.9.0.1. Przy pierwszym pobraniu mam plik

PATCH_SUPEE-10570_CE_v1.9.0.1_v1-2018-02-23-06-18-06.sh

Kilka dni później dostałem następujący plik

PATCH_SUPEE-10570_CE_v1.9.0.1_v1-2018-02-28-04-54-29.sh

Diff pokazuje, że poprzedni plik zawiera pliki z Magento Enterprise Edition, które zawierają niewłaściwą licencję „Umowa licencyjna użytkownika końcowego Magento Enterprise Edition”. Zostało to poprawione do „Open Software License (OSL 3.0)”.


0

Może pojawić się następujący błąd

Hunk #3 FAILED at 17 po linii

checking file app/code/core/Enterprise/Cms/Block/Adminhtml/Cms/Page/Edit/Tab/Hierarchy.php

Stało się to dla mnie w wersji Magento 1.10.0.2EE. Stało się tak, ponieważ nie zastosowano poprawki SUPEE-6285.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.