อะไรปกป้องแบบฟอร์มได้จริง: CAPTCHA ช่องดักบอต กับดักเวลา และ CSRF
แบบฟอร์มติดต่อส่วนใหญ่พึ่งเทคนิคเดียวในการต้านสแปม และหลายเทคนิคหยุดได้เฉพาะบอตที่ง่ายที่สุด แต่ละชั้นหยุดอะไร มีต้นทุนอะไร และควรใช้ร่วมกันอย่างไร
สแปมผ่านแบบฟอร์มติดต่อแทบไม่เคยมาจากคนที่พิมพ์ด้วยมือ ส่วนใหญ่เป็นซอฟต์แวร์ที่หาแบบฟอร์ม กรอกทุกช่อง แล้วส่งผลลัพธ์ซ้ำหลายพันครั้ง มีวิธีป้องกันหลายแบบที่ทำงานในจุดต่างกันมาก การรู้ว่าแต่ละแบบทำอะไรได้จริงช่วยหลีกเลี่ยงข้อผิดพลาดสองอย่าง: แบบฟอร์มที่ไม่มีการป้องกันจริง และแบบฟอร์มที่ป้องกันแน่นหนาจนผู้ใช้จริงยอมแพ้
- ช่องดักบอต: บอตง่าย ๆ ที่กรอกทุกช่อง
- กับดักเวลา: สคริปต์ที่ส่งทันทีหลังโหลด
- CAPTCHA: ระบบอัตโนมัติทั่วไปส่วนใหญ่
- โทเค็น CSRF: คำขอที่ส่งตรงไปยังเอนด์พอยต์
- การจำกัดอัตรา: การส่งถล่มจากแหล่งเดียว
- การพิสูจน์การทำงาน: การส่งจำนวนมากที่มีต้นทุนต่ำ โดยไม่ติดตามหรือใช้ปริศนา
- การตรวจสอบฝั่งเซิร์ฟเวอร์: ทุกอย่างที่ข้ามเบราว์เซอร์
- บอตที่เจาะจงเว็บไซต์จะข้ามช่องนี้ หากซ่อนไม่ดี โปรแกรมอ่านหน้าจอจะอ่านให้ฟัง
- บอตที่รอเวลา และหากไม่มีลายเซ็นฝั่งเซิร์ฟเวอร์ก็ปลอมได้ง่าย
- เป็นอุปสรรคสำหรับทุกคน มีข้อจำกัดด้านการเข้าถึง มักพึ่งบุคคลที่สาม และมีบริการรับแก้ CAPTCHA
- บอตที่โหลดหน้าก่อนก็ได้รับโทเค็นที่ถูกต้องเช่นกัน
- สแปมที่กระจายมาจากที่อยู่ IP จำนวนมาก
- ผู้ส่งที่มุ่งมั่นและมีกำลังประมวลผล โดยต้องใช้ JavaScript
- เพียงลำพังไม่ได้ป้องกันอะไร แต่หากไม่มี การป้องกันชั้นอื่นทั้งหมดก็เป็นเพียงของตกแต่ง
ช่องดักบอตและกับดักเวลา: ตัวกรองที่มองไม่เห็น
ช่องดักบอตคือช่องเสริมที่คนมองไม่เห็น เช่น ช่องชื่อ “website” ที่ซ่อนด้วย CSS บอตง่าย ๆ จะกรอกทุกช่อง ดังนั้นช่องดักบอตที่มีข้อมูลจึงบ่งชี้การทำงานอัตโนมัติ และเซิร์ฟเวอร์สามารถทิ้งข้อความเงียบ ๆ ได้ บอตที่เขียนมาเพื่อเว็บไซต์นี้หรือบอตที่เรนเดอร์หน้าเหมือนเบราว์เซอร์จะข้ามช่องนี้ ต้องซ่อนให้ถูกวิธี: ช่องที่เพียงย้ายออกนอกหน้าจออาจถูกโปรแกรมอ่านหน้าจออ่าน เข้าถึงด้วยปุ่ม Tab หรือถูกกรอกอัตโนมัติได้ ใช้ aria-hidden, tabindex -1 และ autocomplete off พร้อมป้ายกำกับที่เป็นกลางเพื่อบอกผู้ที่เข้าถึงช่องนั้นให้เว้นว่างไว้
กับดักเวลาบันทึกเวลาที่ส่งแบบฟอร์มให้ผู้ใช้และปฏิเสธข้อมูลที่ส่งกลับเร็วเกินจริง คนต้องใช้เวลาสองสามวินาทีเพื่ออ่านและพิมพ์ แต่หลายสคริปต์ส่งภายในเสี้ยววินาที ต้องตรวจเวลาที่เซิร์ฟเวอร์และป้องกันการแก้ไข เช่น ลงลายเซ็นหรือเก็บไว้ในเซสชัน เพราะบอตเขียนทับช่องเวลาที่ซ่อนธรรมดาได้ง่าย ควรกำหนดเกณฑ์ให้ต่ำ เนื่องจากการกรอกอัตโนมัติก็ทำให้คนจริงกรอกเร็วได้ บอตที่เพียงรอเวลาก็ผ่านได้: กับดักเวลาเป็นตัวกรอง ไม่ใช่กำแพง
CAPTCHA: ได้ผล แต่มีต้นทุน
CAPTCHA ขอหลักฐานว่าไม่มีบอตกำลังทำงาน ตั้งแต่ปริศนารูปภาพไปจนถึงการตรวจที่ทำงานเบื้องหลัง บริการที่พบบ่อย ได้แก่ reCAPTCHA, hCaptcha, Cloudflare Turnstile และ Friendly Captcha วิธีนี้หยุดระบบอัตโนมัติทั่วไปได้ส่วนใหญ่ จึงเป็นที่นิยม แต่ทุกปริศนาที่มองเห็นเป็นอุปสรรคที่ทำให้ผู้เยี่ยมชมบางคนยอมแพ้ และบริการส่วนใหญ่โหลดสคริปต์ของบุคคลที่สามซึ่งทำให้เกิดคำถามเรื่องความเป็นส่วนตัวและความยินยอม CAPTCHA ยังช่วยได้ก็ต่อเมื่อตั้งค่าถูกต้อง คีย์เว็บไซต์ทดสอบสาธารณะ วิดเจ็ตที่ไม่มีสคริปต์ หรือโทเค็นที่เซิร์ฟเวอร์ไม่เคยตรวจสอบ ล้วนดูเหมือนป้องกันแต่ไม่ได้ป้องกัน การตรวจสอบฟรีที่ formexposed.com ชี้ข้อผิดพลาดเหล่านี้จากภายนอก
การเข้าถึงเป็นส่วนหนึ่งของต้นทุนนี้ ปริศนารูปภาพกีดกันคนตาบอดและคนสายตาเลือนรางจำนวนมาก ทางเลือกเสียงไม่ช่วยคนที่หูหนวกและตาบอด และโจทย์ตรรกะซับซ้อนเพิ่มภาระให้ผู้มีความบกพร่องทางการรู้คิด เกณฑ์ความสำเร็จ 1.1.1 ของ WCAG 2.2 กำหนดให้มีข้อความทางเลือกที่อธิบายวัตถุประสงค์ของ CAPTCHA และรูปแบบทางเลือกสำหรับประสาทสัมผัสต่างกัน การตรวจเบื้องหลังหลีกเลี่ยงปัญหาส่วนใหญ่ได้ แต่เมื่อพบสิ่งน่าสงสัย วิธีสำรองมักกลับเป็นปริศนารูปภาพอีก จึงต้องทดสอบเส้นทางนั้นด้วยแป้นพิมพ์และโปรแกรมอ่านหน้าจอ
โทเค็น CSRF: ป้องกันการปลอมคำขอ ไม่ใช่สแปม
โทเค็น CSRF คือค่าสุ่มที่เซิร์ฟเวอร์ใส่ในแบบฟอร์มและคาดว่าจะได้รับกลับมา ออกแบบมาเพื่อต้านการปลอมคำขอข้ามเว็บไซต์ ซึ่งเว็บไซต์อื่นทำให้เบราว์เซอร์ของผู้เยี่ยมชมส่งคำขอที่เจ้าตัวไม่ได้ตั้งใจ สำหรับแบบฟอร์มติดต่อสาธารณะ มีผลข้างเคียงคือปฏิเสธบอตที่ส่งตรงไปยังที่อยู่แบบฟอร์มโดยไม่โหลดหน้า บอตใดที่ดึงหน้ามาก่อนแล้วส่งโทเค็นกลับก็ผ่านได้ เฟรมเวิร์กและปลั๊กอินแบบฟอร์มส่วนใหญ่มีโทเค็น CSRF อยู่แล้ว ควรเปิดไว้ แต่ไม่ควรนับเป็นการป้องกันสแปม
สิ่งที่ต้องเกิดขึ้นบนเซิร์ฟเวอร์
- ตรวจสอบทุกช่องซ้ำที่เซิร์ฟเวอร์ ทั้งช่องที่ต้องกรอก ความยาว รูปแบบอีเมล และห้ามมีการขึ้นบรรทัดใหม่ในช่องที่จะนำไปใส่ในส่วนหัวอีเมล
- ตรวจสอบโทเค็น CAPTCHA และการพิสูจน์การทำงานทุกครั้งที่มีการส่ง โดยตรวจกับบริการผู้ออกหรือในโค้ดของตนเอง และปฏิเสธโทเค็นที่นำกลับมาใช้ซ้ำ
- จำกัดการส่งตามที่อยู่ IP และช่วงเวลา วิธีนี้หยุดการส่งถล่มจากแหล่งเดียวได้ ส่วนสแปมที่กระจายหลายที่อยู่ต้องใช้ชั้นอื่น
- พิจารณาการพิสูจน์การทำงาน: ก่อนส่ง เบราว์เซอร์แก้โจทย์คำนวณเล็กน้อย ผู้เยี่ยมชมไม่เห็นปริศนาและไม่มีการติดตาม แต่การส่งจำนวนมากมีต้นทุนสูงขึ้น
การใช้ร่วมกันอย่างเหมาะสม: สองหรือสามชั้น
- 1เริ่มจากชั้นที่มองไม่เห็น: ช่องดักบอตที่รองรับการเข้าถึงและกับดักเวลาที่ลงลายเซ็น โดยตรวจทั้งสองอย่างที่เซิร์ฟเวอร์
- 2เพิ่มการจำกัดอัตราต่อที่อยู่ IP เพื่อไม่ให้แหล่งเดียวส่งถล่มแบบฟอร์มได้
- 3หากสแปมที่เจาะจงยังผ่านได้ ให้เพิ่มการพิสูจน์การทำงานหรือ CAPTCHA โดยควรเลือกแบบที่ไม่มีปริศนาให้เห็นและมีทางเลือกที่รองรับการเข้าถึง
- 4เก็บโทเค็น CSRF ที่เฟรมเวิร์กให้มาไว้ โดยถือเป็นประโยชน์เสริม ไม่ใช่มาตรการต้านสแปม
- 5ทดสอบผลลัพธ์ในฐานะผู้เยี่ยมชม ทั้งใช้แป้นพิมพ์อย่างเดียว ใช้โปรแกรมอ่านหน้าจอ และใช้โทรศัพท์ พร้อมตรวจว่าข้อความจริงยังส่งถึง
สำหรับหลายเว็บไซต์ การใช้ช่องดักบอต กับดักเวลา และการจำกัดอัตราร่วมกันก็ขจัดสแปมทั่วไปส่วนใหญ่ได้แล้วโดยไม่มีอุปสรรคที่มองเห็น CAPTCHA เป็นตัวสำรองเมื่อยังไม่เพียงพอ บน WordPress ปลั๊กอินฟรีของ formexposed รวมช่องดักบอต การตรวจสอบเวลา และการพิสูจน์การทำงานโดยไม่ต้องใช้ Google หากต้องการดูสิ่งที่แบบฟอร์มแสดงจากภายนอก ว่ามีชั้นใดบ้างและตั้งค่า CAPTCHA อย่างมีประสิทธิภาพหรือไม่ การตรวจสอบฟรีที่ formexposed.com ใช้เพียงโดเมน ไม่ต้องมีบัญชี แต่ไม่สามารถเห็นโค้ดเซิร์ฟเวอร์ได้ ดังนั้นส่วนฝั่งเซิร์ฟเวอร์ยังเป็นหน้าที่ของผู้ดูแล