ข้อผิดพลาดในตัวแก้ไข Substack ที่เกิดจากการเขียนไฟล์ "/etc/hosts"

 (scalewithlee.substack.com)
1 คะแนน โดย GN⁺ 2025-04-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในตัวแก้ไขของ Substack จะเกิด ข้อผิดพลาดเครือข่าย เมื่อป้อนพาธระบบบางรายการ
  • Web Application Firewall (WAF) บล็อกพาธเหล่านี้เพื่อป้องกัน การโจมตีแบบ path traversal และ การโจมตีแบบ command injection
  • ประเด็นเรื่องการหาสมดุลระหว่าง ความปลอดภัย และ การใช้งาน จึงเด่นชัดขึ้น
  • จำเป็นต้องมีทางออกที่ดีกว่าสำหรับ นักเขียนสายเทคนิค
  • สามารถแก้ปัญหาได้ด้วยการใช้ พาธทางเลือก

เมื่อ /etc/h*sts รบกวนตัวแก้ไข Substack: การผจญภัยของการกรองเนื้อหาบนเว็บ

ข้อผิดพลาดเครือข่ายอันน่าพิศวง

  • ระหว่างเขียนโพสต์เชิงเทคนิคเกี่ยวกับการแปลงชื่อ DNS เกิด ข้อผิดพลาดที่ไม่คาดคิด
  • เมื่อพิมพ์พาธ /etc/h*sts จะเกิด ข้อผิดพลาดเครือข่าย และบันทึกอัตโนมัติล้มเหลว
  • หน้าสถานะของ Substack แสดงว่า ระบบทำงานปกติ

เริ่มต้นการสืบค้น

  • พบว่า ข้อผิดพลาด เกิดขึ้นเมื่อป้อนพาธไฟล์บางรายการ แต่ถ้าดัดแปลงพาธจะ ใช้งานได้ปกติ
  • พาธอย่าง /etc/h*sts ทำให้เกิดข้อผิดพลาด แต่พาธที่ดัดแปลงแล้วไม่มีปัญหา

มีอะไรเกิดขึ้นอยู่ภายใน?

  • ตรวจพบการตอบกลับ 403 Forbidden ในเครื่องมือนักพัฒนาของเบราว์เซอร์
  • มี Cloudflare เข้ามาเกี่ยวข้อง

ทำความเข้าใจตัวกรองความปลอดภัยของเว็บแอปพลิเคชัน

อธิบาย WAF แบบสั้น ๆ

  • Web Application Firewall (WAF) ทำหน้าที่เป็น ยามรักษาความปลอดภัย ของเว็บไซต์
  • คอย บล็อก คำขอที่น่าสงสัย

การโจมตีแบบ path traversal: ทำไมจึงต้องระวัง

  • การโจมตีแบบ path traversal คือความพยายามเข้าถึงไฟล์ระบบที่มีความอ่อนไหว
  • พาธอย่าง /etc/h*sts อาจตกเป็น เป้าหมายของการโจมตี ได้

Command injection: ปัญหาด้านความปลอดภัยอีกแบบหนึ่ง

  • การโจมตีแบบ command injection มุ่งให้มีการรันคำสั่งของระบบ
  • เมื่อมีการกล่าวถึงพาธระบบ ตัวกรองอาจ บล็อก ได้

ปริศนายิ่งลึกขึ้น: ตัวอย่างในอดีต

  • พบกรณีการใช้พาธคล้ายกันในโพสต์ Substack อื่น ๆ
  • เป็นไปได้ว่าพฤติกรรมการกรองอาจ เปลี่ยนไป ตั้งแต่ช่วงเวลาหนึ่ง

ความปลอดภัยเทียบกับการใช้งาน: สมดุลที่ละเอียดอ่อน

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

มองดูการตอบสนอง HTTP

  • ยืนยันสถานะ 403 Forbidden ได้ในระดับ API

ทางออกที่ดีกว่าสำหรับแพลตฟอร์มเนื้อหาเชิงเทคนิค

  1. การกรองตามบริบท: รับรู้พาธระบบใน code block หรือการสนทนาเชิงเทคนิค
  2. ข้อความผิดพลาดที่ชัดเจน: อธิบายว่าโดนบล็อกจากตัวกรองความปลอดภัย แทนคำว่า "ข้อผิดพลาดเครือข่าย"
  3. วิธีแก้ที่มีเอกสารรองรับ: แนะนำวิธีพูดถึงพาธที่อ่อนไหว

บทสรุป: จุดตัดกันของความปลอดภัยและงานเขียนเชิงเทคนิค

  • ปัญหาในตัวแก้ไขของ Substack เผยให้เห็นความท้าทายที่ซับซ้อนของ ความปลอดภัย และ การเขียนเชิงเทคนิค

  • สิ่งที่ตัวกรองความปลอดภัยอาจมองว่าเป็นรูปแบบการโจมตี แท้จริงแล้วอาจเป็น เนื้อหาที่ชอบด้วยเหตุผล

  • สามารถแก้ปัญหาได้ด้วยการใช้ พาธทางเลือก

  • ขอให้ผู้อ่านแชร์ประสบการณ์ในคอมเมนต์ หากเคยเจอปัญหาการกรองลักษณะคล้ายกันบนแพลตฟอร์มอื่น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-04-26
