แนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยสำหรับ WordPress Plugin and Theme Developers

ในฐานะนักพัฒนา WordPress คุณต้องตัดสินใจหลายอย่างเกี่ยวกับสิ่งที่ต้องดำเนินการ ความสนใจและลำดับความสำคัญหลักของคุณคือการสร้างธีมหรือปลั๊กอินที่น่าตื่นตาตื่นใจ และมาตรการรักษาความปลอดภัยมักใช้เบาะหลังเมื่อคุณนั่งบนที่นั่งคนขับเพื่อทำงานกับโค้ด ครั้งสุดท้ายที่คุณนั่งลงและตรวจสอบรหัสของคุณเกี่ยวกับปัญหาด้านความปลอดภัยคือเมื่อใด ไม่ ฉันไม่ได้คิดอย่างนั้น

เคล็ดลับเหล่านี้อิงจากประสบการณ์ของฉันจากทั้งการพัฒนาปลั๊กอินที่ CleverPlugins และช่วยให้ลูกค้าจำนวนนับไม่ถ้วนนำเว็บไซต์ของตนกลับมาออนไลน์หลังจากถูกแฮ็ก การพัฒนาปลั๊กอินความปลอดภัยเช่น WP Security Ninja ไม่ได้ทำให้ฉันหวาดระแวงเกี่ยวกับโค้ดของคนอื่นน้อยลง

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

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

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

น่าเสียดาย ที่มักมีช่องโหว่ปรากฏขึ้นในผลิตภัณฑ์ที่มีชื่อเสียง ดังนั้นจึงควรใช้มาตรการรักษาความปลอดภัยขั้นพื้นฐานเพื่อปกป้องรหัสของคุณสำหรับผู้ใช้ของคุณ

แล้วทีมตรวจสอบ WordPress.org ล่ะ?

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

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

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

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

นี่คือสิ่งที่คุณสามารถทำได้เพื่อพัฒนาปลั๊กอินหรือธีม WordPress ของคุณอย่างปลอดภัย

1. นึกถึงความปลอดภัยจากทุกมุมมอง!

คุณไม่มีทางรู้ได้เลยว่าใครกำลังใช้ปลั๊กอินหรือธีมของคุณ และพวกเขามีความเข้าใจในระดับใดเกี่ยวกับความปลอดภัย หากมี

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

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

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

นั่นฟังดูหวาดระแวงหรือไม่? อาจจะ. แต่ถ้าและเมื่อปลั๊กอินหรือธีมของคุณเป็นที่นิยมอย่างมาก คุณจะยินดีที่จะใช้วิธีหวาดระแวงเพื่อความปลอดภัย

หากและเมื่อปลั๊กอินหรือธีมของคุณได้รับความนิยมอย่างมาก คุณยินดีที่จะใช้วิธีหวาดระแวงในการรักษาความปลอดภัยทวีต

2. ป้องกัน XSS – การโจมตีแบบ Cross-Site Scripting

สิ่งนี้มีความสำคัญมากขึ้นเรื่อย ๆ เนื่องจาก WordPress กำลังกลายเป็นโปรเจ็กต์ที่ขับเคลื่อนด้วยส่วนหน้ามากขึ้นด้วย Gutenberg และ ReactJS

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

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

แฮ็กเกอร์จะพยายามส่งความคิดเห็นด้วย "<script>alert('XSS');</script>"

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

เราสามารถป้องกันไม่ให้สิ่งนี้เกิดขึ้นได้ด้วยการตรวจสอบ ฆ่าเชื้อ และหลบหนี

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

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

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

มาดูตัวอย่างง่ายๆ แบบเดียวกับที่เราใช้ก่อนหน้า "<script>alert('XSS');</script>"

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

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

3. ระวังเกี่ยวกับการฉีด SQL

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

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

