เพราะมาตรการความปลอดภัยที่ใช้กันทั่วไปเกิดจากการเชื่อคำการตลาด?
เราเชื่อว่าเจ้าของธุรกิจที่มีเว็บไซต์หลายท่านเคยหรือกำลังใช้บริการด้านความปลอดภัยโดยการติดตั้งปลั๊กอินความปลิดภัย (เช่น WordFence, Sucuri, iThemes เป็นต้น) ไม่ว่าจะติดตั้งด้วยตัวเองหรือคนทำเว็บไซต์เคยติดมาให้แล้วบอกว่าสบายใจหายห่วง(ตลอดกาล?) แต่เหตุการณ์มากมายในอดีต รวมถึงเคสของ Plugin สร้างเว็บไซต์อย่าง Bricks Builder ที่เพิ่งเกิดขึ้นไม่นานนี้ ย้ำเตือนเราว่าการเสริมความปลอดภัยไม่ควรทำในระดับเว็บไซต์เป็นหลัก แต่ควรทำในระดับเซิฟเวอร์ วันนี้มาเข้าใจจุดอ่อนเหล่านี้กันว่าเกิดขึ้นได้อย่างไร และเราจะพาคุณปรับแผนด้านความปลอดภัยให้ครอบคลุมหลายมิติมากขึ้นในยุคที่ภัยคุกคามทางไซเบอร์ทวีความรุนแรงขึ้นทุกวัน
โน้ตจากผู้เขียน: กรณีศึกษาในบทความนี้ได้แก้ไขเรียบร้อย โดยในวันที่มีการประกาศตรวจพบช่องโหว่ ทีมงาน Bricks Builder ได้จัดการด้วยความรวดเร็วและเป็นมืออาชีพภายในไม่กี่ชั่วโมงพร้อมออกแพทช์อัพเดทความปลอดภัยทันที เว็บไหนที่อัพเดทแล้วก็จะปลอดภัยทันทีเช่นกันครับ นี้เป็นเคสตัวอย่างที่ถือว่าดีระดับเวิล์ดคลาสในด้านการจัดการช่องโหว่เลยทีเดียว โปร่งใส รวดเร็วและจัดการเบ็ดเสร็จ สิ่งที่เกิดขึ้นในบทความนี้คือเว็บไซต์ที่ไม่ได้อัพเดทและปล่อยปะละเลยจนเกิดความเสียหาย สิ่งที่กล่าวถึงในบทความนี้เป็นการนำส่วนหนึ่งของโค้ดมาอธิบายเพื่อการศึกษา
ทำไมช่องโหว่บนเว็บไซต์ถึงยังมีอยู่ ไม่หมดไปซะที
ขึ้นชื่อว่าซอฟต์แวร์ การมีข้อบกพร่องหรือช่องโหว่เป็นของคู่กันอยู่แล้ว เป็นสัจธรรมเหมือน ‘ในน้ำมีปลา’เลยครับ โค้ดสำหรับพัฒนาเว็บไซต์ก็มีช่องโหว่ยอดฮิตที่สามารถถูกโจมตีได้บ่อยอย่าง Cross-Site Scripting (XSS), SQL Injection หรือรูปแบบอื่น ๆ ซึ่งอาจเกิดจากความผิดพลาดหรือเป็นสิ่งที่หลุดรอดจากขั้นตอนตรวจสอบความปลอดภัยของซอฟต์แวร์ก่อนที่จะปล่อยให้ใช้งานจริง (พูดตามตรง คนป้องกันกับคนจ้องจะทำลายย่อมมีความกระหายในการหาช่องโหว่ต่างกัน จริงไหมครับ?) และนี่คือสาเหตุที่ทำให้ช่องโหว่เหล่านี้เกิดขึ้น:
- ตัวโค้ดที่ซับซ้อน: เว็บไซต์มีระบบที่มีความซับซ้อนเพิ่มขึ้นเรื่อย ๆ ทั้งตัวซอฟต์แวร์หลัก ธีมที่เลือกใช้ ไปจนถึง Plugin มากมายที่ถูกติดตั้ง ดังนั้นช่องโหว่จึงอาจจะซ่อนอยู่ในส่วนใดก็ได้บนเว็บไซต์ของคุณ
- ความผิดพลาดของมนุษย์: นักพัฒนาก็เป็นมนุษย์ ดังนั้นความผิดพลาดจึงเป็นสิ่งที่เกิดขึ้นได้ และนั่นเปิดโอกาสให้พวกที่จ้องทำลายระบบเข้ามาโจมตี (WordPress โดยปกติปลอดภัยสูงครับ แต่ตัวปลั๊กอินสารพัดที่ถูกพัฒนาโดยโปรแกรมเมอร์ที่ไม่ใส่ใจมากกว่าที่ทำให้โดนแฮ็คบ่อย)
- การพัฒนาที่เร่งรีบ: แรงกดดันให้ปล่อยฟีเจอร์ใหม่ออกมาไว ๆ อาจทำให้มาตรการด้านความปลอดภัยต้องถูกมองข้ามไปก่อนในบางครั้ง
- ภัยคุกคามที่รุนแรงขึ้น: กลุ่มแฮ็กเกอร์สร้างสรรค์วิธีการล้วงข้อมูลรูปแบบใหม่เรื่อย ๆ ดังนั้นวิธีรักษาความปลอดภัยที่เคยใช้ได้ผลในอดีต (และ Plugin บางตัว) จึงอาจจะไล่ตามไม่ทัน หรือไม่อัพเดทความรู้ถึงภัยคุกคามในปัจจุบัน
Security Plugins: ความสะดวกสบายของผู้ไม่รู้
มาทำความเข้าใจก่อนนะครับว่า Security Plugins อย่าง Wordfence หรือ Sucuri นั้นมีความสำคัญ และเสริมความแข็งแกร่งให้เว็บไซต์เราได้เพียงส่วนหนึ่ง แต่ถูกใช้อย่างแพร่หลายเพราะความง่ายในการติดตั้ง บริษัททำเว็บหลายแห่งเพียงแค่ติดตั้งก็การโฆษราเลยว่า เราช่วยดูแลความปลอดภัยระดับองค์กร! แต่.. มันเป็นอย่างนั้นจริงไหม? เราจะพาคุรมาทำความรู้จักกับมันอย่างดีก่อน
ฟีเจอร์ส่วนใหญ่ของพวกปลั๊กอินด้านความปลอดภัยคือ
- สแกนหาร่องรอยภัยคุกคามที่รู้จักในฐานข้อมูลอยู่แล้ว (Malware scanner) ซึ่งฟังก์ชั่นนี้กินทรัพยากรเซิฟเวอร์ ทำให้เว็บช้าลงได้ คุณต้องคอยดูแลเรื่องประสิทธิภาพดีๆ นะ ครับ (อีกทั้ง WordFence ตัวฟรี มีข้อจำกัดหน่วงเวลาการอัพเดทฐานข้อมูลที่ 30 วันเลย ก็คือถ้าไวรัสใหม่เจอวันนี้ อีก 30 วันเขาถึงจะอัพเดทให้คุณแหนะ!)
- เฝ้าระวังกิจกรรมแปลก ๆ บนเว็บไซต์ (Malicious activity watch)
- มีตัวเลือกให้ปรับแต่งฟีเจอร์เพิ่มเติมเพื่อรักษาความปลอดภัยให้เข้มงวดขึ้น
แต่ประสิทธิภาพของ plugin พวกนี้ก็มีขีดจำกัดเหมือนกัน:
- ต้องคอยไล่ตามรูปแบบใหม่ ๆ ของแฮ็กเกอร์: Plugin หลายตัวใช้ฐานข้อมูลที่รู้จักอยู่แล้วเป็นเครื่องมือในการรักษาความปลอดภัย ฉะนั้นเวลาเจอการโจมตีรูปแบบใหม่ ๆ ที่ไม่รู้จัก (แบบ zero-day) เจ้าพวกนี้ก็ไม่สามารถช่วยอะไรได้ครับ เพราะไม่รู้จักนั่นเอง
- Plugin ต่าง ๆ อาจขัดกัน หรือมีบั๊กในตัว: การทำงานของแต่ละซอฟต์แวร์ในเว็บแอพพลิเคชั่นเดียวกันมีโอกาสทำงานขัดกันได้เสมอ Plugin ด้านความปลอดภัยอาจทำงานไม่ได้ราบรื่นถ้าไปมีบางฟังค์ชั่นที่ไปขัดกับการทำงานอื่นเช่น อาจจะทำให้หน้าบ้านแสดงผลผิดไปเพราะคิดว่าสคริปต์ตัวนี้ควรปิดการทำงานซะ เป็นต้น
- ความรับผิดชอบของผู้ใช้งาน: Plugin ด้านความปลอดภัยไม่ได้เก่งกาจไร้เทียบมทานชนิดที่ตั้งค่าครั้งเดียวจบ แต่เราต้องหมั่นอัปเดตและตั้งค่ามันอย่างเหมาะสมซึ่งตรงนี้ผู้ใช้เว็บไซต์หลายคนมักจะละเลยกันครับ
- ความโปร่งใสและความใส่ใจ: ช่องโหว่เกิดขึ้นได้ ฐานข้อมูลตามไม่ทันการโจมตีรูปแบบใหม่ก็เกิดขึ้นได้ครับ ปัญหาคือ ผู้ที่เราไว้ใจเรื่องความปลอดภัยได้ทำการออกมาแจ้งเตือนเราหรือเปล่าว่าเกิดอะไรขึ้นและให้รีบทำอะไรต่อ ซึ่งนี้คือปัญหาหลักของผู้พัฒนาส่วนใหญ่บนโลกของเราครับ พวกเขาเลือกที่จะปิดสิ่งที่เกิดขึ้นและปล่อยผ่านไปแบบให้จับมือใครดมไม่ได้ ดังนั้น ความโปร่งใส ความใส่ใจ และการรับมือสำคัญมากกว่าช่องโหว่ที่เกิดขึ้นครับ
กรณี Bricks Builder: ปลั๊กอินความปลอดภัยก็ช่วยอะไรไม่ได้
จุดอันตรายที่เกิดขึ้นกับซอฟต์แวร์สร้างเว็บไซต์อย่าง Bricks Builder ครั้งที่ผ่านมาเป็นช่องโหว่แบบ Cross-Site Scripting (XSS) ซึ่งผู้ที่ไม่หวังดีใช้ช่องนี้แทรกโค้ดอันตรายเข้ามาในเว็บไซต์ ถ้าเจาะลึกลงไปในตัวมัลแวร์ PHP ที่เกิดขึ้นในเหตุการณ์นี้ เราจะเห็นลักษณะการทำงานดังนี้:
โจมตีเข้าที่โค้ดหลักของ WordPress: โค้ดส่วนนี้ออกแบบมาเพื่อปิดการทำงานของ Plugin ด้านความปลอดภัยต่าง ๆ (อย่าง Wordfence หรือ Sucuri) ซึ่งปิดการทำงานได้ด้วยโค้ดไม่กี่บรรทัดเองครับ หลังจากนั้นมัลแวร์จะเข้าไปแก้ไขไฟล์หลักไฟล์หนึ่งของ WordPress นั่นคือ (wp-includes/pluggable.php)
สร้างทางลับเข้าออก (Backdoor): ในไฟล์หลักที่ว่า มัลแวร์จะฝังโค้ดสำหรับตรวจสอบคุกกี้ชนิดพิเศษที่ใส่ authentication key ลับของเว็บไซต์ไว้ ถ้าเจอคุกกี้นี้ มันจะข้ามขั้นตอนล็อคอินเข้าสู่ระบบปกติไปเลยทำให้ผู้ไม่หวังดีได้สิทธิ์แอดมินเต็มรูปแบบในการบริหารเว็บไซต์ครับ
มีโอกาสขโมยข้อมูล: โค้ดมัลแวร์ส่วนที่สองสามารถส่งข้อมูลสำคัญต่าง ๆ ของเว็บไซต์ออกไปให้แฮ็กเกอร์รู้ได้ด้วย
แหล่งโค้ดอ้างอิงเพื่อการศึกษา: https://gist.github.com/lynt-smitka/1eef476aed934fd3bc0be0813ea82f39#file-malware1-php-L34
ผลกระทบกับเจ้าของเว็บไซต์
มัลแวร์ตัวนี้ PHP อันตรายอย่างยิ่งกับทุกเว็บไซต์ที่ติดเข้าไป เพราะอาจเกิดปัญหาเหล่านี้ตามมา
- เว็บไซต์โดนควบคุมแบบเบ็ดเสร็จ: พอพวกคนร้ายได้สิทธิ์แอดมิน พวกมันก็ปรับแต่งหรือเพิ่มเนื้อหาอะไรลงไปก็ได้ (ทำให้หน้าตาเว็บไซต์เราเปลี่ยนไปโดยไม่ได้รับอนุญาต) ยกตัวอย่างเช่น การขโมยข้อมูลผู้ใช้ หรือถึงขั้นลบทั้งเว็บไซต์ก็ยังได้เลย
- ถูกใช้ล่อลวงข้อมูล หรือฝังมัลแวร์ต่อ: พวกมันจะเปลี่ยนเส้นทางผู้เยี่ยมชมเว็บไซต์ไปยังหน้าเข้าสู่ระบบปลอม เพื่อหลอกเอาข้อมูล หรือไม่ก็หลอกฝังมัลแวร์ไปยังเครื่องลูกค้าที่เข้ามาชมเว็บของคุณต่ออีกทอดหนึ่ง
- ชื่อเสียงของบริษัทเสียหาย: ลองจินตนาการตามนะครับว่าเว็บไซต์ของเราขึ้นเนื้อหาล่อแหลม แจกจ่ายไวรัส หรือโดน Search Engine อย่าง Google ตราหน้าว่าเป็นเว็บไซต์อันตราย การกู้ความเชื่อใจกับลูกค้าหลังเหตุการณ์เช่นนี้เป็นเรื่องยากมาก
- SEO พังพินาศ: แฮ็กเกอร์มักฝังลิงก์ หรือคีย์เวิร์ดแอบแฝงในเว็บเราเพื่อปรับแต่งผลการค้นหาให้เข้าทางพวกมัน ส่งผลให้การจัดอันดับเว็บไซต์ของเราดิ่งระนาว
- เปลืองทรัพยากรเซิร์ฟเวอร์: พอเปิดทางลับสำเร็จ เซิร์ฟเวอร์เราก็กลายเป็นของหวานของพวกมันได้เลย เว็บไซต์เราช้าลงเพราะถูกใช้งานเกินโควต้า เราอาจพบว่าต้องจ่ายค่า bandwidth แพงขึ้น หรือหนักเข้าก็โดนผู้ให้บริการโฮสติ้งระงับเว็บเราได้ครับ
ไม่ใช่เฉพาะ(เว็บที่ไม่อัพเดท) Bricks Builder เหตุการณ์นี้เกิดขึ้นได้กับทุกซอฟต์แวร์บนโลก (อย่าง Elementor เครื่องมือสร้างเว็บไซต์อันดับหนึ่งมีช่องโหว่แทบทุกเดือน ที่คุณอาจยังไม่รู้ อย่าลืมไปอัพเดทนะครับ) ในเมื่อเป็นเรื่องธรรมชาติ ให้คุณมองที่วิธีการรับมือเพื่อเลือกผู้ให้บริการที่ไว้วางใจได้ในการดูแลธุรกิจของคุณ
แล้วคุณจะทำอะไรได้บ้าง: ขั้นตอนการดูแลความปลอดภัยบนเว็บที่คุณทำได้
มองความปลอดภัยของเว็บไซต์เหมือนหัวหอมที่มีหลายชั้นซ้อนกันครับ อย่าฝากความหวังไว้ที่ plugin เป็นหลัก การทำให้เว็บไซต์ปลอดภัยอยู่เสมอเกิดจากการมีความรู้ มาตรการที่รัดกุม และการคอยตรวจสอบสม่ำเสมอ
เริ่มที่รากฐานที่มั่นคง: อัปเดตทุกปลั๊คอินให้เป็นเวิร์ชั่นล่าสุดอยู่เสมอ ไม่ว่าจะตัว WordPress, Theme หรือ Plugin ทั้งหลายที่เราใช้กัน หมั่นติดตามและอัปเดตทุกครั้งที่มีเวอร์ชันใหม่ เพราะพวกแฮ็กเกอร์ก็นั่งจ้องเวอร์ชันเก่า ๆ เป็นเป้าหมายหลักในการลงมือ (การติดตั้งปลั๊กอินก็ควรมีเกณฑ์ในการคัดเลือก เช่น ไม่ติดตั้งปลั๊กอินที่ดูเหมือนไม่ได้รับการพัฒนาแล้ว เป็นต้น)
การพัฒนาที่ละเอียดรอบคอบ: ถ้าคุณจ้างทำเว็บไซต์ ควรมั่นใจว่าธีมหรือ Plugin และวิธีการเขียนโค้ดที่คนทำเว็บไซต์นำมาใช้ต้องมีโค้ดที่ปลอดภัยมาเป็นอันดับแรกครับ สำคัญมาก ๆ ตรวจเช็คทุกอย่าง บางปลั๊คอินเสี่ยงโดนเจาะง่ายกว่าปลั๊คอินอื่น รวมถึงปลั๊คอินที่ไม่จำเป็นก็อย่าติดเยอะ ยิ่งปลั๊คอินเยอะ พื้นที่ในการโดนเจาะก็มากขึ้น (Surface of attack)
เลือกเครื่องมืออย่างชาญฉลาด: ติดตั้งเฉพาะ plugin หรือธีมที่มีชื่อเสียง จากแหล่งที่น่าเชื่อถือ ลองหาข้อมูลว่าผู้พัฒนาโปรแกรมเหล่านี้มีประวัติดีไหมและความแอทีฟเป็นยังไง ดูแลคนใช้งานดีไหม มี Roadmap ชัดเจนหรือไม่ ดูที่ความโปร่งใสในการให้ข้อมูล และมีความกระตือรือร้นที่จะปรับปรุงโปรแกรมอย่างรวดเร็วหรือไม่ เป็นต้น
เข้าถึงน้อยไว้ก่อน: จำกัดการเข้าถึงเว็บไซต์และความสามารถในการทำสิ่งต่าง ๆ ของบัญชีผู้ใช้ (User Permission) ให้ User ในแต่ละระดับทำสิ่งต่าง ๆ ได้เท่าที่ควรทำ เช่น ผู้เขียนก็ควรเขียนบทความได้อย่างเดียว ไม่ควรที่จะสามารถลงปลั๊กอินได้ เป็นต้น
ท่องให้ขึ้นใจ ต้อง ‘แบ็คอัพ แบ็คอัพ แบ็คอัพ’: สำรองข้อมูลเสมอ หากเว็บไซต์ของคุณเป็น E-Commerce หรือมีการอัพคอนเทนตบ่อย ยิ่งแบ็คอัพบ่อยยิ่งดี หากเกิดเหตุไม่คาดฝัน คุณจะกู้คืนได้ทุกเมื่อ
แกนหลักต้องเป็นการดูแลความปลอดภัยระดับเซิฟเวอร์และเน็ทเวิร์ค: อย่าปล่อยให้ใครบอกคุณว่าการติดปลั๊กอินก็พอแล้ว มันแย่ยิ่งกว่าคำว่า ‘ไม่พอ’ อีกครับในด้านความปลอดภัย เพราะคุณอาจอุ่นใจในสิ่งที่กันอะไรไม่ได้ จัดการความปลอดภัยต้องเริ่มที่ระดับบเซิฟเวอร์และเครือข่าย มันคือการป้องกันก่อนที่แฮคเกอร์จะเข้าถึงในระดับเว็บไซต์ของคุณ ทั้งการติดตั้ง Firewall, กำหนดกฎเกณฑ์ต่าง ๆ และการจำกัดการเข้าถึง เป็นต้น
เปรียบให้เห็นภาพง่าย ๆ การป้องกันด้วยปลั๊กอินเหมือนคุณจ้างรปภ.มาเดินตรวจใน ‘ตัวบ้าน’ ในขณะที่ระดับเซิฟเวอร์คือการติดตั้งรั้วไฟฟ้านอกบ้านอย่างดี ติดกล้องวงจรปิด และตั้งป้อมรปภ.ติดอาวุธทุกมุมรั้ว นั่นเอง
สรุป: การป้องกันที่ดีสุดคือการมีความเข้าใจและเลือกผู้ให้บริการที่ไว้ใจได้
การดูแลความปลอดภัยเป็นสิ่งสำคัญสำหรับทุกซอฟต์แวร์หรือเว็บไซต์ที่เข้าถึงจากอินเทอร์เน็ตได้ เพราะสิ่งที่ตามมานอกจากลูกค้าที่อยากซื้อสินค้าและบริการของคุณแล้ว ก็ยังมีผู้ไม่ประสงค์ดีที่คอยงัดแงะหาช่องโหว่ตลอดเวลา ยิ่งไปกว่านั้นพวกเขาก็พัฒนาวิธีการเจาะที่ล้ำขึ้นทุกวัน (เหมือนสถานการณ์มิจฉาชีพคอลเซ็นเตอร์ในปัจจุบันเลยครับ) ด้วยเหตุผลนี้แหละที่คุณคงเริ่มเห็นแล้วว่า การจัดการด้านความปลอดภัยแบบครั้งเดียว สบายใจตลอดชีพ มันไม่มีอยู่จริงครับ (Apple ยังอัพเดท OS กันแทบจะทุกสัปดาห์เลย)
หากคุณอ่านบทความนี้มาจนถึงตอนนี้ ผมมั่นใจว่าคุณเห็นภาพรวมและเข้าใจรายละเอียดของงานความปลอดภัยเยอะขึ้น หรืออย่างน้อย ๆ ก็หลีกหนีปลั๊กอินที่ไม่ตอบโจทย์ความปลอดภัยของคุณได้ ทั้งยังแอบกิน CPU กับ Ram เซิฟเวอร์ของคุณโดยไม่ได้ประสิทธิภาพในกรณีแบบนี้อีก แต่ถ้าต้องการติดตั้ง ก็มองหาเซิฟเวอร์แรง ๆ ไว้ครับ (และลองทดสอบประสิทธิภาพเมื่อเว็บเสร็จทุกครั้ง อย่าเพิ่งเชื่อผลทดสอบจากเว็บไซต์ที่เพิ่งติดตั้งใหม่เพราะโครงสร้างฐานข้อมูลยังไม่ซับซ้อนมากครับ) และมองหาผู้พัฒนาที่ตอบสนองต่อเหตุการณ์เลวร้ายได้ยอดเยี่ยมแบบเคสของ Bricks Builder (เหมือนมองหารัฐบาลที่ดีต้องมองหาผู้ที่จัดการวิกฤติและบริหารได้ดีนั่นแหละครับ เพราะเหตุร้ายหรือเศรษฐกิจไม่ดีเกิดขึ้นได้เสมอ)
นี่เป็นอีกเหตุผลหนึ่งที่นักพัฒนาทั่วโลกมั่นใจใน Bricks Builder เพราะนอกจากประสิทธิภาพที่ใส่ใจแล้ว การจัดการปัญหานี้ถือเป็น World Class Crisis Management อีกเคสหนึ่งทีเดียวครับ
