จะประเมินนามสกุลบุคคลที่สามได้อย่างไร

ในขณะที่ Magento ทำอะไรมากมายนอกกรอบเราพบว่ามีฟีเจอร์และสิ่งอำนวยความสะดวกที่จำเป็นสำหรับร้านค้าลูกค้าที่ต้องมีส่วนขยายจากบุคคลที่สามอย่างหลีกเลี่ยงไม่ได้

อย่างไรก็ตามด้วยลักษณะของสื่อมันอาจเป็นเรื่องที่มีความเสี่ยงที่จะแนะนำรหัส 'ต่างประเทศ' ให้กับระบบที่ซับซ้อนเช่นนี้ที่เกี่ยวข้องกับธุรกรรมเชิงพาณิชย์

สิ่งใดที่คุณมองหาเมื่อประเมินส่วนขยายของวีโอไอพี 'ธงแดง' ที่คุณเจอคืออะไร (หมูประสิทธิภาพความเสี่ยงด้านความปลอดภัยแนวทางปฏิบัติด้านสถาปัตยกรรมที่ไม่ดี)?

นี่คือความคิดบางอย่างเกี่ยวกับการประเมินโมดูลของบุคคลที่สาม:

ข้อมูลเบื้องต้น:

• รองรับเวอร์ชันวีโอไอพีปัจจุบัน - รองรับวีโอไอพีรุ่นล่าสุด (รวมถึงเวอร์ชันปัจจุบันที่เรากำลังพัฒนา)

  หากโมดูลไม่รองรับ Magento รุ่นล่าสุดอาจเป็นเรื่องยากที่จะทำให้มันทำงานได้โดยไม่ต้องใช้เวลาพัฒนาอันมีค่า

• สนับสนุน - นักพัฒนาที่สร้างโมดูลสนับสนุนผลิตภัณฑ์หรือไม่

  หนึ่งในสัญญาณของโมดูลที่มีสุขภาพดีคือผู้พัฒนาสนับสนุนอย่างแข็งขัน หากพวกเขาไม่สนับสนุนมันเป็นธงสีแดงทำไมพวกเขาจะไม่สนับสนุนผลิตภัณฑ์ถ้ามันดี

  นอกจากนี้เมื่อโมดูลได้รับการสนับสนุนเรามักจะได้รับข้อมูลที่สำคัญจากนักพัฒนาด้วยอีเมลง่ายๆ (ตัวอย่างเช่นโมดูลนี้ใช้ jQuery หรือ Prototype)

• รีวิว - ผู้ใช้รายอื่นกำลังพูดอะไร ประสบการณ์ของพวกเขาเป็นอย่างไร?

  โดยการอ่านรีวิวเราจะได้ภาพที่ดีขึ้นมีปัญหาในการติดตั้งหรือไม่? นักพัฒนาตอบสนองอย่างรวดเร็วและเป็นประโยชน์หรือไม่? มันทำงานได้ตามที่โฆษณาไว้หรือไม่

• การคืนเงิน - พวกเขาจะคืนเงินให้คุณหรือไม่หากไม่ได้ผลตามที่ตั้งใจไว้

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

กลาง:

• การแทนที่คลาส - โมดูลจะแทนที่คลาสหลักใด ๆ หรือไม่?

  โดยทั่วไปแล้วการพูดโมดูลที่ดีไม่ควรแทนที่คลาสหลักใด ๆ แต่ควรใช้ผู้สังเกตการณ์

  เหตุผลหนึ่งสำหรับเรื่องนี้คือมันสามารถทำให้การอัพเกรด Magento เป็นเรื่องยาก นอกจากนี้โมดูลอื่น ๆ อาจขึ้นอยู่กับหนึ่งเอาท์พุทจากฟังก์ชั่นที่กำหนดและโมดูลนี้จะให้หนึ่งที่แตกต่างกัน

  บางครั้งสิ่งนี้เป็นไปไม่ได้ที่จะทำถ้าเป็นกรณีนี้ควรมีเหตุผลที่ดีว่าทำไมมันถึงเอาชนะแกนหลัก

• การอัพเดตเลย์เอาต์ - โมดูลเปลี่ยนการตั้งค่าเลย์เอาต์ของฉันหรือไม่?

  บางโมดูลเปลี่ยนการตั้งค่าเค้าโครงในเว็บไซต์ของคุณ (ตัวอย่างเช่น: หน้าผลิตภัณฑ์) ตรวจสอบให้แน่ใจว่าไม่ได้ทำให้การจัดวางปัจจุบันของคุณเสียหายและหากทำสิ่งที่ต้องการ (อ่าน: ใช้เวลานานเท่าใดในการแก้ไข) .