การฉีด SQL เป็นวิธีการโจมตีเว็บไซต์แบบเก่า แต่ก็ยังมีประสิทธิภาพมากและมีคนจำนวนมากที่กำลังมองหาวิธีที่จะใช้การโจมตีรูปแบบนี้ ในเดือนตุลาคม 2020 ปลั๊กอิน WordPress ยอดนิยมของ Loginizer ประกาศว่าพวกเขามีช่องโหว่ในการฉีด SQL ซึ่งทำให้เว็บไซต์กว่าล้านแห่งตกอยู่ในความเสี่ยง

ในปี 2019 แฮกเกอร์ที่ไม่รู้จักขโมยข้อมูลภาษีของชาวบัลแกเรียนับล้านผ่านการโจมตีแบบฉีด SQL และในปี 2559 กลุ่มแฮกเกอร์ชาวรัสเซียได้ดึงข้อมูลผู้มีสิทธิเลือกตั้งประมาณ 500,000 คนในโอไฮโอ การโจมตีประเภทนี้ยังคงมีประสิทธิภาพ และคุณสามารถหาข้อมูลมากมายเกี่ยวกับการโจมตีเหล่านี้

ที่มา: https://xkcd.com/327/

ตำแหน่งที่พบบ่อยที่สุดที่การฉีด SQL เกิดขึ้นคือในฟิลด์แบบฟอร์มที่ยอมรับการป้อนข้อมูลของผู้ใช้ ตัวอย่างเช่น ชื่อ การโจมตีเกิดขึ้นโดยการป้อนส่วนต่างๆ ของโค้ด SQL ในช่องป้อนข้อมูล สร้างคิวรีที่กำหนดเองซึ่งให้ผลลัพธ์ที่แตกต่างจากที่คุณคาดหวัง

สมมติว่าคุณมีแบบฟอร์มที่ช่วยให้ผู้ใช้สามารถค้นหาชื่อเฉพาะได้

SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' AND meta_key = 'celebrity_name';

ตัวอย่างง่ายๆ นี้จะดึงแถวทั้งหมดจากตารางเมตาของโพสต์ที่มีแถวทั้งหมดที่มีชื่อ Henry และคีย์เฉพาะ celebrity_name วิธีนี้ เราจะไม่ส่งคืนฐานข้อมูลทั้งหมดและเฉพาะแถวที่เราต้องการเท่านั้น

ผู้โจมตีจะพยายามแยกวิเคราะห์ค่าอื่น เช่น 'Henry' OR 1=1--

แบบสอบถามจะส่งคืนแถวทั้งหมดด้วยค่าเฉพาะของเราหรืออย่างอื่น - เนื่องจาก OR 1=1 ใน SQL เป็นจริงเสมอ

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

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

SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' OR 1=1--' AND meta_key = 'celebrity_name';

ซึ่งหมายความว่าแบบสอบถามมีลักษณะดังนี้:

SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' OR 1=1

ตอนนี้แบบสอบถามจะส่งกลับทุกอย่างในตารางฐานข้อมูลนั้นโดยพื้นฐานแล้ว

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

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

วิธีที่ง่ายและมีประสิทธิภาพคือการส่งอะพอสทรอฟี ' เป็นอินพุตและดูว่ามีการเปลี่ยนแปลงอะไรหรือไม่ มีข้อผิดพลาดเกิดขึ้น หรือส่งคืนผลลัพธ์เพิ่มเติม

WordPress เพื่อช่วยเหลือ

แทนที่จะโต้ตอบกับฐานข้อมูลโดยตรง นักพัฒนาควรใช้คลาส abstraction ฐานข้อมูลในตัวใน WordPress $wpdb

คลาส $wpdb ใน WordPress มีฟังก์ชัน CRUD ทั้งหมดที่คุณต้องการเพื่อโต้ตอบกับฐานข้อมูลได้อย่างปลอดภัย และคุณยังสามารถใช้คลาสเพื่อโต้ตอบกับตารางฐานข้อมูลของคุณเองได้หากต้องการปลั๊กอินหรือธีมของคุณ

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

สิ่งที่สำคัญที่สุดที่คุณสามารถทำได้เพื่อแก้ปัญหาคือเตรียมข้อมูลของคุณด้วย $wpdb->prepare()

