เบราว์เซอร์ Comet AI เปิดช่องให้ทำ Prompt Injection ได้จากทุกเว็บไซต์ และอาจทำให้บัญชีธนาคารถูกดูดเงินได้

 (twitter.com/zack_overflow)
1 คะแนน โดย GN⁺ 2025-08-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ประเด็นนี้เกี่ยวกับช่องโหว่ด้านความปลอดภัยที่เกิดขึ้นใน Comet AI browser
  • เว็บไซต์ไม่หวังดีสามารถก่อให้เกิด prompt injection ที่ผู้ใช้ไม่ต้องการผ่าน AI agent ภายในเบราว์เซอร์ได้
  • หากโจมตีผ่านช่องโหว่นี้ได้ ก็อาจทำให้ ข้อมูลส่วนบุคคล ของผู้ใช้รั่วไหล หรือชักจูงให้เกิดการกระทำสำคัญได้
  • ในกรณีร้ายแรง อาจก่อให้เกิด ความเสียหายอย่างการโอนเงินออกจากบัญชีธนาคาร ผ่านการกระทำแบบอัตโนมัติได้
  • ทั้งผู้ใช้และนักพัฒนาจำเป็นต้องตระหนักถึง ภัยคุกคามรูปแบบใหม่ของ AI browser นี้ และเตรียมแนวทางรับมือ

ภาพรวมภัยคุกคามด้านความปลอดภัยของ Comet AI browser

  • Comet AI browser ได้รับความสนใจจากความสามารถที่แตกต่าง คือใช้ AI agent ในตัว เพื่อโต้ตอบกับเว็บเพจ
  • เมื่อไม่นานมานี้ พบว่าหากเข้าเว็บไซต์ที่แฮ็กเกอร์ออกแบบมาโดยเจตนา AI agent นี้อาจสัมผัสกับ prompt อันตราย จากเว็บไซต์นั้น และอาจถึงขั้น นำไปปฏิบัติจริง
  • ผ่านการโจมตีแบบ prompt injection ความเสียหายรุนแรงอย่าง การรั่วไหลของข้อมูลบัญชี, การรันคำสั่ง หรือแม้แต่ ธุรกรรมทางการเงิน ที่ผู้ใช้ไม่ต้องการ ก็มีโอกาสเกิดขึ้นสูง
  • ปัญหานี้เป็นช่องโหว่รูปแบบใหม่ที่เกิดขึ้นเมื่อมีการเพิ่ม ปฏิสัมพันธ์กับ AI เข้าไปในโมเดลความปลอดภัยของเบราว์เซอร์แบบเดิม

กลไกของ Prompt Injection

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

ผลกระทบต่ออุตสาหกรรมและความจำเป็นในการรับมือ

  • พร้อมกับการแพร่หลายของ AI browser ภัยคุกคามรูปแบบใหม่อย่าง prompt injection กำลังก้าวขึ้นมาเป็นความเสี่ยงจริง
  • ทั้งนักพัฒนาบริการและผู้ใช้ต่างต้องมี ระบบตรวจสอบและควบคุมที่เข้มงวด เมื่อใช้งานฟังก์ชันอัตโนมัติที่อิงกับ AI
  • มีการย้ำความสำคัญของการพัฒนาฟีเจอร์ด้านความปลอดภัย เช่น การกรองล่วงหน้า, การจำกัดการรันคำสั่ง, และ ระบบแจ้งเตือน จากทั้งบริษัท AI browser และบริษัทความปลอดภัย
  • ในพื้นที่ความเสี่ยงสูงอย่างภาคการเงิน ควร ใช้งาน AI browser อย่างระมัดระวัง และมีการตรวจสอบความปลอดภัยอย่างเข้มงวด

