Arkose Labs FunCaptcha คืออะไร: การท้าทายแบบ enforcement และการแก้
Arkose Labs ซึ่งนักพัฒนาหลายคนยังรู้จักในชื่อ FunCaptcha เป็นผู้ให้บริการ captcha ที่เว็บขนาดใหญ่ใช้กับการสมัครสมาชิก การเข้าสู่ระบบ และการชำระเงิน จุดเด่นที่สุดคือการท้าทายแบบ enforcement ซึ่งเป็นปริศนาสั้น ๆ คล้ายเกม เช่น การหมุนวัตถุหรือการจับคู่รูปแบบ ที่ปรากฏขึ้นเมื่อระบบประเมินความเสี่ยงตัดสินว่าผู้เข้าชมควรถูกตรวจสอบเพิ่มเติม การรองรับ Arkose ของ Scarnox เร็ว ๆ นี้ คู่มือนี้อธิบายว่าการท้าทายทำงานอย่างไร ทำไมจึงยากกว่า widget ธรรมดา และแนวทางทั่วไปสำหรับงานที่ถูกต้องตามกฎหมาย
วิธีที่การท้าทายของ Arkose ถูกส่งมา
หน้าที่ได้รับการป้องกันจะโหลดสคริปต์ของ Arkose และส่ง public key ที่ระบุเว็บไซต์นั้นให้สคริปต์ ตัวการท้าทายเองถูกให้บริการจากผู้ให้บริการ และ widget จะส่งคำตอบของผู้เข้าชมกลับมาในรูปของ token เช่นเดียวกับ widget แบบ token อื่น ๆ backend ของเว็บไซต์ต้องตรวจสอบ token นั้นกับผู้ให้บริการก่อนจะเชื่อถือผลลัพธ์
public key คือตัวระบุที่คุณใช้มองหาเมื่อจะทำงานกับหน้านั้น เหมือนกับที่ sitekey ระบุ widget ของ PopularCaptcha หรือ reCAPTCHA คู่มือหา captcha sitekey อธิบายวิธีหาตัวระบุเหล่านี้ในหน้าเว็บ
การท้าทายหน้าตาเป็นอย่างไร
การท้าทายของ Arkose มักสั้นและเป็นภาพ เช่น การหมุนรูปจนตั้งตรง การเลือกรายการที่ตรงกันในชุด หรือการทำตามลำดับในฉาก 3 มิติ การออกแบบเปลี่ยนบ่อย และแต่ละเว็บไซต์อาจใช้ชุดการท้าทายที่ต่างกัน ตัวปริศนาเองก็เป็นสัญญาณได้ด้วย วิธีที่ผู้เข้าชมเคลื่อนไหวและเวลาที่ใช้ อาจสำคัญพอ ๆ กับคำตอบสุดท้าย
ระบบประเมินความเสี่ยง
ก่อนแสดงการท้าทาย ผู้ให้บริการจะให้คะแนน session นั้น คะแนนนี้ใช้ข้อมูลจากสัญญาณของเบราว์เซอร์ ลักษณะของอุปกรณ์ ประวัติคำขอ และพฤติกรรมบนหน้าเว็บ ผู้เข้าชมที่มีความเสี่ยงต่ำอาจผ่านโดยไม่เจอการท้าทายเลย ผู้เข้าชมที่มีความเสี่ยงสูงกว่าจะเจอปริศนาหนึ่งข้อหรือมากกว่า และผู้ที่มีความเสี่ยงสูงมากอาจถูกบล็อก
เพราะระบบประเมินความเสี่ยงถูกปรับแต่งเฉพาะแต่ละเว็บไซต์และเปลี่ยนไปตามเวลา แนวทางทั่วไปที่ใช้ได้กับเว็บหนึ่งอาจใช้ไม่ได้กับอีกเว็บหนึ่ง นี่คือเหตุผลหนึ่งที่ enforcement challenge จัดการได้ยากกว่า widget ธรรมดา
ทำไม automation ถึงถูกตรวจจับ
automation ถูกตั้งธงด้วยเหตุผลเดียวกับการตรวจสอบแบบให้คะแนนอื่น ๆ ได้แก่ headless browser ที่ตั้งค่าเริ่มต้น session ใหม่ที่ไม่มีประวัติ รูปแบบคำขอที่เร็วและสม่ำเสมอ และ IP ที่มีชื่อเสียงไม่ดี แต่ละสัญญาณเพิ่มคะแนนความเสี่ยง จากนั้นการท้าทายจะขอสิ่งที่ automation ทำได้ไม่ดี เช่น การลากที่แม่นยำและดูเป็นธรรมชาติเหมือนคน
แนวทางที่ถูกต้องตามหลัก
สำหรับการทดสอบของคุณเองและงานที่ถูกต้องตามกฎหมาย แนวทางเหล่านี้ช่วยลดการท้าทายที่ไม่จำเป็น
- ใช้โปรไฟล์เบราว์เซอร์จริง ที่มีการตั้งค่าสม่ำเสมอ แทนที่จะใช้ build ของ automation ที่ตัดทอนออก
- รักษา session ให้ต่อเนื่อง เพื่อไม่ให้ผู้เข้าชมดูเหมือนคนใหม่ในทุกหน้า
- ควบคุมจังหวะคำขอ ให้อยู่ในอัตราที่คนทั่วไปทำได้อย่างสมเหตุสมผล
- ใช้สภาพแวดล้อมทดสอบของผู้ให้บริการ หากเว็บไซต์เป็นของคุณ Arkose และผู้ให้บริการรายใหญ่ส่วนใหญ่มีวิธีทดสอบการเชื่อมต่อโดยไม่ต้องให้ระบบประเมินความเสี่ยงจริงทำงาน
- ขอจากเจ้าของเว็บไซต์ ให้ allowlist, API หรือทางเลือกที่เข้าถึงได้ หากงานของคุณถูกต้องแต่ยังถูกบล็อก
แนวทางเหล่านี้ช่วยลดความถี่ที่การท้าทายปรากฏ แต่ไม่ได้ลบสิทธิ์ของผู้ให้บริการในการท้าทาย session และไม่ควรนำมาใช้เพื่อผ่านการป้องกันการเข้าสู่ระบบของบัญชีที่คุณไม่ได้เป็นเจ้าของ
Arkose solver จะทำอะไร
token-based Arkose solver จะรับ public key และ URL ของหน้า สร้าง token ที่ถูกต้อง แล้วส่งกลับมาให้โค้ดของคุณ จากนั้นโค้ดของคุณต้องส่ง token พร้อมฟอร์มก่อนที่ token จะหมดอายุ รูปแบบการเชื่อมต่อจะคล้ายกับขั้นตอนของ PopularCaptcha แบบใช้งานจริง แต่รายละเอียดต่างกัน และ Scarnox จะบันทึกประเภทงานและฟิลด์ไว้ใน เอกสาร API เมื่อการรองรับเปิดให้ใช้งาน
Scarnox ยังไม่แก้ Arkose แบบใช้งานจริงในวันนี้ ประเภทงานเดียวที่ใช้งานได้แบบสดคือ PopularCaptcha แบบ proxyless การรองรับ Arkose เร็ว ๆ นี้
เส้นแบ่งทางจริยธรรม
enforcement challenge มีไว้เพื่อปกป้องหน้าเข้าสู่ระบบ ขั้นตอนการชำระเงิน และฟอร์มสมัครสมาชิกจากการถูกใช้ในทางที่ผิด การใช้ solver กับโฟลว์เหล่านี้เพื่อเข้าสู่ระบบบัญชีที่ไม่ใช่ของคุณ สร้างบัญชีสแปม หรือซื้อสินค้าที่มีจำนวนจำกัดก่อนลูกค้าคนอื่น อยู่นอกขอบเขตที่ยอมรับได้ Scarnox ไม่รองรับการใช้งานเหล่านั้น งานที่ถูกต้องบนเว็บที่มีการป้องกันควรเริ่มจากเจ้าของเว็บไซต์ และคำตอบของเจ้าของจะเป็นตัวกำหนดว่าอะไรทำได้
สิ่งที่ควรตรวจสอบก่อนเริ่มงาน
ก่อนวางแผนงานใด ๆ กับโฟลว์ที่มี Arkose ป้องกันอยู่ ให้ตอบคำถามไม่กี่ข้อก่อน โฟลว์นี้เป็นของคุณหรือไม่ หากเป็น สภาพแวดล้อมทดสอบของผู้ให้บริการและ staging ของคุณเองคือที่ที่ควรใช้สร้างและทดสอบ งานนี้ถูกต้องหรือไม่ การเก็บข้อมูลสาธารณะในวิธีที่เว็บอนุญาตถือว่าถูกต้อง ส่วนการเข้าสู่ระบบบัญชีที่ไม่ใช่ของคุณ หรือการสร้างบัญชีจำนวนมาก ไม่ถูกต้อง เว็บไซต์มี API หรือ data feed ที่ทำให้ไม่ต้องใช้โฟลว์ผ่านเบราว์เซอร์หรือไม่ หลายเว็บมีให้ และเร็วกว่าและเสถียรกว่าการทำ automation กับการท้าทาย
จากนั้นดูปริมาณงาน การท้าทายแบบ enforcement ตอบสนองต่อพฤติกรรมตามเวลา งานที่รันในอัตราต่ำและสม่ำเสมอมักได้รับการท้าทายน้อยกว่าการยิงคำขอพร้อมกันเป็นชุด วางตารางเวลาโดยคำนึงถึงเรื่องนี้ และตรวจสอบให้แน่ใจว่างานจะหยุดและรายงานเมื่อพบการท้าทายที่ไม่ได้ออกแบบมารองรับ แทนที่จะลองซ้ำในลูป
สุดท้าย กำหนดไว้ล่วงหน้าว่างานจะทำอย่างไรเมื่อไม่สามารถทำการท้าทายให้สำเร็จได้ การล้มเหลวอย่างสะอาดพร้อม log ดีกว่าการลองซ้ำรัว ๆ ที่สร้างความเสียหายให้เว็บและทำให้ traffic ของคุณถูกบล็อก
การ scraping อย่างรับผิดชอบ
หากเว็บไซต์ที่มีการป้องกันคือเว็บที่คุณวางแผนจะ scrape ให้ตรวจสอบ robots.txt และข้อกำหนดการใช้งานก่อน รักษาอัตราการเรียกให้ต่ำ หลีกเลี่ยงข้อมูลส่วนบุคคลที่ไม่จำเป็น และมองหา API ก่อนจะสร้างโฟลว์ผ่านเบราว์เซอร์ คู่มือการ scrape เว็บให้ถูกกฎหมายหรือไม่ ครอบคลุมประเด็นหลัก