ฟังก์ชันนี้ใช้สตริงคิวรีที่เตรียมไว้และอาร์เรย์ของอาร์กิวเมนต์ที่คุณต้องการเพิ่มลงในคิวรี SQL

$meta_key = 'celebrity_name';
$meta_val = 'Henry'
$allhenrys = $wpdb->get_results(
  $wpdb->prepare(
    "SELECT * FROM $wpdb->postmeta WHERE meta_key = %s AND meta_value = %s",
    $meta_key,
    $meta_val
  )
);

งานทั้งหมดเกิดขึ้นภายในฟังก์ชัน prepare() พารามิเตอร์แรก แบบสอบถามที่เตรียมไว้ – มีตัวยึดตำแหน่ง %s แทนค่าจริง สิ่งนี้ถูกแทนที่ด้วยตัวแปรแยกวิเคราะห์อื่นๆ $meta_key และ $meta_val

หมายเหตุ – สิ่งสำคัญคือต้องไม่มีอะพอสทรอฟีในคิวรีของคุณล้อมรอบพื้นที่ที่สำรองไว้ เนื่องจากฟังก์ชันจะเพิ่มสิ่งเหล่านั้นให้คุณ

นี่เป็นตัวอย่างที่เข้าใจง่าย แต่กระบวนการเดียวกันนี้สามารถใช้ได้กับการสืบค้นฐานข้อมูลใดๆ และคุณสามารถใช้ %s สำหรับสตริง %d สำหรับจำนวนเต็ม และ %f สำหรับการลอย

นอกจากนี้ยังมีฟังก์ชันสำหรับสถานการณ์เฉพาะ เช่น การเพิ่มแถวใหม่ลงในฐานข้อมูล เพื่อจุดประสงค์นี้ คุณสามารถใช้ $wpdb->insert()

$wpdb->insert(
  "{$wpdb->prefix}my_custom_table",
  array(
    'name'   => 'Henry',
    'userid' => 123,
    'score'  => 10,
  ),
  array(
    '%s',
    '%d',
    '%d',
  )
);

การใช้ฟังก์ชันการจัดเตรียมสามารถช่วยป้องกันความพยายามในการฉีด SQL ส่วนใหญ่กับผลิตภัณฑ์ของคุณ

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

4. ใช้ nonces เพื่อปกป้องคำขอของคุณ

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

เหมือนมีรหัสผ่านลับที่คุณต้องให้คนโกหกเพื่อเข้าคลับ

อย่างไรก็ตาม nonce ใน WordPress นั้นแตกต่างกันเล็กน้อย – ไม่ใช่ตัวเลขหรือ nonce ที่ใช้เพียงครั้งเดียว

ในทางเทคนิคแล้ว nonces ใน WordPress สามารถมีทั้งตัวพิมพ์เล็กและตัวเลข และแทนที่จะใช้เพียง ครั้งเดียว จะถูกสร้างใหม่หลังจากช่วงระยะเวลาหนึ่ง

วิธีที่คุณใช้ nonce คือโค้ด PHP ที่ลงทะเบียนไฟล์ JavaScript ของคุณจะสร้างตัวเลขและตัวอักษรผสมกันที่ไม่ซ้ำกันเล็กน้อย และแยกวิเคราะห์ตามนั้น เพื่อให้โค้ด JS ของคุณสามารถอ่านได้

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

มันง่ายกว่าเสมอด้วยตัวอย่าง มาดูวิธีง่ายๆ ในการโหลดไฟล์ .js ในปลั๊กอินของคุณโดยทำตามขั้นตอนเหล่านี้:

การใช้ nonce ในปลั๊กอิน WordPress

add_action('wp_enqueue_scripts', 'load_my_plugin_script');