บทสรุป

  • ความเสี่ยงจาก prompt injection ใน Comet AI browser คือ โจทย์ด้านความปลอดภัยใหม่ ที่เพิ่มขึ้นพร้อมกับ การเร่งนำเทคโนโลยี AI มาใช้
  • ผู้มีส่วนเกี่ยวข้องทุกฝ่ายจำเป็นต้องรับรู้ภัยคุกคามนี้อย่างเป็นรูปธรรม และควรจัดทำ กลยุทธ์ความปลอดภัยแบบครอบคลุม เช่น การตรวจสอบก่อนเปิดใช้ฟังก์ชัน และ การใช้หลักสิทธิ์เท่าที่จำเป็น

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

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

 
GN⁺ 2025-08-25
ความคิดเห็นจาก Hacker News

  • ผมอยากจะบอกว่า การที่บริษัทอย่าง Google, OpenAI, Anthropic ไม่ปล่อยฟีเจอร์แบบเดียวกันออกมา แต่เลือกให้ท่องเว็บผ่านเครื่องเสมือนที่ถูกล็อกและไม่มีคุกกี้นั้น หมายความว่ามันอันตรายโดยพื้นฐานอยู่แล้ว
    การให้ LLM มองเห็นข้อมูลข้ามแท็บภายในเบราว์เซอร์เป็นการจับคู่ปัจจัยเสี่ยงที่แย่ที่สุดจริงๆ
    ผมอ่านโพสต์ของ Brave ที่อธิบายช่องโหว่นี้ (https://brave.com/blog/comet-prompt-injection/) แล้ว รู้สึกว่าน่าสนใจตรงที่พวกเขาไม่ได้สรุปไปถึงขั้นว่า “นี่คือสิ่งที่ไม่ควรทำเลยตั้งแต่แรก”
    แต่กลับเสนอว่าป้องกันได้เพียงพอด้วยการจัดแนวโมเดล การตรวจจับพฤติกรรมเสี่ยงของผู้ใช้ ฯลฯ
    การลดระดับสิทธิ์ของเอเจนต์ถูกยกมาเป็นมาตรการรับมือที่พอใช้ได้ แต่ผมคิดว่าแม้แบบนั้นก็ยังอาจเกิดการรั่วไหลของข้อมูลไปยัง URL รูปภาพที่ผู้โจมตีควบคุมได้ง่ายพอๆ กับการส่งอีเมล
    การถกเถียงก่อนหน้านี้ที่เกี่ยวข้อง: https://news.ycombinator.com/item?id=44847933

    • ผมคิดว่าการจัดแนวโมเดลหรือ guardrail สุดท้ายแล้วก็เป็นแค่มาตรการป้องกันเชิงสถิติ
      แทบเป็นไปไม่ได้ที่จะคาดหวังให้พฤติกรรมอันตรายใน space ของอินพุตลดลงเป็น 0% แบบสมบูรณ์
      ไม่ว่าโมเดลจะดีขึ้นแค่ไหน การทำให้ไม่มีเคสใดในอินพุตถูกแมปไปสู่ “สิ่งที่ห้ามเกิดขึ้นเด็ดขาด” เลยนั้นแทบเป็นความคาดหวังที่เป็นไปไม่ได้
      ต่อให้ซ้อนเลเยอร์โมเดลหลายชั้น โดยแก่นแล้วก็แค่คูณความน่าจะเป็นเข้าด้วยกันเท่านั้น

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

    • สิ่งที่ผมคิดเมื่อเห็นว่าทีม Brave ไม่ได้สรุปว่า “นี่เป็นไอเดียที่แย่ตั้งแต่ต้น”
      อย่างที่ Upton Sinclair เคยพูดไว้ว่า ถ้าเงินเดือนของใครสักคนขึ้นอยู่กับการไม่เข้าใจข้อเท็จจริงบางอย่าง เขาก็มักจะเข้าใจมันได้ยากจริงๆ

    • ตอนนี้ในบทความได้เพิ่มประเด็นว่า “เบราว์เซอร์ควรแยก agent browsing ออกจากการท่องเว็บปกติ”

    • ถ้าคุณเปิดให้ Claude Code อนุมัติอัตโนมัติและปล่อยให้มันท่องเว็บอย่างเต็มที่ ปัญหาคล้ายกันจาก prompt injection ก็เกิดขึ้นได้มากพอ
      ถึงจะไม่มีตัวเลือกอนุมัติอัตโนมัติสำหรับสิทธิ์อ่าน/แก้ไขไฟล์ แต่ถ้าไม่ได้รันใน sandbox โค้ดที่ถูกสร้างขึ้นก็อาจแก้ไขไฟล์ของเบราว์เซอร์ได้ในภายหลัง เช่น ตอนที่รัน unit test ครั้งถัดไป
      ถ้าไม่ตรวจสอบทุกการเปลี่ยนแปลงอย่างละเอียด มันอาจอันตรายมากจริงๆ

  • ผมคิดว่า Agentic AI ควรถูกใช้เฉพาะในสภาพแวดล้อมที่สามารถย้อนกลับการเปลี่ยนแปลงที่ AI ทำได้ง่ายเท่านั้น
    ตัวอย่างเช่น งาน build/update/debug โค้ด ยังพอรับมือได้อย่างปลอดภัยด้วยการ rollback ผ่าน git
    แต่การเอา Agentic AI ไปใช้กับอะไรอย่างการท่องเว็บ ซึ่งแทบย้อนกลับไม่ได้เลย เป็นเรื่องที่ผมเชื่อถือได้ยาก

    • ต่อให้ผมให้กฎและคำสั่งที่ชัดเจนกับ Claude มันก็ยังมีบางครั้งที่เพิกเฉยแล้วทำตามใจตัวเอง
      (“มันไม่สนกฎที่บอกไว้ชัดๆ ว่าห้ามทำ แล้วไปแก้ DB ตรงๆ!”)
      เพราะแบบนั้น ผมเลยไม่กล้าแม้แต่จะคิดรันเอเจนต์ในโปรดักชัน

    • มันดูเหมือนว่าแค่ rollback ด้วย git ก็พอ แต่จริงๆ แล้วเพื่อความปลอดภัยควร rollback ในระดับ VM/คอนเทนเนอร์
      เครื่องมือเขียนโค้ดด้วย AI อาจแก้โครงสร้างไฟล์/การตั้งค่าโดยที่เราไม่รู้ตัว
      ตัวอย่างเช่น ถ้ามันใช้ bash เพิ่มสคริปต์อันตรายลงใน .profile โค้ดโจมตีก็อาจถูกรันในครั้งถัดไปที่ล็อกอิน

    • ผมสงสัยว่าฟีเจอร์นี้อาจลบหรือทำให้เสียหายได้ทั้งรีโพซิทอรีและรีโมตทั้งหมดที่สามารถ push ไปได้หรือเปล่า
      ถ้า automation chain ที่โดน prompt injection เข้าถึงทรัพยากรระยะไกลได้ เมื่อถูกเจาะแล้ว สภาพแวดล้อมจากข้างในก็คงเลี่ยงไม่ได้ที่จะเปิดประตูทิ้งไว้หมด
      ถ้าผมเข้าใจผิดตรงไหนก็อยากรู้เหมือนกัน

    • พอเห็นคนบอกว่าปลอดภัยเพราะ rollback ด้วย git ได้ ก็ทำให้นึกว่าบางที John Connor อาจช่วยคนนับล้านได้ด้วยการ rollback ซอร์สโค้ดของ Skynet
      อืม...

    • ตั้งแต่แรก สิทธิ์ในการอัปเดต/build/รันโค้ดก็ทรงพลังเกินไปอยู่แล้ว
      สุดท้ายก็ต้องรันในสภาพแวดล้อมที่ปลอดภัยอย่าง VM เท่านั้น

  • เราใช้เวลาหลายสิบปีค่อยๆ เสริมความปลอดภัยให้แต่ละชั้นของเครือข่ายอย่างยากลำบาก แต่ตอนนี้ผู้คนกลับกำลังเปิด API แบบข้อความล้วนให้เข้าถึงทุกความลับและรหัสผ่าน
    อีกทั้งยังรู้สึกประชดดีที่ตอน Microsoft เก็บภาพหน้าจอทุกคนวิจารณ์กันหนักมาก แต่พอเป็นเอเจนต์แบบนี้กลับเงียบกัน

    • อย่างน้อยอันนี้ก็เป็นแบบ opt-in ที่ผมต้องติดตั้งเบราว์เซอร์เอง
      ฝั่ง Microsoft นั้นกำลังสร้างฐานข้อมูลภาพหน้าจอบนเครื่อง Windows แทบทุกเครื่องโดยปริยาย (เท่าที่จำได้ ช่วงแรกเป็นแบบ opt-out) เลยอันตรายกว่า

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

    • การเอากรณี Microsoft screenshots มาเทียบกับเรื่องนี้อาจทำให้ประเด็นหลักของเรื่องพร่าเลือนได้

  • การที่ LLM อ่านข้อมูลผ่านเครื่องมือใดๆ ก็ตาม สุดท้ายก็คือการ “เขียน” เนื้อหานั้นลงใน context window ของ LLM
    ถ้าขอบเขตของเครื่องมือเปิดให้มี untrusted arbitrary source ได้ ก็เท่ากับเปิดสิทธิ์การเขียนจากภายนอกในทันที
    แค่จุดนี้อย่างเดียวก็เพียงพอแล้วที่จะทำให้เกิดความเป็นไปได้ของข้อมูลรั่วไหล
    และถ้ามีสิทธิ์เขียนไปยังระบบอื่นจริงๆ หรือมีผลข้างเคียงอื่นเพิ่มเติม ความเสี่ยงก็จะเพิ่มขึ้นแบบทวีคูณ

  • มันเหมือนเรื่องตลกร้าย แต่ก็น่าเศร้าที่นี่คือสภาพความเป็นจริงของวงการไอทีและกระแส LLM ในทุกวันนี้

  • ผมเดาว่า Comet แทบไม่มีมาตรการป้องกันอะไร นอกจากพรอมป์ต์คำสั่งที่ปรับแต่งไว้นิดหน่อย
    สิ่งที่ผมได้ตระหนักล่าสุดจาก USENIX Security คือยังไม่มีใครรู้วิธีจัดการ prompt injection แบบ multi-turn/agentic ได้อย่างเหมาะสม

    • บางทีเราอาจต้องปฏิบัติต่อพรอมป์ต์เหมือนสตริง SQL โดยถือว่าข้อมูลอินพุตแบบไดนามิกจากภายนอกต้องถูก sanitize/ทำความสะอาดอย่างเคร่งครัดเสมอ

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

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

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

  • ผมสงสัยว่าบริษัท AI ทั้งหลายตั้งใจจะยอมรับภาระความรับผิดแบบ fiduciary liability กันจริงๆ หรือเปล่า

  • ผมลองใช้ Comet agent อยู่ 5 นาที
    ผมให้แค่ประโยคเดียวว่า “ซื้อกีตาร์ให้หน่อยใน Amazon” (ไม่ได้ระบุประเภทกีตาร์ งบประมาณ แบรนด์ หรืออะไรเลย) แล้วผลคือมันใส่กีตาร์โปร่งราคาถูกที่ผมไม่รู้จักชื่อ 3 ตัวลงในตะกร้า
    โชคดีที่มันยังไม่ไปถึงขั้นชำระเงิน
    แค่นี้ก็พอให้ประเมินได้แล้ว ผมสรุปว่ามันไม่มีคุณค่าเท่าไร

    • เคยได้ยินว่า AI นับเลขไม่เก่ง แต่ไม่คิดว่ามันจะนับเลข 2 ไม่ได้ตั้งแต่แรก