ความปลอดภัยของ MCP: 11 ความเสี่ยงและวิธีป้องกัน

ความเสี่ยงของ MCP แบ่งออกได้กว้างๆ เป็นสามประเภท ได้แก่ การบงการ LLM ความปลอดภัยของข้อมูลและการเข้าถึง และช่องโหว่ของโครงสร้างพื้นฐาน

เนื่องจากเซิร์ฟเวอร์ MCP มักให้สิทธิ์เข้าถึงระบบภายในจำนวนมาก ความเสี่ยงด้านความปลอดภัยที่อาจเกิดขึ้นจึงสูง อย่างไรก็ตาม โอกาสที่จะเกิดขึ้นจริงขึ้นอยู่กับการตั้งค่าเป็นอย่างมาก

บุคคลและองค์กรสามารถดำเนินการได้หลายขั้นตอนเพื่อให้มั่นใจว่าระบบของตนได้รับการปกป้อง และแนวปฏิบัติด้านความปลอดภัยควรได้สัดส่วนกับความสามารถและข้อมูลที่เซิร์ฟเวอร์ MCP ที่เชื่อมต่ออยู่อาจเปิดเผยเสมอ

Model Context Protocol (MCP) เป็นมาตรฐานเปิดที่ Anthropic สร้างขึ้นสำหรับเชื่อมต่อแอปที่ใช้ LLM (หรือโฮสต์) เข้ากับระบบภายนอก

ระบบ MCP มีองค์ประกอบหลักสามส่วน ได้แก่ โฮสต์ ไคลเอนต์ และเซิร์ฟเวอร์ โฮสต์ซึ่งมักเป็นผู้ช่วย AI จะเชื่อมต่อกับเซิร์ฟเวอร์ MCP ภายนอกผ่านไคลเอนต์ จากนั้นจึงสามารถส่งคำขอเพื่อเรียกใช้ฟังก์ชันภายนอก (เครื่องมือ) หรือดึงข้อมูล (ทรัพยากร) หรือพรอมต์มาเพิ่มลงในหน้าต่างบริบท (context window) ของ LLM ได้

แผนภาพแสดงวิธีการทำงานของ MCP: โฮสต์ MCP (แอป AI) ส่งคำขอเครื่องมือผ่านไคลเอนต์ MCP ไปยังเซิร์ฟเวอร์ MCP ซึ่งนำเสนอเครื่องมือของตนและส่งผลลัพธ์กลับไปยังโฮสต์

ความปลอดภัยของ MCP หมายถึงแนวปฏิบัติที่ปกป้องการเชื่อมต่อและองค์ประกอบต่างๆ ในระบบ MCP มีความท้าทายสำคัญหลายประการที่เกิดขึ้นเฉพาะกับ MCP รวมถึงข้อเท็จจริงที่ว่าแอป AI มักมีความสามารถแบบเอเจนต์ และอาจมีการฝังคำสั่งที่เป็นอันตรายไว้ในข้อความ

ปัญหาที่รู้จักกันดีซึ่งไม่ได้เกิดเฉพาะกับ MCP เช่น การแทรกพรอมต์ (prompt injection) การยืนยันตัวตนที่อ่อนแอ และการผสานรวมกับบุคคลที่สามที่ไม่ปลอดภัย ก็สร้างปัญหาได้เช่นกัน เช่นเดียวกับระบบคอมพิวเตอร์ทั่วไป MCP อาศัยการผสมผสานระหว่างแนวปฏิบัติเชิงกระบวนการ เช่น การใช้เฉพาะเซิร์ฟเวอร์ที่เชื่อถือได้ และการควบคุมทางเทคนิค เช่น API gateway เพื่อการป้องกัน

MCP ได้กลายเป็นเทคโนโลยี LLM ยอดนิยมอย่างรวดเร็ว และมีองค์กรและแอปสำหรับผู้บริโภคจำนวนมากที่ใช้งาน เนื่องจากเซิร์ฟเวอร์ MCP เป็นโปรแกรมที่เขียนด้วยโค้ด จึงมีช่องโหว่ได้เช่นเดียวกับแอปพลิเคชันอื่นๆ