function load_my_plugin_script() {
  // Register the script with all details and ensures it is loaded after jQuery
  wp_register_script('secure-plugin', plugin_dir_url( __FILE__ ). 'js/secure-plugin.js', array( 'jquery' ) );

  // Here happens the magic, we add some details to an object that we can later reference and read from in our JS code.
  wp_localize_script(
    'secure-plugin',
    'plugin_ajax_object',
    array(
      'nonce' => wp_create_nonce('secure-plugin-nonce')
    )
  );

  // Once that is done, we can now enqueue the script
  wp_enqueue_script('secure-plugin');
}

ในฟังก์ชันนี้ เราบอกให้ WordPress โหลดไฟล์ JavaScript ขั้นแรก เราลงทะเบียนไฟล์ที่เราต้องการโหลดด้วย wp_register_script()

จากนั้นเราใช้ wp_localize_script() เพื่อแยกวิเคราะห์อาร์เรย์ของข้อมูล โดยเฉพาะ "nonce" ที่มี nonce เฉพาะที่เราต้องการใช้ในโค้ด JS ของเรา จำไว้ว่า คุณสามารถส่งข้อมูลอื่นๆ ทุกประเภทในอาร์เรย์นั้นได้เช่นกัน แต่เราจะทำให้ง่ายในตัวอย่างนี้

เมื่อคุณส่งคำขอจากไฟล์ JavaScript คุณต้องรวม nonce ที่ไม่ซ้ำกันนั้นด้วย การทำเช่นนี้เป็นเรื่องง่าย:

การใช้ nonce จากปลั๊กอิน WordPress ในไฟล์ JavaScript

jQuery(document).ready(function($) {
  $.ajax({
    url: ajaxurl, // WP variable, contains URL pointing to admin-ajax.php
    type: 'POST',
    data: {
      'action':      'get_custom_data',
      '_ajax_nonce': plugin_ajax_object.nonce,
      'user_data':   'Some input from a user'
    },
    success: function( response ) {
      // Here we do what happens if all is good - update the interface with a success message!?
    },
    error: function( response ) {
      // Whooops, something went wrong!
      // console.log(response);
    }
  });
});

เนื่องจากเราใช้ wp_localize_script() เราจึงสามารถใช้ตัวแปร plugin_ajax_object ใน JavaScript ได้ เราส่ง nonce เป็นตัวแปร _ajax_nonce

ตรวจสอบและยืนยัน nonce ในปลั๊กอิน WordPress จากโค้ด JavaScript

add_action('wp_ajax_get_custom_data', 'get_custom_data');

function get_custom_data() {
  // Ready for the magic to protect your code?
  check_ajax_referer('secure-plugin-nonce');

  /**
   * That's it - the check_ajax_referer function verifies the nonce is correct or it dies and stops code execution if it fails.
   *
   * If you want to customize the error handling and perhaps return an error to your JS code, you could change the code to something like:
   * if ( ! check_ajax_referer( 'secure-plugin-nonce', false, false ) ) {    
   *   wp_send_json_error( 'Invalid nonce' );
   * }
   */

  $sanitized_user_data = sanitize_text_field( $_POST['user_data'] );

  // ... continue with the rest of your plugin's function code ...
}

ความมหัศจรรย์เกิดขึ้นกับฟังก์ชัน check_ajax_referer() ที่ตรวจสอบ nonce และล้มเหลวและหยุดการเรียกใช้โค้ดเพิ่มเติมหาก nonce ไม่ตรงกับที่คาดไว้

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

การใช้ nonce ในโค้ดของคุณเป็นวิธีที่รวดเร็ว ง่าย และมีประสิทธิภาพในการป้องกันการพยายามแฮ็คหลายประเภท ไม่ได้หมายความว่าคุณสามารถข้ามมาตรการรักษาความปลอดภัยอื่นๆ ได้ แต่จะช่วยลดปัญหาที่เลวร้ายที่สุดได้

จำสิ่งที่ฉันพูดเกี่ยวกับการไม่ไว้ใจใครได้ไหม? นั่นนำเราไปสู่อีกวิธีหนึ่งในการปกป้องรหัสของคุณ – การฆ่าเชื้อ

สมัครสมาชิกและรับหนังสือของเราฟรี

