วิธีตรวจสอบว่าระบบ WordPress ของคุณปลอดภัยจากการโจมตี XSS หรือไม่

ทั่วโลกเกือบ 48% ของเว็บไซต์ทั้งหมดมีความเสี่ยงต่อการเขียนสคริปต์ข้ามไซต์ (XSS) ทั่วโลกเกือบร้อยละ 25 ของเว็บไซต์ทั้งหมดใช้แพลตฟอร์ม WordPress

ตามแผนภาพเวนน์ของเว็บไซต์ที่เสี่ยงต่อ XSS และเว็บไซต์ที่ใช้แพลตฟอร์ม WordPress การทับซ้อนต้องมีขนาดค่อนข้างใหญ่

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

บทนำสู่การเขียนสคริปต์ข้ามไซต์

อันดับแรก มาพูดคุยกันถึงวิธีดำเนินการโจมตี XSS มีการโจมตี XSS มากกว่าหนึ่งประเภท ดังนั้นฉันจะเริ่มต้นด้วยคำจำกัดความที่ง่ายขึ้น โดยทั่วไป การโจมตี XSS จะเริ่มต้นด้วยอินพุตที่ไม่ถูกสุขอนามัย เช่น แบบฟอร์มความคิดเห็น กล่องแสดงความคิดเห็น แถบค้นหา และอื่นๆ การโจมตีเหล่านี้มีความแตกต่างกันอย่างมากในด้านความซับซ้อน อันที่จริง ผู้ใช้ WordPress รูปแบบที่ง่ายที่สุดของการโจมตี XSS จะเห็นได้ทุกวัน นั่นคือ ความคิดเห็นที่เป็นสแปม คุณรู้ว่าฉันกำลังพูดถึงอะไร: “ ขอบคุณสำหรับบทความที่ยอดเยี่ยม อีกอย่าง นี่คือไซต์ของฉันที่ฉันทำเงินได้ 5,000 เหรียญต่อสัปดาห์จากการทำงานที่บ้าน: www.only-an-idiot-would-click-this-link.co.uk ”

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

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

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

หยุดการโจมตี

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

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

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

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

[xhtml]
<script>CoughUpYourPreciousData();</script>
[/xhtml]

ตัวอย่างเช่น อาจทำให้บุคคลถัดไปที่เข้าชมหน้านั้นส่งสำเนาคุกกี้ของตนไปยังผู้โจมตี

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

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

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

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

วิธีอื่นๆ

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

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

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

การใช้งานจริงอื่นๆ

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

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

ความคิดสุดท้าย

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

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

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

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