- Web Bot พัฒนามาตั้งแต่ การส่งคำขอแบบง่ายด้วย HTTP client ไปจนถึงการทำงานอัตโนมัติผ่านเบราว์เซอร์จริง และในขณะเดียวกัน เทคนิคการตรวจจับบอตก็ซับซ้อนขึ้นอย่างต่อเนื่อง
- มีการใช้เทคนิคหลากหลายในการตรวจจับบอต เช่น ชื่อเสียงของ IP, ลายนิ้วมือของ TCP/TLS/สภาพแวดล้อมเบราว์เซอร์, การวิเคราะห์พฤติกรรมด้วย JavaScript
- แม้ว่า เทคนิคหลบเลี่ยงของบอต อย่าง headless browser, proxy, การปลอม User-Agent จะพัฒนาไปมาก แต่ฝั่งอัลกอริทึมตรวจจับก็พัฒนาไปพร้อมกัน ทำให้เกมแบบ ‘แมวจับหนู’ ระหว่างสองฝ่ายยังคงดำเนินต่อไป
- ช่วงหลังยังมีการผสาน โมเดล AI ที่อิงข้อมูลพฤติกรรม เข้ากับการวิเคราะห์พฤติกรรมขั้นสูง ทำให้การตรวจจับบอตซับซ้อนยิ่งขึ้น
- ระบบป้องกันหลายชั้นอย่าง CAPTCHA, การตรวจจับพร็อกซี, Proof-of-Work, การยืนยันตัวตนตามพฤติกรรม กำลังกลายเป็นมาตรฐานทั่วไป
บทนำ: วิวัฒนาการของเว็บบอตและเทคโนโลยีตรวจจับ
- เว็บบอตมีหลายรูปแบบ ตั้งแต่ crawler และสคริปต์อัตโนมัติแบบง่าย ไปจนถึงโปรแกรมขั้นสูงที่ทำตัวเหมือนผู้ใช้จริง
- มีทั้งบอตที่มีประโยชน์ เช่น search engine และ archive bot แต่ก็มีการใช้งานในทางปัญหาอย่างสแปมและการสแครปข้อมูลโดยมิชอบจำนวนมาก
- ผู้ดูแลเว็บไซต์ต่อสู้กับบอตมาตั้งแต่ยุคแรก ๆ และทั้ง เทคนิคการตรวจจับและการหลบเลี่ยงก็พัฒนาขึ้นพร้อมกัน
บอตที่ง่ายที่สุด: HTTP client
- วิธีพื้นฐานที่สุดของบอตคือการส่งคำขอไปยังเว็บไซต์ด้วย HTTP client แบบง่ายอย่าง
curl, wget
- HTTP client ทุกตัวเปิดเผยตัวเองผ่านส่วนหัว
User-Agent ดังนั้นเว็บไซต์จึงตรวจจับและบล็อกได้ง่าย
- ถึงจะปลอม User-Agent ให้เป็นเบราว์เซอร์ได้ แต่เบราว์เซอร์จริงจะมีส่วนหัวเพิ่มเติม เช่น ภาษาและ encoding ดังนั้นหากปลอมไม่ครบก็ยังถูกตรวจจับได้อยู่ดี
ชื่อเสียงของ IP และพร็อกซี
- เซิร์ฟเวอร์ใช้ ที่อยู่ IP ในการตรวจจับบอต โดยเฉพาะช่วง IP ของคลาวด์และดาต้าเซ็นเตอร์ที่มักถูกมองว่าเป็นทราฟฟิกจากบอต/ระบบอัตโนมัติ จึงมีความน่าเชื่อถือต่ำ
- หากใช้งานโดยไม่มีพร็อกซีมักจะถูกบล็อกอย่างรวดเร็ว จึงต้องใช้ พร็อกซีที่อยู่อาศัย/มือถือ เพื่อหลบเลี่ยง IP ซึ่งมีต้นทุนตามมา
- เว็บไซต์ตรวจสอบอย่างจริงจังทั้งชื่อเสียงของ IP, การเปิดพอร์ตพร็อกซี (เช่น 1080), ช่วง IP และรูปแบบการเชื่อมต่อ
- เพื่อหลบเลี่ยงการบล็อก IP จึงมีการใช้ rotating proxy และ mobile proxy เป็นต้น
ลายนิ้วมือ TCP (TCP Fingerprinting)
- ตอนสร้าง การเชื่อมต่อ TCP ก่อนส่งคำขอ HTTP ระบบปฏิบัติการแต่ละแบบมีวิธีจัดรูปแบบแพ็กเก็ต TCP ต่างกัน จึงสามารถวิเคราะห์เพื่อระบุ OS ได้
- หาก User-Agent ไม่สอดคล้องกับ OS จริง (ลายนิ้วมือ TCP) ก็จะถูกมองว่าเป็นทราฟฟิกจากบอตหรือการปลอมตัว
- พร็อกซีเซิร์ฟเวอร์เองก็อาจส่งผลต่อลายนิ้วมือ TCP ได้ ดังนั้นตอนเลือกพร็อกซีจึงต้องคำนึงถึงความสอดคล้องกับ OS ด้วย
ลายนิ้วมือ TLS (TLS Fingerprinting)
- ระหว่างกระบวนการ TLS handshake รูปแบบการเข้ารหัสที่รองรับ เวอร์ชัน และส่วนขยายต่าง ๆ จะแตกต่างกันไปตามเบราว์เซอร์และ OS
- ลายนิ้วมือ TLS ช่วยคาดเดาเบราว์เซอร์ ระบบปฏิบัติการ และชนิดของไลบรารีได้ และสามารถนำไปตรวจสอบไขว้กับ User-Agent ได้
การตรวจจับด้วย JavaScript
- เซิร์ฟเวอร์จะเก็บข้อมูลเพิ่มเติมเกี่ยวกับสภาพแวดล้อมและพฤติกรรมของไคลเอนต์ด้วย JavaScript ก่อนตอบกลับหรือหลังหน้าเว็บโหลดเสร็จ
- หากบอตไม่รัน JavaScript ก็จะถูกตรวจจับได้ทันที และฝั่งบอตก็โต้ตอบด้วยการใช้เครื่องมือทำงานอัตโนมัติของเบราว์เซอร์อย่าง Selenium, Puppeteer, Playwright
- จึงกำลังเกิดวิวัฒนาการจากระดับคำขอ HTTP แบบง่ายไปสู่การทำงานอัตโนมัติผ่านเบราว์เซอร์
Headless browser และการตรวจจับ
- โหมด headless (เช่น Chrome แบบไม่มีหน้าต่าง) เป็นสิ่งจำเป็นต่อการพัฒนาบอต แต่ก็ตรวจจับได้จากความแตกต่างหลายอย่าง เช่น คุณสมบัติเฉพาะอย่าง
navigator.webdriver หรือรายการปลั๊กอินที่ว่างเปล่า
- แม้จะปลอมตัวได้ด้วยการแพตช์คุณสมบัติต่าง ๆ แต่ต้องจัดการ เบาะแสหลายสิบจุด ให้ครบ และยังมีจุดตรวจจับใหม่ ๆ เกิดขึ้นตลอดเวลา
- โหมด New Headless ที่เริ่มใช้ตั้งแต่ปี 2023 ใช้เอนจินเดียวกับ Chrome จริง ทำให้ตรวจจับได้ยากขึ้น
การตรวจจับ orchestration framework และ IPC
- เฟรมเวิร์กอัตโนมัติอย่าง Selenium และ Playwright มักเผยความผิดปกติจากแฟลกและออปชันเฉพาะ เวอร์ชันเบราว์เซอร์ และการตั้งค่าสภาพแวดล้อม
- ตัวอย่างเช่น แฟลกอย่าง
--disable-ipc-flooding-protection อาจกลายเป็นเบาะแสในการระบุสภาพแวดล้อมของบอต
- สามารถเรียกใช้ฟังก์ชัน JS บางตัว (เช่น
window.history.pushState) มากเกินไปเพื่อกระตุ้นให้เกิดสถานะ IPC flood และใช้เป็นจุดตรวจจับได้
การตรวจจับพร็อกซี: ยกระดับด้วย JS
- Latency (การวัดความหน่วง): เปรียบเทียบความหน่วงรวมที่วัดผ่าน WebSocket เป็นต้น กับความหน่วง TCP เพื่อตรวจสอบว่ามีพร็อกซีอยู่หรือไม่
- WebRTC Leak: ใช้ WebRTC ของเบราว์เซอร์เพื่อดู IP จริงของไคลเอนต์ แล้วเปรียบเทียบกับ IP ของคำขอ HTTP หากไม่ตรงกันก็อาจเป็นพร็อกซีหรือบอต
- DNS Leak: ให้ JavaScript เรียกซับโดเมนแบบสุ่ม แล้วตรวจจับรูปแบบผิดปกติ เช่น ประเทศไม่สอดคล้องกัน จากตำแหน่งของ DNS server/IP
- Timezones: เปรียบเทียบ timezone ของเบราว์เซอร์กับตำแหน่งของ IP เพื่อจับการใช้พร็อกซีหรือการปลอมตัว
CAPTCHA และการยืนยันตัวตน
- Captcha เป็นการยืนยันตัวตนแยกต่างหากเพื่อการตรวจจับ/บล็อกบอต โดยประกอบด้วยโจทย์ที่มนุษย์แก้ได้ เช่น การอ่านข้อความหรือการคลิก
- ระยะหลังมีการใช้ Captcha แบบ Proof-of-Work (บังคับให้คำนวณงานบางอย่าง) และ Captcha ตามพฤติกรรม (คลิกง่าย ๆ ร่วมกับการวิเคราะห์พฤติกรรม)
- บอตส่วนใหญ่หลบเลี่ยงแคปช่าโดยอาศัย บริการแก้แคปช่าภายนอกราคาถูก
การวิเคราะห์พฤติกรรมแบบง่าย/ขั้นสูง
- การวิเคราะห์พฤติกรรม จะดูความไม่มีประสิทธิภาพและความหลากหลายอันเป็นลักษณะเฉพาะของมนุษย์ เช่น การเคลื่อนไหวของเมาส์ รูปแบบการพิมพ์ ตำแหน่งและความเร็วในการคลิก
- ตัวอย่าง: การเคลื่อนเมาส์เป็นเส้นโค้ง, ดีเลย์ก่อนคลิก, ช่วงเวลาระหว่างการกดปุ่ม, เหตุการณ์ orientation/motion บนอุปกรณ์มือถือ เป็นต้น
- บอตมักเผยตัวง่ายจากการเคลื่อนที่เป็นเส้นตรง การพิมพ์เร็วสม่ำเสมอ หรือความเร็วในการตอบสนองที่ไม่สมจริง
- การวิเคราะห์พฤติกรรมขั้นสูง จะรวบรวมและเรียนรู้ข้อมูลพฤติกรรมของมนุษย์และบอตจำนวนมาก แล้วใช้ AI/แมชชีนเลิร์นนิงระบุได้แม้แต่แพตเทิร์นเล็ก ๆ
- เช่น การจำแนกจากข้อมูลผสมอย่างเส้นทางการเคลื่อนเมาส์ ความต่างของจังหวะระหว่าง keystroke หรือรูปแบบการท่องหน้าเว็บ
บทสรุปและข้อสังเกต
- เว็บบอต vs. เทคโนโลยีตรวจจับ คือ การต่อสู้ของการพัฒนาและการตอบโต้ที่ไม่สิ้นสุด และมีการผสมใช้หลายเทคนิคตั้งแต่ static fingerprint, การวิเคราะห์พฤติกรรม ไปจนถึงการตรวจจับด้วย AI
- แม้จะมีเทคนิคหลบเลี่ยงและปลอมตัวมากมาย แต่ผู้ให้บริการก็ยังต้องรับมือด้วย ระบบตรวจจับหลายชั้น การวิเคราะห์พฤติกรรมแบบเรียลไทม์ และโมเดล AI พร้อมการอัปเกรดอย่างต่อเนื่อง
- ฝั่งผู้พัฒนาบอตเองก็มีข้อจำกัดในการสร้างสภาพแวดล้อมปลอมตัวให้สมบูรณ์แบบ และจำเป็นต้องเข้าใจเทรนด์การตรวจจับล่าสุดรวมถึงวิธีรับมือ
ยังไม่มีความคิดเห็น