• การเปลี่ยนแปลงเทมเพลต - โมดูลรวมถึงเทมเพลตที่เปลี่ยนการออกแบบปัจจุบันของฉันหรือไม่?

  โมดูลนี้จะแนะนำเทมเพลตใหม่หรือไม่ ถ้าใช่พวกเขาจะทำลายการออกแบบของฉันหรือไม่ ใช้เวลานานเท่าไหร่ในการออกแบบตามที่เราต้องการ?

• การพึ่งพา - โมดูลนั้นขึ้นอยู่กับโมดูลอื่นหรือไม่?

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

ขั้นสูง:

• สคริปต์อัพเกรด SQL - โมดูลอัพเดต DB อย่างใดหรือไม่?

  เมื่อโมดูลอัปเดตฐานข้อมูลเราต้องแน่ใจว่ามีบางสิ่ง

  มันปรับปรุงตารางหลักหรือไม่? ถ้าใช่มันไม่ดีเราต้องการให้ฐานข้อมูลของเราสะอาดและพร้อมสำหรับการอัพเกรด

  มันจัดเก็บข้อมูลอย่างเหมาะสมหรือไม่? หากเราต้องการรับข้อมูลดิบจากฐานข้อมูลด้วยตนเองเราจะสามารถเข้าใจได้หรือไม่

• กิจกรรม - โมดูลตรวจสอบหรือส่งเหตุการณ์ใด ๆ หรือไม่?

  หากโมดูลยื้อหรือสังเกตเหตุการณ์เราต้องการทราบ:

  กิจกรรมใดบ้างที่กำลังเฝ้าสังเกต / จัดส่ง? สิ่งนี้จะส่งผลกระทบต่อโมดูลอื่นที่ทำงานในระบบ ตัวอย่างเช่นหากหนึ่งในโมดูลของเราเปลี่ยนชื่อของผลิตภัณฑ์ของเราในการโหลดเป็นตัวพิมพ์ใหญ่และโมดูลนี้จะเพิ่มคำว่า 'ฟรี' เป็นชื่อของผลิตภัณฑ์ในการโหลดมันจะทำงานอย่างไร คำว่า 'ฟรี' จะปรากฏออกมาพร้อมซองใส่ด้านบนหรือไม่

• การตรวจสอบโค้ด - โมดูลใช้เทคนิคการเข้ารหัสที่ยอมรับได้หรือไม่?

  สิ่งนี้เกี่ยวข้องกับเทคนิคการเขียนโค้ด PHP มากกว่า Magento

  รหัสใช้บล็อกแบบลอง / จับได้หรือไม่

  รหัสหนีผู้ใช้ป้อนหรือไม่?

  ลักษณะเฉพาะนี้ขึ้นอยู่กับระดับความต้องการ / ความสามารถของเรา

• ปัญหาที่อาจเกิดขึ้น - ปัญหาที่อาจเกิดขึ้นจากการติดตั้งโมดูลนี้

  ลองจินตนาการถึงปัญหาห้าอันดับแรกที่อาจเกิดขึ้นได้หากเราติดตั้งโมดูลนี้น่าแปลกใจอย่างที่มันเป็นจริงมันให้ความเข้าใจในโครงการโดยรวม

บรรทัดล่างสุด:

ทุกสิ่งเหล่านี้เป็นสิ่งที่ดีที่มีในโลกอุดมคติในสถานการณ์โลกแห่งความเป็นจริงเราต้องทำสิ่งนี้เรียกว่า 'การประนีประนอม' :)

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

กล่าวอีกนัยหนึ่ง: ทั้งหมดนี้เกี่ยวกับการมีประสิทธิภาพตามเวลาของเราหากการใช้แนวทาง (รายการใน) ช่วยให้ฉันประหยัดเวลาในการใช้งานในระยะยาวหากไม่ใช้งานและช่วยให้คุณมีสุขภาพจิตดี

ธงสีแดง "การปฏิบัติที่ไม่เหมาะสม" ของวีโอไอพีบางกลุ่ม ได้แก่