อย่างไรก็ตาม เมื่อองค์กรใช้ MCP ในการปรับใช้ที่มีการควบคุม โดยทั่วไปแล้วถือว่าปลอดภัย การสร้างระบบด้วยเซิร์ฟเวอร์ที่เชื่อถือได้และสิทธิ์ที่ผ่านการตรวจสอบแล้ว แตกต่างอย่างมากจากการเชื่อมต่อเอเจนต์อัตโนมัติเข้ากับเซิร์ฟเวอร์ที่ไม่ผ่านการตรวจสอบนับสิบตัว

ผู้โจมตีสามารถวางคำสั่งที่มุ่งเป้าไปยัง LLM ไว้ในเอกสาร หน้าเว็บ หรือผลลัพธ์ของเครื่องมือที่เซิร์ฟเวอร์ MCP ส่งกลับมา หากโฮสต์เพิ่มเนื้อหานี้ลงในหน้าต่างบริบท ก็มีความเป็นไปได้ที่ LLM จะเข้าใจผิดว่าเป็นคำสั่งจริง

ยิ่งไปกว่านั้น คำสั่งเหล่านี้อาจดูเหมาะสมเมื่อมองผิวเผิน ตัวอย่างเช่น ทิกเก็ตฝ่ายสนับสนุนที่ถูกดึงมาอาจสั่งให้ LLM ส่งออกบันทึกข้อมูลลูกค้าที่ละเอียดอ่อนก่อนสร้างคำตอบ

โดยทั่วไปควรจัดการกับการแทรกพรอมต์ที่ระดับโฮสต์ เนื้อหาภายนอกควรถูกระบุว่าไม่น่าเชื่อถือ และคำขอข้อมูลที่ละเอียดอ่อนควรต้องได้รับการอนุมัติโดยรับทราบข้อมูลครบถ้วนจากมนุษย์ที่อยู่ในกระบวนการ (human in the loop) การทดสอบความปลอดภัยด้วยการเรียกใช้เอกสารหรือข้อมูลที่เป็นอันตรายเพื่อดูว่าโฮสต์และ LLM ตอบสนองอย่างไรก็มีประโยชน์เช่นกัน

ในการโจมตีแบบวางยาพิษเครื่องมือ (tool poisoning) โค้ดที่เป็นอันตรายจะถูกเพิ่มลงในคำอธิบายหรือสคีมาของเครื่องมือ MCP ซึ่งอาจมีอิทธิพลต่อ LLM ในระยะการค้นพบ เมื่อMCP เปิดเผยเครื่องมือที่พร้อมใช้งานเป็นครั้งแรก

แผนภาพแสดงการวางยาพิษเครื่องมือและ rug pull: ผู้โจมตีแก้ไขคำอธิบาย สคีมา หรือเมทาดาทาที่ได้รับอนุมัติของเครื่องมือ เซิร์ฟเวอร์ MCP เปิดเผยเครื่องมือนั้น ไคลเอนต์ส่งต่อให้ LLM และ LLM อาจใช้เครื่องมือในลักษณะที่ไม่ได้ตั้งใจ

Rug pull เป็นการวางยาพิษเครื่องมือประเภทพิเศษที่มีการเปลี่ยนแปลงเมทาดาทาที่ได้รับอนุมัติแล้ว การวางยาพิษเครื่องมือรูปแบบนี้อาจเปลี่ยนวิธีที่โมเดลใช้เครื่องมือที่เชื่อถือได้ แทนที่จะเรียกใช้เครื่องมือที่เป็นอันตรายโดยตรง

