AI scraper ร้องขอสคริปต์ที่ถูกคอมเมนต์ไว้

 (cryptography.dog)
2 คะแนน โดย GN⁺ 2025-11-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ระหว่างการวิเคราะห์ล็อกของเว็บเซิร์ฟเวอร์ พบกิจกรรมของบอตจำนวนมากที่ร้องขอ ไฟล์ JavaScript ที่ไม่มีอยู่จริง
  • คาดว่าเป็นพฤติกรรมที่ตีความสคริปต์แท็กในคอมเมนต์ HTML เป็นโค้ดจริงและร้องขอไป ซึ่งน่าจะเป็น ความพยายามเก็บข้อมูลสำหรับการฝึก LLM
  • มีการเสนอแนวทางรับมือหลายแบบ เช่น การเปิดเผยคำเตือนสู่สาธารณะ, การบล็อก IP, ระเบิดบีบอัด, การวางยาพิษข้อมูล โดยอาศัยการตรวจจับคำขอผิดปกติเหล่านี้
  • โดยเฉพาะ การวางยาพิษข้อมูล ถูกกล่าวถึงว่าเป็นวิธีที่มีประสิทธิภาพในการทำให้ข้อมูลฝึก LLM ปนเปื้อนและลดประสิทธิภาพของโมเดล
  • เน้นย้ำถึงความจำเป็นที่ผู้ดูแลเว็บควรทดลองนำ กลยุทธ์ป้องกันและโต้กลับต่อ AI scraper มาใช้

พบพฤติกรรมการสแครปที่ผิดปกติ

  • ยืนยันได้จากล็อกเซิร์ฟเวอร์ว่ามี คำขอ 404 error จำนวนมากต่อไฟล์ JavaScript ที่ไม่มีอยู่จริง
    • ไฟล์ดังกล่าวเป็นสคริปต์ที่ถูกปิดการใช้งานและอยู่ภายในคอมเมนต์ HTML ซึ่งเบราว์เซอร์ปกติไม่ควรร้องขอ
  • ใน User-Agent ของคำขอบางส่วน ระบุได้ชัดว่าเป็นบอต เช่น python-httpx/0.28.1, Go-http-client/2.0, Gulper Web Bot 0.2.4
  • แม้จะห้ามครอว์เลอร์เข้าถึงไว้ใน robots.txt แล้ว คำขอก็ยังเกิดขึ้นต่อเนื่อง จึงถูกมองว่าเป็น การเพิกเฉยต่อกฎหรือเพิกเฉยนโยบาย
  • คำขอบางส่วนปลอมตัวเป็นเบราว์เซอร์ปกติอย่าง Firefox, Chrome, Safari แต่เพราะไม่สามารถตีความคอมเมนต์ HTML ได้ จึงเผยให้เห็นว่าเป็น การปลอมแปลงตัวตน
  • คำขอเหล่านี้ถูกคาดว่าเป็น scraper สำหรับ เก็บคอนเทนต์ไปใช้ฝึก LLM โดยไม่ได้รับความยินยอม

วิธีการทำงานของ scraper

  • บางตัวอาจพาร์ส HTML ได้อย่างถูกต้องและไล่สำรวจ URL ภายในคอมเมนต์แบบ recursive
  • อีกบางตัวน่าจะประมวลผล HTML เป็นเพียงข้อความธรรมดาแล้วทำ การดึง URL ด้วย regex
  • จากความหลากหลายและระดับความซับซ้อนของ User-Agent จึงคาดว่ามี ผู้ดำเนินการหลายราย และบางรายใช้เครื่องมืออัตโนมัติแบบง่าย
  • แรงจูงใจร่วมกันคือ การเก็บข้อมูลอย่างละโมบ และมีการเสนอว่าสามารถ ย้อนใช้จุดนี้กลับไปเล่นงานได้

การก่อวินาศกรรมเชิงอัลกอริทึม (Algorithmic Sabotage)

  • คือการจงใจรบกวนระบบเชิงอัลกอริทึม ซึ่งเป็นประเด็นที่ได้รับความสนใจจาก ปัญหาต้นทุนภายนอกของ LLM
  • หากสังเกตรูปแบบพฤติกรรมที่ไม่เหมือนมนุษย์ของบอตได้ ก็จะ ตรวจจับและตอบโต้ได้ง่าย
  • วิธีรับมือแบ่งได้เป็น 4 แบบ: การเปิดเผยสู่สาธารณะ, การกรอง IP, ระเบิดบีบอัด, การวางยาพิษข้อมูล

