อะไรคือข้อเสียของการใช้โค้ดตัวกรอง PHP ในบล็อก, โหนด, views-args ฯลฯ ?

ฉันเคยเห็นหลายครั้งที่คนบอกว่าไม่ใช้ตัวกรอง PHP / PHP แบบกำหนดเอง (จาก Drupal UI) ในบล็อกโหนดมุมมอง args กฎและอื่น ๆ ฉันค้นหารอบเล็กน้อยและไม่พบมากดูเหมือนว่า นี่เป็นแนวทางปฏิบัติที่ดีที่สุดของ Drupal ที่ทุกคน "รู้"

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

เหตุผลบางอย่าง:

• รหัสในฐานข้อมูลของคุณไม่สามารถควบคุมเวอร์ชันและหาได้ยากในภายหลัง
• eval () 'd รหัสคือมากช้ากว่าสิ่งที่ hardcoded ในแฟ้ม
• หากมีข้อผิดพลาดบางอย่างในรหัสนั้นคุณจะได้รับข้อความแสดงข้อผิดพลาดที่ไม่ช่วยเหลือ (ข้อผิดพลาดในรหัส eval () ที่บรรทัดที่ 3) และคุณอาจผ่านฐานข้อมูลด้วยตนเองเพื่อค้นหาและแก้ไขข้อผิดพลาด หากอยู่ในบล็อกที่ปรากฏในทุกหน้าและส่งผลให้เกิดข้อผิดพลาดร้ายแรงตลอดเวลาเช่น
• ข้างต้นเป็นจริงเช่นกันเมื่ออัปเกรดจาก Drupal 6 เป็น 7 และ API ของสิ่งที่คุณใช้มีการเปลี่ยนแปลง ดังนั้นคุณจะต้องย้ายรหัสของคุณในขณะที่ย้ายข้อมูล หากรหัสอยู่ในโมดูลคุณสามารถพอร์ตล่วงหน้าทดสอบและปรับใช้กับไซต์ใหม่เท่านั้น ภายในโหนดหรือบล็อกมันจะใช้ได้กับ Drupal 6 หรือ 7 เท่านั้น
• การเขียนและดูแลรหัสนั้นก็ยากขึ้นเพราะคุณกำลังทำงานในฟิลด์ข้อความในเบราว์เซอร์ของคุณ การมีไว้ในโมดูลช่วยให้คุณใช้โปรแกรมแก้ไข / IDE พร้อมการเน้นไวยากรณ์การเติมข้อความอัตโนมัติและอื่น ๆ
• มีความเป็นไปได้ที่จะมีการกำหนดค่าผิดพลาดซึ่งทำให้ผู้ใช้สามารถเข้าถึงรูปแบบข้อความ / บล็อก / อะไรก็ได้ที่เปิดใช้งานการดำเนินการ php หาก php.module (ใน D7, D6 ไม่เข้มงวดมากนักเช่นสำหรับกฎการบล็อกการเข้าถึง) ไม่ได้เปิดใช้งานแม้แต่ความเสี่ยงนั้นก็ต่ำกว่ามากแล้ว
• หาก CMS ของคุณอนุญาตให้เรียกใช้งาน PHP ผู้โจมตีที่พบว่ามีช่องโหว่ความปลอดภัยของ XSS หรือการเพิ่มระดับสิทธิ์สามารถใช้เซิร์ฟเวอร์ของคุณเพื่อทำสิ่งที่เป็นอันตรายมหาศาล (เป็นส่วนหนึ่งของ DDOS ส่งสแปมโฮสติ้งมัลแวร์ เซิร์ฟเวอร์แฮ็คเข้าสู่เซิร์ฟเวอร์อื่น ๆ ในเครือข่ายที่อาจอยู่หลังไฟร์วอลล์) นอกจากจะทำให้ช่องโหว่เล็ก ๆ เจ็บปวดยิ่งขึ้นแล้วยังทำให้เว็บไซต์นั้นเป็นเป้าหมายของการโจมตีได้มากขึ้นหากรู้ว่าสามารถใช้งาน php ได้

อาจมีเหตุผลมากขึ้น แต่นั่นก็เพียงพอแล้ว :)

รหัสนี้ยากที่จะแก้ปัญหาและบำรุงรักษา ฉันไม่รู้วิธีการใช้การควบคุมเวอร์ชันสำหรับรหัส PHP ชนิดนั้น

และเป็นความเสี่ยงด้านความปลอดภัยที่อาจเกิดขึ้นกับผู้ที่เพิ่งเริ่มใช้ Drupal หรือ PHP

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

โดยทั่วไปจะดีกว่าที่จะหลีกเลี่ยงeval()เพราะจะลดความสามารถในการอ่านรหัสความสามารถในการทำนายเส้นทางของรหัส (และผลกระทบด้านความปลอดภัยที่เป็นไปได้) ก่อนรันไทม์และความสามารถในการดีบักรหัส

ออกจากกันในการพัฒนาเว็บไซต์หรือทดสอบผมจะไม่เปิดใช้งานตัวกรอง PHP, หรือใช้โค้ด PHP eval()ที่ส่งผ่านไป

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

ในฐานะที่เป็นวิธีแก้ปัญหาสำหรับปัญหาต่าง ๆ ที่ระบุข้างต้น - ความยากในการบำรุงรักษาโค้ดการควบคุมเวอร์ชันการค้นหาข้อผิดพลาดคุณมีความเป็นไปได้ "klugey" เล็กน้อย:

สร้างฟังก์ชั่น (ตั้งชื่ออย่างระมัดระวังตามสิ่งที่พวกเขาทำ) ในไฟล์บางไฟล์ที่รวมอยู่เสมอ - หากคุณมีโมดูลที่กำหนดเองที่คุณเขียนสำหรับไซต์ php ที่คุณป้อนนั้นเป็นเพียง: return my_specialfunc($somevar);- $somevarนี่อาจเป็นวัตถุโหนดทำงานหรือตัวแปรอื่น ๆ ที่เกี่ยวข้องที่นี่

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

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

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

<?php
echo file_get_contents(dirname(__FILE__)."/../sites/default/settings.php");
?>

การแฮ็คข้อมูลประจำตัวของ Drupal db

แทนที่จะทำสิ่งที่ชอบreturn functionname($object)จะเป็นการดีกว่าถ้าใช้โทเค็น / ตัวกรองระบบเท่าที่จะทำได้ มีโมดูลเช่นแทรกมุมมองและโหนดฝังตัวที่สามารถช่วยในสถานการณ์ทั่วไปที่ผู้คนต้องการฝัง PHP ในโหนดหรือบล็อกร่างกาย

คุณควรใส่ใจเกี่ยวกับการพกพาของข้อมูลของคุณ ถ้าคุณย้ายโหนดจาก drupal 7 ไปเป็น drupal 8 และเนื้อความของโหนดบางตัวมี<?php whatever_function_that_does_not_exist_anymore(); ?>อยู่ในนั้น?

อย่าคิดเกี่ยวกับโครงการของคุณภายใน 5 เดือน แต่ภายใน 5 ปี การอัปเดตการปฏิบัติที่ดีและการพกพาเป็นสิ่งสำคัญสำหรับโครงการไอทีที่ดีในความคิดของฉัน

การใช้โมดูลที่มีส่วนร่วมน้อยที่สุดเท่าที่จะเป็นไปได้ก็เป็นอีกด้านหนึ่งของเรื่องนี้