ทำไมฟังก์ชั่น PHP มากมายจึงไม่อนุญาตใน Magento ECG Coding Standard?

มาตรฐานการเข้ารหัส ECG ของ Magento ดูเหมือนจะเป็นทางการ (อย่างน้อยก็) เป็นมาตรฐานสำหรับ Magento 1 ส่วนขยาย:

https://github.com/magento-ecg/coding-standard

แต่ฉันไม่เข้าใจเหตุผลที่อยู่เบื้องหลังกฎทั้งหมดและการดมกลิ่นรหัสด้วยข้อความของพวกเขาเพียงอย่างเดียวไม่ได้ช่วยอะไรมาก มีเอกสารรายละเอียดเกี่ยวกับมาตรฐานหรือไม่ ฉันรู้วิธีปฏิบัติที่ดีที่สุดทั่วไปและคู่มือนักพัฒนาแต่ไม่พบสิ่งใดที่เฉพาะเจาะจงเกี่ยวกับมาตรฐานการเข้ารหัส

สิ่งที่ฉันกังวลมากที่สุดคือความเข้มงวดในการไม่ใช้ฟังก์ชั่น PHP

ตัวอย่างเช่น: ทำไมทุกระบบไฟล์ที่เกี่ยวข้องกับฟังก์ชั่น PHP ต้องห้าม ?

ผมคิดว่าคุณควรจะใช้Varien_Io_File, Varien_File_Objectฯลฯ แต่แม้นักพัฒนาหลักไม่ได้ตระหนักถึงทุกชั้นเรียน Varien และคุณมักจะพบสิ่งที่ต้องการในMage_ImportExport_Model_Import_Adapter_Csv:

    $this->_fileHandler = fopen($this->_source, 'r');

ดังนั้นแกนกลางไม่ใช่ตัวอย่างที่ดีที่สุดเช่นเคย

ฟังก์ชันที่ต้องห้าม IMHO อื่น ๆ ที่น่าสงสัย:

• mb_parse_str
• parse_str
• parse_url

• base64_decode

  • ใช่มันถูกใช้ในแบ็คดอร์ แต่การแบนevalควรเพียงพอและมีกรณีการใช้งานที่ถูกต้องเช่นการเข้ารหัสข้อมูลไบนารี่ และนอกเหนือจากjson_decode(ซึ่งไม่ได้รับอนุญาต) ไม่มีผู้ช่วยหลักสำหรับสิ่งนี้

ที่มา: https://github.com/magento-ecg/coding-standard/blob/master/Sniffs/Security/ForbiddenFunctionSniff.php

โดยพื้นฐานแล้วคำถามของฉันยังคงเป็น: มาตรฐานนี้บันทึกไว้ที่ไหน และ / หรือมีรายการ "สิ่งที่จะใช้แทนฟังก์ชัน PHP ดั้งเดิมเหล่านี้" หรือไม่?

ได้รับคำตอบอย่างไม่เป็นทางการจากทีม ECG ในเรื่องนั้น:

ก่อนอื่นฟังก์ชั่นที่ถูกตั้งค่าสถานะนั้นไม่จำเป็นต้องมีการอนุญาต - ควรทำการตรวจสอบการใช้งานด้วยตนเองเพื่อให้แน่ใจว่าใช้งานได้อย่างถูกกฎหมาย มันเป็นเครื่องมือช่วยเหลือการตรวจทานเครื่องมือการให้คะแนนโค้ดที่ไม่ดี / ไม่ดี

ประการที่สองข้อสันนิษฐานคือมันเป็นการดีกว่าที่จะใช้ Magento wrappers (ฟังก์ชั่น / คลาส) หากมีอยู่เนื่องจากอาจมีฟังก์ชันหรือการป้องกันเพิ่มเติม

ประการที่สามเป็นสำหรับการโทรเฉพาะ base64_decode มักจะใช้สำหรับฉีดรหัสที่เป็นอันตรายและส่วนที่เหลือเช่น parse_str อาจจะมีความเสี่ยงโดยเฉพาะอย่างยิ่งการจัดการการป้อนข้อมูลที่ไม่รู้จักหรือผู้ใช้บริการที่มีให้ - ดูตัวอย่างhttp://php-security.org/2010/05/ 31 / mops-2010-049-PHP-parse_str-หยุดชะงักหน่วยความจำทุจริตช่องโหว่ /

อีกครั้งนี่คือการตั้งค่าสถานะเพื่อตรวจสอบไม่ปฏิเสธรหัสที่ไม่ดี

หวังว่ามันจะช่วย

มาตรฐานการเข้ารหัสมีสองเป้าหมาย

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

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

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

ข้อมูลเพิ่มเติมอีกเล็กน้อย

ฟังก์ชั่นไฟล์มักอนุญาตให้ใช้งานโปรโตคอลแรปเปอร์หมายถึงพา ธ ไฟล์ที่เริ่มต้นด้วย http: // นำไปสู่ ​​http reaquest ซึ่งมักจะใช้สำหรับ "การโทรกลับบ้าน" และในบางครั้งก็ฆ่าร้านค้าเพราะเซิร์ฟเวอร์ไม่สามารถเข้าถึงได้ (30 วินาทีหมดเวลาเริ่มต้น) และสร้างขึ้นในสถานที่ส่วนกลางมาก

ทุก ๆ คนรู้ตัวว่า sql ไม่มีใครเชื่อว่ามีช่องโหว่ในการฉีด sql จำนวนเท่าใด ตัวอย่างที่ดีคือเมื่อค้นหาบนเว็บไซต์ Mysql ก็มี

มีตัวช่วยหลักสำหรับ json_decode บางแห่ง แต่มันมีการใช้งานที่เก่ามากเพียงแค่ใช้ json_decode ไม่มีความคิดว่าทำไมจึงควรห้าม

gettext เป็นส่วน php ที่น่าสนใจฉันจำได้ว่ามันใช้การติดตั้งระบบปฏิบัติการดั้งเดิมที่อาจมีปัญหาถ้าคุณใช้มันในแบบขนานกับภาษาอื่น ๆ (เช่นมักจะเกิดขึ้นเมื่อคุณมีภาษามากกว่าหนึ่งภาษาในร้านค้าของคุณ) แต่ไม่จำเป็นต้องมีใน Magento Context

จะเพิ่มเติมรายการที่ดูเหมือนจะเป็นเพียงรายการที่มีฟังก์ชั่นให้มากที่สุด ประวัติศาสตร์เป็นเรื่องตลกจริง ๆ ดูเหมือนว่าพวกเขาจะลบฟังก์ชั่นบางอย่างออกจากรายการหลังจากที่พวกเขาสังเกตเห็นพวกเขาใช้มัน : D