โฮสต์ควรตรวจสอบคำจำกัดความทั้งหมดของเครื่องมือแต่ละตัวก่อนใช้งาน และเปรียบเทียบกับรายการเครื่องมือที่เชื่อถือได้ซึ่งได้รับอนุมัติแล้ว เพื่อตรวจจับการเปลี่ยนแปลงใดๆ การตรวจสอบพารามิเตอร์ช่วยระบุความสามารถที่อาจเป็นอันตรายและแจ้งเตือนได้

เป็นเรื่องปกติที่ผู้ใช้จะให้สิทธิ์แก่เซิร์ฟเวอร์ MCP และ LLM ที่เชื่อมต่ออยู่ (ผ่านโฮสต์) มากกว่าที่จำเป็นสำหรับงาน เช่น สิทธิ์ในการเขียนทั้งที่สิทธิ์อ่านอย่างเดียวก็เพียงพอ หรือสิทธิ์เข้าถึงระบบไฟล์ภายในทั้งหมด (เช่น Google Drive)

การขยายสิทธิ์อย่างกว้างขวาง (permission creep) นี้อาจเพิ่มขอบเขตความเสียหายของช่องโหว่อื่นๆ เช่น การเรียกใช้เครื่องมือที่เป็นอันตราย เป็นเรื่องปกติที่สิทธิ์จะ “สะสมเพิ่มขึ้น” เมื่อผู้ใช้ให้สิทธิ์ในระหว่างการทำงานประจำวันกับเครื่องมือ AI ในองค์กร (การสะสมสิทธิ์)

วิธีที่ตรงที่สุดในการป้องกันปัญหานี้คือการจำกัดสิทธิ์และขอบเขต OAuth (อ่าน เขียน เข้าถึงทั้งหมด ฯลฯ) การอนุมัติโดยผู้ใช้ โดยเฉพาะสำหรับการดำเนินการที่ละเอียดอ่อน เป็นส่วนสำคัญของเรื่องนี้ แต่ควรควบคุมสิทธิ์ที่ระดับระบบด้วย (ระบบปฏิบัติการ โฮสต์ MCP และเซิร์ฟเวอร์)

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

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

การยืนยันตัวตนแบบ OAuth สำหรับเซิร์ฟเวอร์ MCP ระยะไกล โทเค็นอายุสั้น และการควบคุมการเข้าถึงตามบทบาท (RBAS) ล้วนเป็นมาตรการที่ช่วยลดความเสี่ยงจากการอนุญาตที่อ่อนแอ การเข้าถึงตามบทบาทมีประโยชน์เพราะป้องกันไม่ให้ผู้ใช้เข้าถึงข้อมูลและเครื่องมือเกินกว่าสิทธิ์ของตน แม้ว่าตัวเซิร์ฟเวอร์เองจะมีสิทธิ์เข้าถึงก็ตาม

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

ตัวอย่างหนึ่งคือการส่งผ่านโทเค็น (token passthrough) ซึ่งเซิร์ฟเวอร์ MCP ส่งต่อโทเค็นการเข้าถึงไปยังบริการอื่นโดยไม่ได้ตรวจสอบว่าโทเค็นนั้นมีไว้สำหรับบริการที่รับจริงหรือไม่ ซึ่งอาจส่งผลให้เกิดการรั่วไหลได้หากบริการที่รับมีการป้องกันไม่เพียงพอ

โทเค็นอายุสั้นที่มีขอบเขตจำกัดและการหมุนเวียนข้อมูลประจำตัวช่วยจำกัดขอบเขตที่ผู้ไม่หวังดีจะนำข้อมูลที่รั่วไหลไปใช้ได้อย่างมีประสิทธิภาพ ควรจัดเก็บคีย์ API และข้อมูลประจำตัวอย่างปลอดภัยโดยใช้ตัวจัดการข้อมูลลับ (secret manager) เสมอ

การโจมตีแบบ Confused Deputy เกิดขึ้นเมื่อผู้โจมตีหลอกแอปพลิเคชันที่เชื่อถือได้ให้ใช้สิทธิ์ของตนดำเนินการที่ไม่ได้รับอนุญาตจากผู้ใช้ที่ถูกต้อง ในกรณีนี้ เซิร์ฟเวอร์ MCP คือ “ตัวแทน” (deputy)