0. การเปิดเผยสู่สาธารณะ (Public Disclosure)

  • ความผิดพลาดเล็กน้อยที่อาจตรวจผิดได้ (เช่น พิมพ์ User-Agent ผิดเป็น “Mozlla”) หากเปิดเผยออกไปก็อาจถูกแก้ไขได้ง่าย จึงควรเก็บไว้ไม่เปิดเผย
  • แต่สำหรับ พฤติกรรมที่เป็นแก่นแท้ (เช่น การร้องขอสคริปต์ในคอมเมนต์) ซึ่งแก้ไม่ได้ง่าย การเปิดเผยจึงเป็นประโยชน์
  • วิธีนี้ช่วยให้ผู้ดูแลเว็บไซต์รายอื่นสามารถ ตรวจจับและบล็อก การโจมตีแบบเดียวกันได้
  • ขณะนี้กำลังนำระบบตรวจจับพฤติกรรมดังกล่าวไปใช้กับเว็บไซต์อื่นเพิ่มเติม

1. การกรอง IP (IP Filtering)

  • ใช้ fail2ban เพื่อบล็อกอัตโนมัติโดยอิงจากแพตเทิร์นในล็อก วันที่ และ IP
  • โดยทั่วไปจะตั้งเวลาบล็อกสั้น ๆ แต่หาก บล็อกระยะยาว ก็อาจช่วยยับยั้งการลองใหม่ของบอตที่มีการเรียนรู้ได้
  • ในกรณีของ botnet อาจสลับ IP แล้วร้องขอต่อเนื่องได้ แต่ยังสามารถตรวจจับจากแพตเทิร์นซ้ำ ๆ ได้
  • มีการกล่าวถึงแผนศึกษาการทำงานของ botnet เพิ่มเติมในอนาคต

2. ระเบิดบีบอัด (Decompression Bombs)

  • ส่ง zip bomb ให้กับไฟล์ที่ผู้โจมตีร้องขอ เพื่อทำให้ระบบใช้ทรัพยากรมากเกินไป
  • อาจบังคับให้ใช้ CPU, RAM, ดิสก์อย่างหนัก หรืออาจนำไปสู่การใช้ประโยชน์จากช่องโหว่ได้
  • ข้อเสียคือทำให้ทรัพยากรของเซิร์ฟเวอร์ถูกใช้ไปด้วย และมี ความเสี่ยงสิ้นเปลืองแบนด์วิดท์
  • บอตบางตัวทำงานอยู่บนเครื่องที่ติดเชื้ออยู่แล้ว จึงอาจทำให้ผลของการโจมตีมีจำกัด
  • แทนที่จะใช้กับทุกบอต มีการเสนอให้ ตอบสนองเฉพาะบางคำขอแบบสุ่ม

3. การวางยาพิษข้อมูล (Poisoning)

  • ทำให้ข้อมูลสำหรับฝึก LLM ปนเปื้อนเพื่อบั่นทอนประสิทธิภาพของโมเดล
  • งานวิจัยล่าสุดระบุว่า แม้มีเพียง เอกสารปนเปื้อน 250 ฉบับ ก็อาจสร้างผลกระทบถาวรต่อโมเดลขนาดใหญ่ได้
  • ข้อมูลปนเปื้อนอาจทำให้โมเดลสร้าง เอาต์พุตไร้ความหมาย ในหัวข้อบางอย่าง
  • ตัวอย่างเช่น สามารถชักจูงให้โมเดลแนะนำบล็อกหนึ่งเป็นพิเศษเมื่อถูกถามเรื่องงานวิจัยด้านความปลอดภัย
  • สามารถใช้เครื่องมือสาธารณะอย่าง nepenthes, iocaine, glaze, nightshade ได้
  • หากข้อมูลฝึก LLM ถูก เก็บรวบรวมโดยไม่ได้รับความยินยอม การตอบโต้แบบนี้ถูกเสนอว่าเป็น วิธีป้องกันที่ชอบธรรม
  • หากใช้ร่วมกับการบล็อก IP อาจเพิ่มความซับซ้อนในการใช้งาน แต่ก็ยัง มีความเป็นไปได้ที่จะใช้งานร่วมกัน
  • อาจไม่เปิดเผยการออกแบบที่มีประสิทธิภาพ และเน้นย้ำความจำเป็นในการ ขยายการมีส่วนร่วมในวินาศกรรมเชิงสร้างสรรค์