11 เทคนิคที่พิสูจน์แล้วเพื่อเพิ่มข้อพิพาทเกี่ยวกับบัตรเครดิตของคุณชนะอัตราความสำเร็จ 740%

แบ่งปันกับเพื่อน

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

ขอบคุณสำหรับการแชร์

ยอดเยี่ยม - สำเนา '11 เทคนิคที่พิสูจน์แล้วในการเพิ่มอัตราการชนะข้อพิพาทบัตรเครดิตของคุณ 740%' ถูกส่งไปที่ . ต้องการช่วยให้เรากระจายข่าวมากยิ่งขึ้นหรือไม่? ไปต่อ แบ่งปันหนังสือกับเพื่อนและเพื่อนร่วมงานของคุณ

ขอบคุณสำหรับการสมัคร!

- เราเพิ่งส่งสำเนา '11 เทคนิคที่พิสูจน์แล้วเพื่อเพิ่มอัตราการชนะข้อพิพาทบัตรเครดิตของคุณ 740%' ไปที่ .

แบ่งปันกับเพื่อน ส่งอีเมล อีกครั้ง

มีการพิมพ์ผิดในอีเมลของคุณ? คลิกที่นี่เพื่อแก้ไขที่อยู่อีเมลและส่งอีกครั้ง

ดาวน์โหลด

5. ฆ่าเชื้ออินพุตของผู้ใช้

ในตัวอย่างก่อนหน้านี้ เราได้รวมข้อมูลเพิ่มเติมที่ส่งจาก JS ไปยัง PHP ทุกครั้งที่คุณได้รับข้อมูลลงในโค้ดของคุณ คุณควรคาดหวังว่าข้อมูลจะไม่ปลอดภัย

'user_data':'Some input from a user'

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

ในการฆ่าเชื้อมา WordPress มีฟังก์ชันมากมายที่รับข้อมูลที่คุณป้อนและทำความสะอาดข้อมูลก่อนที่จะส่งคืนให้คุณ

ในตัวอย่างนี้ เราใช้ฟังก์ชัน sanitize_text_field() แต่ WordPress มาพร้อมกับฟังก์ชันฆ่าเชื้อมากมายที่เหมาะกับข้อมูลประเภทต่างๆ

มีฟังก์ชันและวิธีที่ยอดเยี่ยมอื่น ๆ อีกมากมายใน WordPress ที่คุณสามารถใช้เพื่อรักษารหัสของคุณให้ปลอดภัยและป้องกันการละเมิด

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

และนั่นนำฉันไปสู่เคล็ดลับต่อไป ซึ่งนักพัฒนา WordPress ส่วนใหญ่เคยประสบมา:

6. จำไว้ว่า is_admin() ไม่ใช่สิ่งที่คุณคิด

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

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

คุณจะไม่มีวันสังเกตเห็นหากคุณเพียงแค่ป้อนรหัสในปลั๊กอินของคุณ เนื่องจากคุณมักจะเรียกใช้รหัสในส่วนต่อประสานการดูแลระบบ และนั่นหมายความว่ารหัสจะถูกประเมินว่า true และคุณจะหยุดคิดเกี่ยวกับมันและดำเนินการต่อไป อื่น.

วิธีที่ถูกต้องในการตรวจสอบว่าผู้ใช้เป็นผู้ดูแลระบบหรือไม่ คือการตรวจสอบความสามารถของผู้ใช้:

  if ( current_user_can( 'activate_plugins' ) ) { 
    // Do your code here
  }

มีความสามารถที่แตกต่างกันสำหรับบทบาทของผู้ใช้ที่แตกต่างกัน ดังนั้นคุณจึงมีการควบคุมที่ละเอียดยิ่งขึ้น ในกรณีส่วนใหญ่ 'activate_plugins' คือสิ่งที่คุณต้องการสำหรับผู้ดูแลระบบเท่านั้น

หากคุณต้องการวิธีที่อนุญาตให้ทั้งผู้ดูแลระบบและบรรณาธิการทำบางสิ่ง คุณควรทดสอบความสามารถ 'edit_pages'

