แพทช์ใหม่ supee-6788 วิธีใช้แพทช์

หลังจากสัปดาห์ของการรอคอยโปรแกรมแก้ไขในวันนี้ (27.10.2015) ถูกปล่อยออกมา: SUPEE-6788

มีหลายสิ่งที่ได้รับการติดตั้งและควรตรวจสอบโมดูลที่ติดตั้งเพื่อหาช่องโหว่ที่อาจเกิดขึ้น

ฉันเปิดโพสต์นี้เพื่อรับข้อมูลเชิงลึกเกี่ยวกับวิธีการใช้โปรแกรมแก้ไข ขั้นตอนในการใช้โปรแกรมแก้ไขมีอะไรบ้าง สำหรับความเข้าใจของฉันนี่คือขั้นตอน:

1. แก้ไขโมดูลด้วยฟังก์ชันการทำงานของผู้ดูแลระบบที่ไม่ได้อยู่ภายใต้ URL ของผู้ดูแลระบบ
2. แก้ไขโมดูลที่ใช้คำสั่ง SQL เป็นชื่อฟิลด์หรือฟิลด์ยกเว้น
3. White list block หรือ directives ที่ใช้ตัวแปรเช่น{{config path=”web/unsecure/base_url”}}และ{{bloc type=rss/order_new}}
4. การกล่าวถึงการหาประโยชน์ที่อาจเกิดขึ้นกับประเภทไฟล์ตัวเลือกที่กำหนดเอง (ไม่รู้จะทำอย่างไร)
5. ใช้โปรแกรมปะแก้

นี่เป็นขั้นตอนที่ถูกต้องหรือไม่?

โดยทั่วไปคุณสามารถใช้โปรแกรมแก้ไขเป็นโปรแกรมก่อนหน้าทั้งหมด ดูที่เอกสารอย่างเป็นทางการและตรวจสอบโพสต์ SEนี้ แต่ใช่มีบางจุดเพิ่มเติมที่คุณควรตรวจสอบเมื่อใช้โปรแกรมแก้ไขนี้ Byte / Hypernode มีโพสต์ที่ดีเกี่ยวกับมัน

1. ตรวจสอบว่ามีรูปแบบของคุณเองหรือที่กำหนดเองtemplate/customer/form/register.phtml หากเป็นกรณีนี้ให้แน่ใจว่ามันมีtemplate/persistent/customer/form/register.phtmlform_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

คุณสามารถค้นหาการaddFieldToFilterโทร2 สายที่ไม่เข้ากับ APPSEC-1063

สิ่งนี้กำลังทำลายลูกค้า> แอททริบิวต์กริดดังนั้นคุณต้องแก้ไขแพตช์โดยใช้กลอุบายที่พวกเขาแนะนำใน pdf "SUPEE-6788-Technical% 20 รายละเอียด% 20.pdf" ในส่วน APPSEC-1063

เปลี่ยนหลายอย่าง

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

(โดยที่ $ field มีคำสั่งที่ซับซ้อน (CASE .. เมื่อไหร่ที่แล้ว ... ) คำสั่ง sql)

เข้าไป

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

ทั้ง supee-6788-toolbox และ gaiterjones ของ rhoerr ไม่ตรวจพบปัญหาประเภทนี้ฉันได้ตรวจสอบส่วนอื่น ๆ ทั้งหมด -> addFieldToFilter ($ และดูเหมือนว่าจะไม่ทำให้เกิดปัญหา

ไฟล์หลัก 1.10 ที่ได้รับผลกระทบอื่น ๆ : (ค้นพบโดย supee-6788-toolbox ของ rhoerr)

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

อาจมีมากกว่านี้