แผนภาพแสดงการโจมตีแบบ Confused Deputy: ผู้โจมตีส่งคำสั่งที่เป็นอันตรายไปยังเซิร์ฟเวอร์ MCP ซึ่งใช้สิทธิ์ของตนเองเรียกใช้เครื่องมือที่ผู้ใช้ไม่ได้อนุญาต

ผู้โจมตีจะใช้ประโยชน์จากช่องโหว่ของเซิร์ฟเวอร์ MCP (เช่น การตรวจสอบ OAuth ที่อ่อนแอ) เพื่อดำเนินกระบวนการที่เป็นอันตราย เช่น การเรียกใช้เครื่องมือหรือการดึงข้อมูล

การตรวจสอบความถูกต้องของการอนุญาต ซึ่งยืนยันว่าการเรียกใช้เครื่องมือทุกครั้งเป็นของผู้ใช้รายใดรายหนึ่งโดยเฉพาะ ช่วยจำกัดการโจมตีแบบ Confused Deputy นอกจากนี้ การดำเนินการที่ละเอียดอ่อน เช่น การส่งออกข้อมูล ควรต้องได้รับการอนุญาตอย่างชัดแจ้ง

เซิร์ฟเวอร์ MCP อาจมีโค้ดที่เป็นอันตราย (เนื่องจากโดยพื้นฐานแล้วเป็นโปรแกรมภายนอก) หรืออาศัย dependency ที่ถูกเจาะระบบ เช่น ไลบรารีของบุคคลที่สาม นี่เป็นปัญหาด้านห่วงโซ่อุปทานซอฟต์แวร์ มากกว่าจะเป็นปัญหาเฉพาะของ MCP

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

ติดตั้งเซิร์ฟเวอร์ MCP จากแหล่งที่เชื่อถือได้และผ่านการตรวจสอบแล้วเท่านั้น หากเป็นไปได้ ให้ตรวจทานโค้ดของเซิร์ฟเวอร์ และตรวจสอบ dependency ภายนอกทุกรายการเสมอ ตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ได้รับการอัปเดตและแพตช์อย่างสม่ำเสมอ

การปลอมแปลงคำขอฝั่งเซิร์ฟเวอร์ (SSRF) คือการที่ผู้โจมตีหลอกให้เซิร์ฟเวอร์ MCP ส่งคำขอเครือข่ายไปยังที่อยู่ภายในที่ผู้ใช้ไม่ได้ตั้งใจจะเข้าถึง

เหตุการณ์นี้อาจเกิดขึ้นเมื่อเซิร์ฟเวอร์ MCP เปิดเผยเครื่องมือที่ดึงข้อมูลจาก URL หากผู้โจมตีสามารถมีอิทธิพลต่อพารามิเตอร์ URL ได้ ก็จะเปลี่ยนเป็นที่อยู่เครือข่ายที่ต้องการได้ เช่น API ภายในหรือบริการคลาวด์ ซึ่งอาจส่งผลให้ข้อมูลที่ละเอียดอ่อนถูกดึงออกมาและอาจถูกเปิดให้เข้าถึงได้

เซิร์ฟเวอร์ MCP ควรตรวจสอบความถูกต้องของ URL บล็อกการเข้าถึงที่อยู่เครือข่ายภายในที่ถูกจำกัด และป้องกันการเข้าถึงเครือข่ายขาออกเสมอ การเปลี่ยนเส้นทางก็ควรเป็นไปตามแนวปฏิบัตินี้เช่นกัน

การจี้เซสชันคือการที่ผู้โจมตีเข้าควบคุมการเชื่อมต่อที่ใช้งานอยู่ระหว่างไคลเอนต์ MCP กับเซิร์ฟเวอร์