7. เพิ่ม rel=”noopener” หรือ rel=”noreferrer” ลงในลิงก์ของคุณ

การลิงก์ไปยังแหล่งข้อมูลภายนอกนั้นเป็นเรื่องปกติ และวิธีการแบบเก่าในการเพิ่ม target="_blank" ให้กับลิงก์เหล่านั้นก็สมเหตุสมผลดี เพราะคุณไม่ต้องการให้ผู้ใช้ออกจากหน้าปลั๊กอิน/ธีมของคุณ

อย่างไรก็ตาม สิ่งนี้เปิดให้คุณเห็นถึงสิ่งที่เรียกว่าทับนาบบิง นี่เป็นปัญหาด้านความปลอดภัยที่โค้ด JavaScript ที่เป็นอันตรายสามารถขโมยข้อมูลจากผู้ใช้ของคุณโดยใช้คุณสมบัติ JavaScript window.opener ในทางที่ผิด

การป้องกันสิ่งนี้สามารถทำได้ง่ายเพียงแค่เพิ่ม rel="noopener" ลงในลิงก์ของคุณ หน้าที่คุณลิงก์ไปยังวันนี้อาจใช้ได้ แต่อาจเปลี่ยนแปลงได้ในอนาคต

rel=noopener หมายถึงหน้าที่คุณเชื่อมโยงไปถึงไม่สามารถเข้าถึงข้อมูลหรือเข้าควบคุมเพจของคุณได้

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

หมายเหตุ: ไม่ควรสับสนระหว่างคุณสมบัติทั้งสองนี้กับ rel=nofollow ซึ่งเกี่ยวข้องกับ SEO

8. ใช้ HTTPS และ Secure Tokens กับ 3rd Party APIs

ในฐานะนักพัฒนา คุณมักจะต้องผสานรวม API และจำเป็นอย่างยิ่งที่จะต้องทำเช่นนี้อย่างปลอดภัยเพื่อปกป้องข้อมูลที่คุณกำลังส่งไปมา

โชคดีที่มีมาตรฐานอยู่แล้วเกี่ยวกับวิธีการทำสิ่งนี้อย่างปลอดภัย หนึ่งในนั้นคือ HTTPS การใช้ HTTPS ทำให้เกิดชั้นความปลอดภัยที่ข้อมูลทั้งหมดที่ส่งได้รับการเข้ารหัส

อย่างไรก็ตาม เพื่อให้แน่ใจว่าข้อมูลของคุณได้รับการปกป้องจากการสอดแนม การใช้ HTTPS ไม่เพียงพอ

ตามที่ Ars Technica อธิบายในบทความ "HTTPS ไม่ได้หมายความว่าข้อมูลของคุณปลอดภัย แต่หมายถึงการเชื่อมต่อของคุณปลอดภัย"

โทเค็นที่ปลอดภัย – JWT

มาตรฐานที่ปลอดภัยในการจัดการการสื่อสารและการรวม API คือการใช้ JSON Web Tokens, JWT

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

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

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

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

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

แหล่งข้อมูลที่ดีหากคุณต้องการเจาะลึกเกี่ยวกับโทเค็นและวิธีการทำงานของโทเค็นคือ Introduction to JSON Web Tokens

9. อย่าใช้ไลบรารีภายนอกจาก CDNs

แม้ว่าการรวมไลบรารี่ใดๆ ที่คุณอาจต้องการผ่าน cdnjs.com หรือ CDN ทั่วโลกฟรีอื่นๆ อาจเป็นเรื่องที่น่าดึงดูดใจ แต่ก็มีข้อเสียอยู่บ้าง

ก่อนอื่น คุณไม่สามารถควบคุมไลบรารีและโค้ดที่เป็นอันตรายใดๆ ที่แอบเข้าไปในไฟล์ที่คุณรวมไว้ได้

