Новий патч supee-6788 як застосувати патч

Після тижнів очікування патча сьогодні (27.10.2015) його випустили: SUPEE-6788

Багато речей було зафіксовано, а також рекомендується переглянути встановлені модулі на предмет можливої ​​вразливості.

Я відкриваю цю публікацію, щоб отримати деяку інформацію про те, як застосувати патч. Які кроки застосувати патч? Наскільки я розумію, це такі кроки:

1. Виправити модулі з функцією адміністратора, яка не знаходиться під URL-адресою адміністратора
2. Виправити модулі, які використовують оператори SQL як імена полів або поля втечі
3. Блоки або директиви білого списку, в яких використовуються змінні типу {{config path=”web/unsecure/base_url”}}і{{bloc type=rss/order_new}}
4. Адресація потенційного експлуатації за допомогою типу файлу користувацьких опцій (не маю уявлення, як це зробити)
5. Нанесіть пластир

Це правильна процедура?

Взагалі ви можете застосувати виправлення, як і всі попередні. Перегляньте офіційну документацію та перевірте цю посаду SE . Але так, є кілька додаткових моментів, які слід перевірити, застосовуючи цей патч. Байт / Гіпернод має гарний пост про це.

1. Перевірте, чи є ваша тема власною template/customer/form/register.phtmlчи власною template/persistent/customer/form/register.phtml. Якщо це так, переконайтеся, що він містить a form_key.
2. Перевірте, чи є у вашої теми спеціальна layout/customer.xml. Якщо це так, обов'язково застосуйте необхідні зміни з патча ( customer_account_resetpasswordбуло змінено на customer_account_changeforgotten).
3. Чи використовуєте ви нестандартні змінні на сторінках CMS, статичних блоках або шаблонах електронної пошти? Потім переконайтеся, що ви їх додаєте в білий список. Дивіться це запитання щодо SE, щоб дізнатися, як додати список змінних / блоків.
4. Ви запускаєте cron.phpчерез HTTP? Переконайтеся, що вам краще користуватися cron.sh. Якщо це неможливо, принаймні переконайтеся, що ви телефонуєте cron.php через CLI PHP. Якщо з певних причин ви не можете налаштувати справжню cronjob і вам потрібно запустити її через HTTP, перегляньте це питання SE
5. Переконайтесь, що всі ваші розширення використовують "нову" маршрутизацію адміністратора. Ви можете використовувати цей плагін n98-magerun для перевірки. Ви також можете використовувати цей сценарій CLI . Ви також можете ознайомитись із цим пов'язаним питанням SE .
   6. Коли всі ваші розширення використовують належну маршрутизацію адміністратора, переконайтесь, що вимкнено "Увімкнути режим сумісності маршрутизатора з адміністратором" у розділі Система - Конфігурація - Адміністратор - Безпека.
6. Якщо ви використовуєте M2ePro, оновіть його до останньої версії, оскільки старі версії не працюють з новим патчем.

Під час оновлення переконайтесь, що ви видалили файл dev/tests/functional/.htaccess. Він більше не присутній у Magento 1.9.2.2. Тримаючи це означає, що ви все ще вразливі.

У будь-якому випадку перевірте свою сторінку за допомогою MageReport після оновлення, щоб побачити, чи все добре пішло.

Існує також технічна публікація блогу Piotr , в якій описані критичні зміни.

Існує файл перевірки, який допомагає визначити проблеми: https://github.com/gaiterjones/magento-appsec-file-check

Я зробив із нього сценарій CLI. https://github.com/Schrank/magento-appsec-file-check

Для Nginx переконайтесь, що ви заблокували доступ до cron.php та папки dev. Ми використовуємо цей блок:

location ~ ^/(app|includes|media/downloadable|pkginfo|report/config.xml|var|magmi|cron.php|dev)/? { deny all; }

Я щойно застосував патч на моїй 1.10.1 EE, і це спричиняє побічні ефекти на рідних екранах, оскільки ядро ​​не відповідає APPSEC-1063:

Приклад:

В app/code/core/Mage/Customer/Model/Entity/Attribute/Collection.php

Ви можете знайти 2 addFieldToFilterдзвінки, не сумісні з APPSEC-1063.

Це зламає сітки клієнта> атрибути, тому вам доведеться виправити патч, використовуючи фокус, який вони рекомендують, у pdf "SUPEE-6788-Technical% 20Details% 20.pdf" у розділі APPSEC-1063

Зміна кількох

    $this->addFieldToFilter($field, 0);

(де поле $ містить складні (CASE .. КОЛИ ...) sql заяви)

в

    $resultCondition = $this->_getConditionSql($field, 0);
    $this->_select->where($resultCondition);

Обидва rhoerr-пакети інструментів 6788 та інструменти і гайтерйони не виявили подібного роду проблеми, я перевірив усі інші -> addFieldToFilter ($ і, здається, ніхто не викликає проблеми.

Інші пошкоджені основні файли 1,10: (знайдено в rhoerr's supee-6788-toolbox)

app/code/core/Mage/Bundle/Model/Mysql4/Option/Collection.php 

Може бути і більше.