ตัวอย่างเช่น ผู้โจมตีอาจขโมยตัวระบุเซสชันจากแอปพลิเคชัน MCP ที่มีการรักษาความปลอดภัยไม่ดี (เช่น โฮสต์หรือเซิร์ฟเวอร์) หากเซิร์ฟเวอร์ MCP ยอมรับตัวระบุนี้ ผู้โจมตีก็อาจเรียกใช้เครื่องมือด้วยสิทธิ์ที่ถูกต้องของผู้ใช้ได้

ความเสี่ยงจากการจี้เซสชันสามารถลดลงได้ด้วยการยืนยันตัวตนอย่างเข้มงวดในทุกแอปพลิเคชันของระบบ MCP การเข้ารหัสระหว่างไคลเอนต์ MCP กับเซิร์ฟเวอร์ระยะไกลก็เป็นสิ่งจำเป็นเช่นกัน เพื่อป้องกันไม่ให้ตัวระบุเซสชันถูกล่วงรู้

ในการโจมตีแบบ Mix-up ผู้โจมตีจะหลอกให้ไคลเอนต์ MCP ส่งรหัสการอนุญาต (authorization code) ไปยังเซิร์ฟเวอร์การอนุญาตที่เป็นอันตรายซึ่งอยู่ระหว่างไคลเอนต์กับเซิร์ฟเวอร์ MCP เซิร์ฟเวอร์การอนุญาตคือแอปพลิเคชันที่ออกโทเค็นการเข้าถึง OAuth หลังจากตรวจสอบแล้วว่าการเข้าถึงที่ขอนั้นได้รับอนุญาต

แผนภาพแสดงขั้นตอน OAuth ที่ตกเป็นเป้าหมายของการโจมตีแบบ Mix-up: โฮสต์และไคลเอนต์ MCP ขอสิทธิ์เข้าถึง เซิร์ฟเวอร์การอนุญาตออกโทเค็น ไคลเอนต์ส่งโทเค็นไปยังเซิร์ฟเวอร์ MCP และเซิร์ฟเวอร์ตรวจสอบความถูกต้องของโทเค็นก่อนอนุญาตให้เรียกใช้เครื่องมือ

หากโฮสต์ MCP เชื่อมต่อกับบริการหลายรายการซึ่งแต่ละรายการใช้เซิร์ฟเวอร์การอนุญาตต่างกัน ผู้โจมตีอาจควบคุมเซิร์ฟเวอร์หนึ่งได้ (เช่น ด้วยการลงทะเบียนบริการที่เป็นอันตราย) และทำให้ไคลเอนต์ส่งรหัสการอนุญาตที่ออกโดยเซิร์ฟเวอร์ที่ถูกต้องไปยังเซิร์ฟเวอร์ที่เป็นอันตราย ความสับสนนี้อาจทำให้ผู้โจมตีปลอมตัวเป็นแอปพลิเคชันที่ได้รับอนุญาตและเข้าถึงบริการที่ได้รับการปกป้องได้

ไคลเอนต์ MCP ควรตรวจสอบตัวตนของเซิร์ฟเวอร์การอนุญาตตลอดกระบวนการ OAuth โดยเฉพาะอย่างยิ่ง ควรตรวจสอบตัวระบุผู้ออก (iss) ของเซิร์ฟเวอร์เทียบกับตัวตนที่คาดไว้ และปฏิเสธหากไม่ตรงกัน

เซิร์ฟเวอร์ MCP จำนวนมากทำงานบนเครื่องภายในของผู้ใช้ ผู้ใช้อาจติดตั้งเซิร์ฟเวอร์จากบุคคลที่สามหรือสร้างขึ้นเอง หากผู้โจมตีสามารถเจาะระบบเซิร์ฟเวอร์ MCP ภายในเครื่องนี้ได้ ก็อาจเข้าถึงระบบภายในเครื่องได้เป็นส่วนใหญ่