แม้ว่าโดยทั่วไปแล้ว CDN จะมีความเสถียรและรวดเร็วตามคำจำกัดความ แต่ก็อาจถูกโจมตีได้มากกว่า หากโค้ดของคุณใช้ไลบรารี JS บน CDN ภายใต้การโจมตี ปลั๊กอินและธีมของคุณจะโหลดช้ามากหรือไม่โหลดเลย

สิ่งนี้เกิดขึ้นกับเว็บไซต์ของลูกค้าที่ปลั๊กอิน CDN สาธารณะกำลังใช้อยู่ในขณะนั้นกำลังหมดเวลาสำหรับผู้ใช้ในบางภูมิภาคที่ทำให้อินเทอร์เฟซใช้งานไม่ได้ ในท้ายที่สุด ฉันต้องเปลี่ยนปลั๊กอินเพื่อใช้สำเนาในเครื่องของสคริปต์ JS แทนเพื่อแก้ไขด่วน

การใช้แหล่งข้อมูลภายนอกจากภายนอกอาจส่งผลต่อความเป็นส่วนตัวได้เช่นกัน เป็นไปได้ที่ CDN จะบันทึก IP ผู้ใช้ทั้งหมดของคุณ – อย่าลืมตรวจสอบนโยบาย GDPR และแจ้งให้ลูกค้าของคุณทราบ

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

เธอรู้รึเปล่า? WordPress มาพร้อมกับไลบรารี JS มากมาย ไลบรารี JS ทั่วไปจำนวนมากที่คุณอาจต้องการใช้นั้นมาพร้อมกับ WordPress ห้องสมุดเหล่านี้จะครอบคลุมความต้องการพื้นฐานส่วนใหญ่ของคุณ

เคล็ดลับสำหรับนักพัฒนา: โปรดโหลดเฉพาะไฟล์ JS และ CSS พิเศษในหน้าเฉพาะที่คุณต้องการ ในฐานะนักพัฒนาและผู้ใช้ ฉันไม่ชอบปลั๊กอินที่ทำให้ผู้ดูแลระบบช้าลงโดยการโหลดไฟล์ JS และ CSS ที่ไม่จำเป็นในทุกหน้า มันไม่เพียงแต่ทำให้หน้าผู้ดูแลระบบอื่นๆ ช้าลงเท่านั้น แต่ยังสามารถทำให้เลย์เอาต์ภาพยุ่งเหยิงและทำให้หน้าผู้ดูแลระบบบางหน้าใช้งานไม่ได้ โปรด

นอกจากนี้ยังมีเครื่องมือบางอย่างที่สามารถช่วยคุณปกป้องโค้ดของคุณได้ และเครื่องมือที่ยอดเยี่ยมที่คุณสามารถใช้ได้ฟรีคือ Coderisk

กำลังจ้าง

นักพัฒนา PHP อาวุโส

สร้างแกนหลักของผลิตภัณฑ์ บริการ และ API ของ Freemius และดูผลกระทบโดยตรงต่อธุรกิจปลั๊กอินและธีมของ WordPress

ผู้เชี่ยวชาญด้านการโยกย้ายอีคอมเมิร์ซ

จัดการการย้ายใบอนุญาตและกระบวนการรวมผลิตภัณฑ์สำหรับธุรกิจปลั๊กอินและธีมที่เริ่มขายด้วย Freemius

นักการตลาดเนื้อหา

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

10. ใช้เครื่องมือและบริการเพื่อวิเคราะห์รหัสของคุณ

Coderisk

มีบริการอัตโนมัติมากมายที่ช่วยระบุปัญหาโค้ด Exakat, SonarSource และ PHPStan เป็นต้น และรายการโปรดของฉัน – Coderisk.com – วิธีง่ายๆ ในการค้นหาข้อผิดพลาดด้านความปลอดภัยที่ชัดเจนในโค้ดของคุณ

บริษัทนี้สแกนปลั๊กอิน WordPress ทั้งหมดจากที่เก็บ WordPress.org สาธารณะ ซอฟต์แวร์ของพวกเขาสามารถสแกนและระบุปัญหาด้านความปลอดภัยประเภทต่างๆ ได้หลายร้อยประเภทตามมาตรฐานการเข้ารหัสที่แตกต่างกัน