• รหัสใด ๆ ใน app/code/local/Mage
• แม่แบบที่เขียนทับ (ไฟล์app/designที่มีอยู่แล้วในแกน)
• เขียนคลาสที่จำเป็นเช่นcatalog/productใหม่ โดยทั่วไปฉันดูที่การเขียนซ้ำทุกครั้งอย่างรอบคอบเพื่อดูว่าสามารถหลีกเลี่ยงได้หรือไม่
• การละเมิดมาตรฐานการเข้ารหัส Zend / Magento อย่างรุนแรง ในขณะที่นี่เป็นเพียงการจัดรูปแบบโค้ด แต่ฉันสรุปได้ว่าผู้พัฒนาที่ไม่ใส่ใจในมาตรฐานมักจะไม่สนใจเรื่องอื่น ๆ สำคัญกว่าและสิ่งอื่น ๆ ด้วย
• การเปลี่ยนแปลงในตารางฐานข้อมูลหลัก
• ข้อความที่เข้ารหัสยากในแม่แบบ (ไม่ได้ใช้กลไกการแปล) และที่อื่น ๆ
• ตรรกะทางธุรกิจในแม่แบบ (กฎง่ายๆ: สิ่งที่เกิดขึ้นMage::getModelในไดเรกทอรีแม่แบบมักเป็นสัญญาณที่ไม่ดี)

ค่าสถานะสีแดงที่เกี่ยวข้องกับ PHP (นี่คือรายการที่เลือกได้และไม่สมบูรณ์):

• ประกาศและคำเตือนใด ๆ ที่เปิดใช้งานการรายงานข้อผิดพลาด ( E_STRICT)
• การใช้งานของ@ผู้ประกอบการ
• ไม่ฆ่าเชื้อข้อมูลผู้ใช้ก่อนส่งออก

ประสิทธิภาพที่เกี่ยวข้องกับธงแดง:

• เคียวรีฐานข้อมูลภายในลูป
• กำลังโหลดคอลเล็กชันทั้งหมดเพื่อใช้เป็นส่วนหนึ่ง

ระวังกลิ่นรหัสทั่วไปด้วยซึ่งไม่จำเป็นต้องมีธงสีแดง แต่ช่วยในการประเมินคุณภาพโดยรวม

ขั้นตอนที่ # 1 - ลูกค้าของคุณสามารถให้การสนับสนุนส่วนขยายนี้ได้ไหมหากนักพัฒนาซอฟต์แวร์ไปที่ AWOL

ถ้าไม่คุณไม่สามารถใช้ส่วนขยายได้

ถ้าใช่ดำเนินการประเมินผลต่อไป

คนดีที่ Inchoo มีบทความเกี่ยวกับการวิเคราะห์รหัสโมดูลของบุคคลที่สาม บทความกล่าวถึงการเขียนคลาสงาน cron การปรับปรุงโครงร่างและผู้สังเกตการณ์เหตุการณ์

ฉันพบรหัสผู้สังเกตการณ์เหตุการณ์ที่มีศักยภาพสำหรับการเข้าชมที่มีประสิทธิภาพสูงสุด ระวังรหัสทรัพยากรของบุคคลที่สามที่ทำงานสำหรับกิจกรรมที่ส่งบ่อย กิจกรรมเช่น controller_action_predispatch หรือการรวบรวมการโหลด

ฉันใช้โมดูลยูทิลิตี้นี้จาก Prattski เพื่อรับภาพรวมที่ดีของการเขียนใหม่และผู้สังเกตการณ์

การมีเทมเพลตและสินทรัพย์ของสกินอยู่ในค่าเริ่มต้น / ค่าเริ่มต้น (หรือโปรหรือองค์กร) แทนฐาน / ค่าเริ่มต้นนั้นค่อนข้างน่ารำคาญ

รหัสที่ยุ่งเหยิงคือสิ่งที่ต้องระวัง - ค้นหาการโทรไปยัง eval (), base64_decode () และอื่น ๆ ที่คล้ายกัน สิ่งนี้มักจะใช้สำหรับการตรวจสอบใบอนุญาต แต่อาจเป็นอันตรายหรือน่ากลัว - ฉันเคยเห็นส่วนประกอบอย่างน้อยหนึ่งรายการที่เป็นรหัส arbitary จากฟีด RSS

มองหาการเรียก dl () - ส่วนประกอบเกตเวย์การชำระเงินอย่างน้อยหนึ่งรายการที่ฉันเคยเห็นต้องติดตั้งส่วนขยาย PHP เพื่อทำการเชื่อมต่อ!

คุณพูดถูก

โชคไม่ดีที่คุณต้องทดสอบตรวจสอบรหัสเพื่อดูว่ามีการพัฒนาดีมีการสนับสนุนที่ดีสำหรับโมดูลเชิงพาณิชย์ด้วยฟอรัมหรือความรวดเร็วในการตอบคำถามของคุณ ...