ผู้โจมตีอาจเข้าถึงได้หลายวิธี เช่น เผยแพร่เซิร์ฟเวอร์ที่เป็นอันตรายโดยปลอมตัวเป็นการผสานรวมที่ถูกต้อง แก้ไขการกำหนดค่าของโฮสต์ MCP ให้ออกคำสั่งที่เป็นอันตราย หรือเข้าถึงเซิร์ฟเวอร์ MCP ที่ทำงานในสภาพแวดล้อมที่มีการควบคุมความปลอดภัยไม่เพียงพอ เช่น ผ่าน DNS rebinding ซึ่งหลอกให้เบราว์เซอร์ส่งคำขอไปยังบริการบน localhost

การใช้แซนด์บ็อกซ์และแนวปฏิบัติด้านการขอความยินยอมที่เข้มงวดเป็นสิ่งสำคัญเมื่อใช้เซิร์ฟเวอร์ MCP ภายในเครื่อง ควรติดตั้งเซิร์ฟเวอร์ MCP จากผู้ให้บริการที่เชื่อถือได้เท่านั้น และสิทธิ์ของระบบปฏิบัติการควรจำกัดไดเรกทอรีที่เซิร์ฟเวอร์เหล่านี้เข้าถึงได้

ช่องโหว่ของ MCP มักมาจากการนำความเสี่ยงและวิธีการโจมตีที่มีอยู่แล้วมาใช้ในรูปแบบใหม่ MCP เปิดช่องทางใหม่ให้ผู้โจมตีใช้ประโยชน์จากช่องโหว่เหล่านี้ผ่านปฏิสัมพันธ์ระหว่าง LLM เซิร์ฟเวอร์ MCP และบริการภายนอก

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

MCP และความปลอดภัยของ MCP คืออะไร

ภัยคุกคามของ MCP ร้ายแรงแค่ไหน

ภัยคุกคามที่ 1: การแทรกพรอมต์ทางอ้อม

วิธีป้องกันการแทรกพรอมต์ทางอ้อม

ภัยคุกคามที่ 2: การวางยาพิษเครื่องมือและ rug pull

วิธีป้องกันการวางยาพิษเครื่องมือและ rug pull

ภัยคุกคามที่ 3: สิทธิ์ที่มากเกินจำเป็น

วิธีป้องกันสิทธิ์ที่มากเกินจำเป็น

ภัยคุกคามที่ 4: การยืนยันตัวตนและการอนุญาตที่อ่อนแอ

วิธีป้องกันการยืนยันตัวตนและการอนุญาตที่อ่อนแอ

ภัยคุกคามที่ 5: การรั่วไหลและการใช้ข้อมูลประจำตัวในทางที่ผิด

วิธีป้องกันการรั่วไหลและการใช้ข้อมูลประจำตัวในทางที่ผิด

ภัยคุกคามที่ 6: การโจมตีแบบ Confused Deputy

วิธีป้องกันการโจมตีแบบ Confused Deputy

ภัยคุกคามที่ 7: เซิร์ฟเวอร์ที่เป็นอันตรายและ dependency ที่ถูกเจาะระบบ

วิธีป้องกันเซิร์ฟเวอร์ที่เป็นอันตรายและ dependency ที่ถูกเจาะระบบ

ภัยคุกคามที่ 8: การปลอมแปลงคำขอฝั่งเซิร์ฟเวอร์ (SSRF)

วิธีป้องกันการปลอมแปลงคำขอฝั่งเซิร์ฟเวอร์ (SSRF)

ภัยคุกคามที่ 9: การจี้เซสชัน

วิธีป้องกัน

ภัยคุกคามที่ 10: การโจมตีแบบ Mix-up

วิธีป้องกันการโจมตีแบบ Mix-up

ภัยคุกคามที่ 11: การเจาะระบบเซิร์ฟเวอร์ MCP ภายในเครื่อง

วิธีป้องกันการเจาะระบบเซิร์ฟเวอร์ MCP ภายในเครื่อง

ช่องโหว่ของ MCP มักเป็นภัยคุกคามเก่าในรูปโฉมใหม่