จากสถิติของพวกเขาเอง พวกเขาได้สแกนโค้ดสาธารณะไปแล้วกว่า 4 พันล้านบรรทัด และมีปัญหาค่อนข้างมากกับปลั๊กอินชั้นนำ

การสมัครใช้บริการฟรีนั้นค่อนข้างง่าย – คุณสามารถสร้างบัญชีฟรีแล้วเริ่มอ้างสิทธิ์ในปลั๊กอินของคุณ การอ้างสิทธิ์ปลั๊กอินนั้นง่ายพอๆ กับการใช้โค้ดบรรทัดเดียวที่คุณใส่ใน readme.txt ในครั้งต่อไปที่คุณปรับใช้เวอร์ชันใหม่

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

โปรดทราบว่านี่เป็นบริการฟรี ดังนั้นพวกเขาจึงอาจไม่อัปเดตการสแกนปลั๊กอินของคุณบ่อยๆ แต่เมื่อคุณได้รับการแจ้งเตือน คุณควรตรวจสอบโค้ดของคุณ เนื่องจากคุณอาจมีข้อผิดพลาดตั้งแต่ครั้งล่าสุดที่คุณตรวจสอบ รหัสของคุณ

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

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

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

PHP_CodeSniffer

เครื่องมือที่ยอดเยี่ยมอีกตัวสำหรับตรวจสอบโค้ดของคุณคือ PHP_CodeSniffer PHPCS ประกอบด้วยสองสคริปต์ PHPCS ที่ตรวจสอบโค้ดของคุณและรายงานข้อผิดพลาดให้กับคุณ และ PHPCBF ที่สามารถแก้ไขปัญหาระยะยาวที่ PHPCS ระบุได้โดยอัตโนมัติ

การใช้ PHPCS นั้นใช้งานง่ายมากจากบรรทัดคำสั่งเมื่อคุณติดตั้งแล้ว เครื่องมือนี้จะไม่ป้องกันปัญหาด้านความปลอดภัยที่ปรากฏในโค้ดของคุณ แต่คุณสามารถขจัดข้อผิดพลาดในการเขียนโค้ดง่ายๆ ได้ ซึ่งทำให้ยากต่อการใช้ปัญหาที่ใหญ่กว่านี้มาก

นอกจากนี้ยังสามารถรวม PHPCS เข้ากับโปรแกรมแก้ไขของคุณได้โดยตรง เช่น Sublime Text และ Visual Code วิธีนี้ทำให้คุณสามารถดูข้อผิดพลาดและแก้ไขได้อย่างรวดเร็วใน IDE ของคุณ

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

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

11. ห้ามคัดลอกและวางโค้ดจากเว็บโดยไม่ได้รับการตรวจสอบอย่างเหมาะสม

การรักษาผลิตภัณฑ์ WP ของคุณให้ปลอดภัยที่สุดควรเป็นกระบวนการที่ต่อเนื่อง ไม่ใช่แค่นานๆ ครั้ง เมื่อคุณแนะนำคุณลักษณะใหม่หรือลบโค้ด คุณยังสามารถแนะนำปัญหาด้านความปลอดภัยใหม่ๆ ได้อีกด้วย

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

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

มีหลายสิ่งที่ต้องทำในฐานะนักพัฒนา WordPress และการแก้ไขปัญหาความปลอดภัยเร่งด่วนในปลั๊กอินของคุณด้วยการติดตั้งนับพันไม่ควรเป็นหนึ่งในนั้น

จำไว้ว่าชื่อเสียงของคุณเป็นเดิมพัน

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

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

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

หากคุณนำหน้าเกมในเรื่องการสื่อสารและปัญหา "การประชาสัมพันธ์" ที่อาจเกิดขึ้นจากช่องโหว่ คุณสามารถหลีกเลี่ยงปัญหาใหญ่โตและเพิ่มชื่อเสียงของคุณแทนที่จะทำลายมัน

ขอบคุณที่อ่าน!

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

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

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