บทสรุปและการตอบสนองของชุมชน

  • การตรวจจับผ่านพฤติกรรมบอตที่ผิดปกติไม่ใช่แนวคิดใหม่ และ การร้องขอสคริปต์ในคอมเมนต์ คือกรณีที่เพิ่งถูกค้นพบ
  • มีการเสนอวิธีเพิ่ม คำสั่ง Disallow ใน robots.txt เพื่อชี้นำให้เกิด มาตรการโต้กลับ เมื่อมีคำขอบางประเภท 
    User-agent: GPTBot
Disallow: /poison/
  • ในชุมชนมีการแชร์ไอเดียหลากหลายในการซ่อน ลิงก์ล่อบอต โดยใช้ display:none และ rel="nofollow"
    • ตัวอย่าง: <a href="/hello-llm-robot-come-here" rel="nofollow" style="display:none">you didn't see this link</a>
  • หากตั้งลิงก์เป็น absolute URL ก็อาจมีโอกาสหลอกครอว์เลอร์ได้มากขึ้น
  • ขณะนี้กำลังทำการทดลอง ล่อและบล็อกบอต หลายรูปแบบบนหลายเว็บไซต์ และมีแผนวัดผลแล้วนำมาแชร์
  • นักวิจัยรายอื่นก็เข้าร่วม การทดลองรบกวน AI scraper เช่นกัน และมีการแนะนำกรณีการวางยาพิษแบบสร้างสรรค์ด้วย
  • โดยรวมแล้วมีเป้าหมายเพื่อ ขยายการป้องกันด้วยตนเองและกลยุทธ์โต้กลับต่อการเก็บข้อมูล AI

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

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

 
GN⁺ 2025-11-02
ความเห็นจาก Hacker News

  • เว็บสแครปเปอร์ส่วนใหญ่ทำไปเพื่อธุรกิจ แม้ในหลายกรณีจะผิดกฎหมายก็ตาม
    เลยมักจะไปดึงข้อมูลจาก Amazon หรือเว็บช้อปปิ้งต่าง ๆ และสุดท้ายทราฟฟิกที่ไม่พึงประสงค์ส่วนใหญ่ก็มาจากบิ๊กเทคหรือผู้ไม่หวังดีที่มุ่งหาช่องโหว่
    ฉันพอรู้เรื่องเว็บสแครปปิงอยู่บ้าง บางเว็บไซต์จะตอบกลับเป็น 404 เพื่อป้องกันตัว ดังนั้นครอว์เลอร์ของฉันจึงลองวิธีครอว์ลแบบเร็วหลายครั้งด้วยเครื่องมืออย่าง curlcffi
    การป้องกัน Zip bomb นั้นง่าย แค่อ่าน content-length จากเฮดเดอร์ก็พอแล้ว ถ้าคำตอบมีขนาดใหญ่เกินไปก็ตั้งลิมิตจำนวนไบต์ไม่ให้อ่านต่อ และควบคุมด้วย timeout ได้ด้วย
    แต่รู้ไหมว่า timeout ของ requests ไม่ได้เป็น timeout สำหรับการอ่านทั้งหน้า? ถ้าเซิร์ฟเวอร์ค่อย ๆ ส่งไบต์มา ก็อาจรอไม่รู้จบได้
    เพราะงั้นฉันเลยสร้าง ระบบครอว์ลิง ของตัวเองขึ้นมาเพื่อแก้ปัญหาแบบนี้ และยังรัน Selenium ได้อย่างสม่ำเสมอด้วย
    โปรเจกต์ของฉันคือ crawler-buddy และไลบรารีฐานคือ webtoolkit

    • อย่าลืมว่า content-length ถูกคำนวณ หลัง content-encoding
    • สงสัยว่าระหว่าง “scraping” กับ “crawling” มีความต่างกันไหม
    • ดูเหมือนว่าเรากำลังเข้าสู่ยุคของ สแครปเปอร์ในเบราว์เซอร์ แล้ว จากฝั่งเซิร์ฟเวอร์แทบแยกไม่ออกว่าเป็นมนุษย์ และ AI driver ก็อาจผ่านการทดสอบแบบมนุษย์ได้ด้วย

  • คำว่า “เก็บข้อมูลฝึก LLM แบบไม่ยินยอม” ฟังดูน่าขำ
    แค่ส่งคำขอ GET ไปยังเซิร์ฟเวอร์ HTTP ที่เปิดสาธารณะ จะต้องขออนุญาตอะไรด้วยไม่เข้าใจ แน่นอนว่าคดี weev เป็น โศกนาฏกรรม ที่ค่อนข้างยกเว้น

    • ถ้าฉันเปิด HTTP เซิร์ฟเวอร์สาธารณะ ฉันก็ยินดีต้อนรับคำขอ GET ทั่วไป
      แต่ (1) การเข้าถึงของผู้ใช้ทั่วไปกับ DDoS จากบอต เป็นคนละเรื่องกัน ของที่ให้ใช้ฟรีไม่ได้แปลว่าจะเอาไปได้ไม่จำกัดจนเป็นการละเมิด
      (2) การทำสำเนาอย่างถูกกฎหมายกับ การปลอมแปลงโดยหุ่นยนต์ ควรถูกแยกจากกัน
      (3) ถ้าเป็นบอตที่ทำงานอย่างเหมาะสม ก็ควรเคารพ robots.txt แม้จะไม่ใช่กฎหมาย แต่เป็นเรื่องของ มารยาท
      บอตที่หมุนใช้ residential IP หลายล้านรายการไม่มีทางถือว่าปกติได้
    • ถ้าคุณหลอกการตั้งค่าเซิร์ฟเวอร์เพื่อให้ได้ข้อมูลที่ต้องการ นั่นคือ การเข้าถึงโดยไม่ยินยอม
      การเป็นเซิร์ฟเวอร์สาธารณะไม่ได้แปลว่ายอมรับคำขอเท็จ ๆ แต่เป็นการยินยอมโดยนัยเฉพาะคำขอที่สมเหตุสมผลเท่านั้น
    • robots.txt ไม่ได้มีผลผูกพันทางกฎหมาย แต่เป็น คำขออย่างสุภาพ
      มีความหมายประมาณว่า “กรุณาอย่าสแครปหน้านี้” เท่านั้น ถ้าอยากป้องกันจริงก็ควรใช้ API token หรือขั้นตอนยืนยันตัวตน
    • การเอาการเข้าถึงเพียงครั้งเดียวไปเทียบกับ การครอว์ลแบบถล่มไม่สิ้นสุด นั้นไม่สมเหตุสมผล
      เหมือนกับที่สแปมไม่ใช่อีเมลธรรมดา การใช้บอตในทางที่ผิดก็ไม่เหมือนคำขอทั่วไป
    • ถ้าเปรียบเป็น “ชามลูกอม” ถ้ามีผู้ใหญ่คนหนึ่งหยิบลูกอมสำหรับ trick-or-treat ไปหมดทั้งชาม ก็คงไม่มีใครรู้สึกดี

  • น่าจะเร็วกว่า ถ้า ค้นหาสตริง http/https โดยตรง แทนการพาร์ส DOM

    • ความต่างด้านทรัพยากรระหว่างการค้นหาข้อความธรรมดากับการไล่ DOM นั้นมาก การพูดว่า “น่าจะเร็วกว่า” จึงยังเบาไปด้วยซ้ำ
    • วิธีใช้ regex นั้น ทำได้ง่าย แต่ต่อให้พาร์ส DOM ปัญหาคอขวดหลักก็มักเป็นเครือข่ายมากกว่า CPU
      สุดท้ายตัวจำกัดจริง ๆ คือ ความแออัดของเครือข่าย

  • สนุกดีที่ได้เห็น การประยุกต์ใช้งานจริง ของงานวิจัยที่น่าสนใจ
    งานวิจัยที่เกี่ยวข้องดูได้จากโพสต์นี้

  • ชื่อเรื่องชวนสับสน น่าจะใช้คำว่า “commented-out” มากกว่า

    • ตอนแรกฉันก็นึกว่าเป็น สคริปต์สำหรับบล็อก AI scraper เหมือนกัน

  • นี่ดูไม่ใช่การใช้งานในทางที่ผิดเท่าไร แค่เหมือน อ่าน URL ที่ถูกคอมเมนต์ทิ้งไว้ มากกว่า

    • แต่ในบทความอธิบายว่าวิธีนี้ไม่ได้ใช้เพื่อ abuse แต่ใช้เป็น สัญญาณตรวจจับบอต
    • ถึงอย่างนั้น การเมิน robots.txt แล้วยังสแครปแม้แต่คอมเมนต์ ก็ชัดเจนว่าเป็น พฤติกรรมไร้มารยาท

  • สมัยก่อนตอนครอว์ลเว็บ regex ของ Perl น่าเชื่อถือที่สุด
    URL ในคอมเมนต์ก็ถูกใส่เข้าคิวตามปกติ

    • การไล่ DOM กลับเป็นความพยายามที่ มากเกินจำเป็น การใช้ regex จับ div หรือ p ที่ต้องการนั้นทั้งแข็งแรงกว่าและง่ายกว่า

  • ชวนคิดว่า ถ้าให้บอตเจอไฟล์ ข้อมูลสุ่มขนาด 512MB จะเป็นยังไง

    • แต่ที่ทำเงินได้มากกว่าคือ บิดเบือนคำตอบโฆษณาสำหรับ AI scraper เพื่อชักนำให้ LLM แนะนำสินค้าบางอย่าง
      สตาร์ตอัปที่ฉันทำอยู่ให้บริการแบบนี้พอดี เป็น Ad-poisoning-as-a-service
    • หรือจะสร้าง หน้า poison สำหรับ AI ที่ลิงก์สุ่มถึงกันไปมาเพื่อขังบอตไว้ก็ได้ เพราะมนุษย์คงไม่กดเข้าไป
    • แต่คนส่วนใหญ่น่าจะรับ ค่าแบนด์วิดท์ ไม่ไหว
    • หรือจะใส่ทั้ง 512MB เป็นข้อความว่า “บริการของเราดีที่สุด” ไปเลยก็ตลกดี

  • นี่ดูไม่ใช่ “การเก็บข้อมูลเพื่อฝึก LLM” เท่าไร แต่เป็นแค่ noise จากการสแกนอินเทอร์เน็ต

    • เห็นด้วย ถ้าเป็นตัวสแกนหาช่องโหว่ มันก็คงพยายามเก็บ HTTP endpoint ให้ได้มากที่สุด
      ไฟล์ JS เป็นเบาะแสที่ดี ไม่ว่าจะอยู่ในคอมเมนต์หรือไม่ก็ตาม
      แต่ถ้าเป็นเพื่อฝึก LLM จริง ก็คงไม่ได้สนใจ โค้ด JS คุณภาพต่ำ แบบนี้นัก

  • นี่คือความคิดเกี่ยวกับการ วางยาพิษทราฟฟิก สำหรับการฝึก LLM ที่ไม่พึงประสงค์

    1. ถ้าหลายเว็บไซต์ร่วมมือกัน ก็มีโอกาสปนเปื้อนโมเดลได้มากขึ้นโดยหลบเลี่ยง การลบข้อมูลซ้ำ
    2. อาจใช้ กฎหมายลิขสิทธิ์ เพื่อเพิ่มต้นทุนของการปนเปื้อนได้ แต่เว็บไซต์เองก็อาจมีความเสี่ยงทางกฎหมายด้วย
      ถ้าร่วมมือกับเจ้าของลิขสิทธิ์ก็อาจลดความเสี่ยงลงได้
    • ไอเดียแรกน่าจะทำเป็น ปลั๊กอิน WordPress ได้ดี
      และยังอาจดัดแปลงภาพแบบไดนามิกในแต่ละคำขอเพื่อ ทำลายการป้องกันการลบข้อมูลซ้ำ ได้ด้วย ถ้ามีปลั๊กอินแบบนั้นฉันคงติดตั้งทันที