ความเห็นบน Hacker News

  • คนที่ตั้งกฎ WAF บน CDN มักไม่ค่อยเข้าใจเว็บไซต์และบริการที่จัดการเนื้อหาทางเทคนิคดีนัก ไม่ใช่แค่ Cloudflare เท่านั้น แต่ Akamai ก็เจอปัญหาเดียวกัน

    • ถ้าเป็นเว็บไซต์ที่ทำงานกับฐานข้อมูล การเปิดใช้กฎป้องกัน SQL injection พื้นฐานอาจทำให้เว็บพังได้
    • ยังมีกลุ่มกฎเกี่ยวกับ file inclusion ที่บล็อกสิ่งอย่าง /etc/hosts หรือ /etc/passwd
    • คิดว่าการหาสมดุลระหว่างความปลอดภัยกับการใช้งานเป็นเรื่องสำคัญ ถ้าใช้กฎ WAF ทุกข้อก็อาจปลอดภัยขึ้น แต่จะสร้างความลำบากให้บริการที่จำเป็นต้องพูดคุยเรื่องแนวคิดทางเทคนิค
    • การปรับแต่งกฎอย่างละเอียดกินเวลามาก ต้องแก้หลายอย่างเพื่อให้ยังคงใช้กฎไว้ได้พร้อมกับอนุญาต use case ที่ต้องการ
    • อาจเกิดปัญหาอย่างหน้าเว็บไม่โหลดหรือ resource ไม่โหลด จนทำให้อยากปิดกฎทิ้งไปเลย

  • ทำให้นึกถึงเกร็ดเรื่องหนึ่งเกี่ยวกับแพลตฟอร์มอีคอมเมิร์ซ: มีคนเขียนเว็บช็อปที่มี memory leak และแก้ปัญหาด้วยการรีสตาร์ตแอปเมื่อมีสตริง "OutOfMemoryException" ปรากฏในล็อก

    • นักพัฒนาคนอื่นอยากบันทึกคำค้นหาของลูกค้า แล้วถ้ามีคนพิมพ์ "OutOfMemoryException" ในช่องค้นหา ก็จะเกิดปัญหาขึ้น

  • สงสัยว่ามันบล็อก /etc/hosts หรือ /etc/./hosts ด้วยหรือไม่ เรื่องนี้ดูเป็นเกมตีตัวตุ่นที่แพ้ตั้งแต่แรก เพราะแฮ็กเกอร์ฉลาดกว่าและมุ่งมั่นกว่า จึงควรพึ่งพาเฉพาะความปลอดภัยที่ผ่านการพิสูจน์แล้วเท่านั้น

  • ความเห็นเกี่ยวกับวิธีที่ Substack จะปรับปรุงสถานการณ์นี้สำหรับนักเขียนสายเทคนิคได้

    • ไม่ควรรัน WAF โง่ ๆ บน endpoint ที่ให้คนแก้ไขบทความเกี่ยวกับหัวข้อใดก็ได้
    • มันเหมือนกับการทำ XSS filter ในฟอรัมเว็บดีเวลอปเมนต์จนสมาชิกคุยเรื่อง XSS กันไม่ได้
    • ควรเรียนรู้วิธี escape เนื้อหาอย่างเหมาะสม

  • ยกให้เป็นกรณีศึกษาที่น่าสนใจของความตึงเครียดระหว่างการป้องกันกับการใช้งานในความปลอดภัยเว็บ

    • แต่ในกรณีนี้มันชี้ให้เห็นบั๊กมากกว่า แม้ความตึงเครียดระหว่างความปลอดภัยกับการใช้งานจะมีอยู่จริง แต่กรณีนี้ไม่ใช่แบบนั้น
    • ความตึงเครียดระหว่างความปลอดภัยกับการใช้งานโดยทั่วไปคือ trade-off คือเพิ่มความปลอดภัยแล้วประสบการณ์ผู้ใช้จะแย่ลง
    • แต่กรณีนี้แสดงให้เห็นทั้งความปลอดภัยที่แย่และประสบการณ์ผู้ใช้ที่แย่

  • ปัญหาที่เกิดขึ้นระหว่างสอนทีมแข่งขันเขียนโปรแกรม: ถ้ามี type และคีย์เวิร์ดของ C++ ปรากฏในโค้ด จะขึ้นข้อผิดพลาด 403

    • ตอนทำงานที่ธนาคาร มี API ตัวหนึ่งที่ต้องส่งไฟล์ Python และไฟล์ Python ส่วนใหญ่กลับทำให้เกิดข้อผิดพลาด 403
    • แม้แต่ในสภาพแวดล้อมคลาวด์ใหม่ก็ยังเจอปัญหาคล้ายกัน

  • ปัญหาที่เกิดขึ้นเมื่อทีม red team ภายในโพสต์ข้อมูลที่มีความพยายามโจมตีแบบ XSS และการโจมตีแบบ injection อื่น ๆ รวมอยู่ด้วย

    • ตัวการโจมตีเองไม่ได้ทำงาน แต่การมีรายการเหล่านี้อยู่กลับทำให้หน้าแอดมินภายในโหลดไม่ขึ้น

  • ปัญหาเก่าแก่ที่ย้อนกลับมาอีกครั้ง เรื่องนี้เรียกว่า Scunthorpe problem

  • เคยเจอปัญหาคล้ายกันกับ OpenRouter ซึ่งเป็นบริการที่ให้ endpoint เดียวสำหรับใช้งาน LLM หลายตัว

    • ถ้ามีชิ้นส่วน HTML และ JavaScript บางแบบรวมอยู่ในเนื้อหา POST request คำขอจำนวนมากจะถูกบล็อก

  • การกรองเนื้อหาควรพึ่งพาบริบทอย่างมาก ถ้า WAF แยกขาดจากสิ่งที่มันต้องกรอง ปัญหาก็จะเกิดขึ้น

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