มีรีวิวบางอย่างเกี่ยวกับ Magento Connect และความนิยมของส่วนขยายสามารถช่วยให้รู้ว่ามันมีค่าหรือไม่ แต่โดยสุจริตคุณสามารถค้นหาโมดูลยอดนิยมที่มีข้อบกพร่องมากมาย ฉันมีตัวอย่างที่ดีเมื่อสัปดาห์ที่แล้วด้วยโมดูล MailChimp ซึ่งทำได้ดีมาก แต่ฉันต้องแก้ไขข้อบกพร่องบางอย่างและมอบให้กับผู้พัฒนา มีความเสี่ยงอยู่เสมอคุณต้องทำการทดสอบ

WebShopApp มีความคิดที่จะผลักดันทิศทางนี้ฉันหมายถึงการนำแพลตฟอร์มเพื่อรับข้อมูลที่ดีเกี่ยวกับโมดูล ความคิดคือการผลักดันวีโอไอพีในทิศทางนี้ ดังนั้นคุณภาพของโมดูลจึงเป็นคำถามจริง

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

การทดสอบอันดับที่ 1 ที่ฉันสามารถทำได้คือการหาช่องโหว่แบบ zero-day ในรหัสของพวกเขา (มักจะไม่ยากมากกับส่วนต่อขยายของวีโอไอพี) รายงานเฉพาะความเสียหายที่เกิดขึ้นจากการเอาเปรียบผู้เยาะเย้ยกับทีมรักษาความปลอดภัย ส่วนหนึ่งของรหัสมีความเสี่ยง) และเริ่มจับเวลา - เพราะนี่คือสิ่งที่จะเกิดขึ้นเมื่อไซต์ของคุณถูกแฮ็ก เมื่อเจ้าหน้าที่สนับสนุนของพวกเขาร้องขอการเข้าถึง FTP ทั่วโลกและ mysql โปรดปฏิเสธอย่างสุภาพว่าเป็นการละเมิด PCI-DSS และข้อเสนอเพื่อให้พวกเขาสามารถเข้าถึงที่เก็บแบบซอร์สโค้ดของคุณแบบอ่านอย่างเดียว

การทดสอบ # 2 ที่ฉันดำเนินการคือการโทรติดต่อผู้ขายและแจ้งให้ทราบล่วงหน้า ถามพวกเขาว่าการทดสอบพฤติกรรม / หน่วยที่พวกเขาทำคืออะไรระบบการควบคุมแหล่งที่มาที่พวกเขาใช้ PHP เวอร์ชันใดที่พวกเขาทำการทดสอบซึ่งเวอร์ชั่นของวีโอไอพีที่ได้รับการทดสอบซึ่งเว็บเซิร์ฟเวอร์ใด ๆ -stack สำหรับทดสอบส่วนประกอบส่วนหน้า ฯลฯ ... หากผู้ขายไม่ทราบว่าคุณกำลังพูดถึงอะไรเงียบหรือต้องการ "ให้ผู้เชี่ยวชาญส่งอีเมลถึงคุณกลับ" เรียกใช้เหมือนนรกเพราะพวกเขามักใช้หมายเลข ไฟล์ zip สำหรับ "การควบคุมเวอร์ชัน" และแก้ไขข้อบกพร่องเพียง 3 เดือนหลังจากที่ลูกค้ารายงาน

เมื่อพูดถึง PCI-DSS การแก้ไขระบบทั้งหมดจะต้องมีกลยุทธ์การพลิกกลับ ด้วยโมดูลที่เพิ่มคอลัมน์ที่ไม่เป็นโมฆะลงในตารางหลักสิ่งนี้จึงเป็นไปไม่ได้ในขณะที่ยังคงรักษากลยุทธ์การพลิกกลับที่จะผ่านการตรวจสอบ ทำงานเหมือนนรกจากโมดูลใด ๆ ที่จะทำให้เกิดปัญหา (อ่าน: ข้อผิดพลาดของ SQL) เมื่อปิดการใช้งาน

PCI-DSS v3

6.4.5.4 กระบวนการสำรองข้อมูล

ตรวจสอบว่ามีการเตรียมโพรซีเดอร์สำรองสำหรับการเปลี่ยนแปลงแต่ละตัวอย่าง

สำหรับการเปลี่ยนแปลงแต่ละครั้งควรมีขั้นตอนการสำรองข้อมูลในกรณีที่การเปลี่ยนแปลงล้มเหลวหรือส่งผลเสียต่อความปลอดภัยของแอปพลิเคชันหรือระบบเพื่อให้ระบบกู้คืนกลับสู่สถานะก่อนหน้า

นี้นอกเหนือไปจากคำตอบอื่น ๆ IMO ควรมีกำแพงแห่งความอับอายสำหรับอึอันตรายที่เกิดขึ้นบนแพลตฟอร์มนี้