Bảo vệ hệ thống MCP của bạn: 11 rủi ro phổ biến và cách phòng chống

Rủi ro MCP nhìn chung được chia thành ba loại: thao túng LLM, bảo mật dữ liệu và quyền truy cập, và lỗ hổng cơ sở hạ tầng.

Vì máy chủ MCP thường cấp quyền truy cập vào nhiều hệ thống nội bộ, rủi ro bảo mật tiềm ẩn là rất cao. Tuy nhiên, khả năng xảy ra phụ thuộc rất nhiều vào cách thiết lập.

Cá nhân và doanh nghiệp có thể thực hiện nhiều bước để đảm bảo hệ thống của mình được bảo vệ, và các quy trình bảo mật luôn cần tương xứng với những khả năng và dữ liệu mà các máy chủ MCP được kết nối có thể làm lộ.

MCP và bảo mật MCP là gì?

Model Context Protocol (MCP) là một tiêu chuẩn mở do Anthropic tạo ra để kết nối các ứng dụng dựa trên LLM (hay ứng dụng chủ) với các hệ thống bên ngoài.

Một hệ thống MCP có ba thành phần cốt lõi: ứng dụng chủ, máy khách và máy chủ. Ứng dụng chủ, thường là một trợ lý AI, kết nối với máy chủ MCP bên ngoài thông qua máy khách. Sau đó, ứng dụng chủ có thể gửi yêu cầu để chạy chức năng bên ngoài (công cụ), truy xuất dữ liệu (tài nguyên) hoặc lời nhắc để thêm vào cửa sổ ngữ cảnh của LLM.

Phóng to

Bảo mật MCP là các quy trình bảo vệ những kết nối và thành phần trong một hệ thống MCP. Có một số thách thức chính chỉ riêng MCP mới có, bao gồm việc các ứng dụng AI thường có khả năng hoạt động như tác nhân và các chỉ dẫn độc hại có thể được nhúng vào tin nhắn.

Các vấn đề đã biết không chỉ riêng MCP mới có, chẳng hạn như chèn lời nhắc, xác thực yếu và tích hợp bên thứ ba không an toàn, cũng gây ra rắc rối. Như mọi hệ thống máy tính, MCP dựa vào sự kết hợp giữa các quy trình thủ tục, như chỉ sử dụng máy chủ đáng tin cậy, và các biện pháp kiểm soát kỹ thuật, như cổng API, để đảm bảo an toàn.

Các mối đe dọa MCP nghiêm trọng đến mức nào?

MCP đã nhanh chóng trở thành một công nghệ LLM phổ biến và được nhiều tổ chức cũng như ứng dụng dành cho người tiêu dùng sử dụng. Vì máy chủ MCP là các chương trình được viết bằng mã, chúng cũng có lỗ hổng như bất kỳ ứng dụng nào khác.

Tuy nhiên, khi các tổ chức sử dụng MCP trong các môi trường triển khai được kiểm soát, MCP nhìn chung an toàn. Có một khoảng cách rất lớn giữa việc xây dựng một hệ thống với các máy chủ đáng tin cậy và quyền đã được xác minh, so với việc kết nối một tác nhân tự hành với hàng chục máy chủ chưa được thẩm định.

Mối đe dọa số 1: Chèn lời nhắc gián tiếp

Kẻ tấn công có thể đặt các chỉ dẫn nhắm vào LLM bên trong một tài liệu, trang web hoặc đầu ra công cụ mà máy chủ MCP trả về. Nếu ứng dụng chủ đưa nội dung này vào cửa sổ ngữ cảnh, LLM có thể nhầm đó là chỉ dẫn thật.

Hơn nữa, bề ngoài những chỉ dẫn này có thể trông hoàn toàn hợp lý. Ví dụ: một phiếu hỗ trợ được truy xuất có thể yêu cầu LLM xuất các hồ sơ khách hàng nhạy cảm trước khi tạo câu trả lời.

Cách phòng chống chèn lời nhắc gián tiếp

Chèn lời nhắc thường nên được xử lý ở cấp ứng dụng chủ. Nội dung bên ngoài cần được gắn nhãn là không đáng tin cậy, và các yêu cầu liên quan đến thông tin nhạy cảm cần có sự phê duyệt có hiểu biết từ con người tham gia giám sát. Kiểm thử bảo mật bằng cách gọi các tài liệu hoặc dữ liệu độc hại để xem ứng dụng chủ và LLM phản ứng thế nào cũng có thể hữu ích.

Mối đe dọa số 2: Đầu độc công cụ và rug pull

Trong một cuộc tấn công đầu độc công cụ, mã độc được thêm vào phần mô tả hoặc lược đồ của một công cụ MCP. Điều này có thể tác động đến LLM trong giai đoạn khám phá, khi MCP lần đầu cung cấp các công cụ hiện có.

Phóng to

Rug pull là một dạng đầu độc công cụ đặc biệt, trong đó siêu dữ liệu đã được phê duyệt bị thay đổi. Hình thức đầu độc công cụ này có thể thay đổi cách mô hình sử dụng các công cụ đáng tin cậy, thay vì trực tiếp gọi một công cụ độc hại.

Cách phòng chống đầu độc công cụ và rug pull

Ứng dụng chủ nên kiểm tra toàn bộ định nghĩa của từng công cụ trước khi sử dụng và đối chiếu với danh sách các công cụ đáng tin cậy đã được phê duyệt, nhờ đó phát hiện mọi thay đổi. Việc kiểm tra tham số có thể giúp xác định và gắn cờ những khả năng tiềm ẩn nguy hiểm.

Mối đe dọa số 3: Cấp quyền quá mức

Người dùng thường cấp cho máy chủ MCP và các LLM được kết nối (thông qua ứng dụng chủ) nhiều quyền hơn mức cần thiết cho một tác vụ. Ví dụ: cấp quyền ghi trong khi chỉ cần quyền đọc là đủ, hoặc cấp toàn quyền truy cập vào một hệ thống tệp nội bộ (chẳng hạn như Google Drive).

Tình trạng quyền hạn bị mở rộng dần quá mức này có thể làm tăng phạm vi ảnh hưởng của các lỗ hổng khác, chẳng hạn như lệnh gọi công cụ độc hại. Quyền hạn thường “cộng dồn” khi người dùng cấp đặc quyền trong quá trình làm việc hằng ngày với các công cụ AI tại doanh nghiệp (tích lũy đặc quyền).

Cách phòng chống cấp quyền quá mức

Cách trực tiếp nhất để phòng chống vấn đề này là hạn chế quyền và phạm vi OAuth (đọc, ghi, toàn quyền truy cập, v.v.). Sự phê duyệt của người dùng, đặc biệt với các thao tác nhạy cảm, là một phần quan trọng, nhưng quyền cũng cần được kiểm soát ở cấp hệ thống (hệ điều hành, ứng dụng chủ MCP và máy chủ).

Mối đe dọa số 4: Xác thực và phân quyền yếu

Xác thực là việc xác minh danh tính của người dùng hoặc ứng dụng kết nối với máy chủ MCP. Phân quyền quy định những công cụ và tài nguyên mà họ có thể truy cập.

Máy chủ MCP được cấu hình kém có thể chấp nhận yêu cầu hoặc token mà không xác thực đúng người dùng hay thực thi các giới hạn truy cập. Ngoài ra, nếu cơ chế xác minh yếu, thông tin xác thực bị đánh cắp có thể giúp kẻ xấu giành quyền truy cập.

Cách phòng chống xác thực và phân quyền yếu

Xác thực dựa trên OAuth cho máy chủ MCP từ xa, token ngắn hạn và kiểm soát truy cập dựa trên vai trò (RBAS) đều là những biện pháp giúp giảm thiểu rủi ro từ phân quyền yếu. Truy cập dựa trên vai trò hữu ích vì nó ngăn người dùng truy cập dữ liệu và công cụ vượt quá quyền hạn của họ, ngay cả khi bản thân máy chủ có quyền truy cập.

Mối đe dọa số 5: Rò rỉ và lạm dụng thông tin xác thực

Máy chủ MCP thường xuyên sử dụng thông tin xác thực như khóa API và token truy cập OAuth để kết nối với các dịch vụ bên ngoài. Nếu những thông tin này bị lộ hoặc bị lạm dụng, kẻ tấn công có thể truy cập dữ liệu và chức năng nhạy cảm.

Một ví dụ là chuyển tiếp token (token passthrough), trong đó máy chủ MCP chuyển tiếp token truy cập đến một dịch vụ khác mà không xác minh rằng token đó thực sự dành cho dịch vụ nhận. Điều này có thể dẫn đến rò rỉ nếu dịch vụ nhận không có biện pháp bảo vệ đầy đủ.

Cách phòng chống rò rỉ và lạm dụng thông tin xác thực

Token ngắn hạn, có phạm vi hẹp và việc xoay vòng thông tin xác thực giúp hạn chế hiệu quả mức độ mà kẻ xấu có thể sử dụng dữ liệu bị rò rỉ. Khóa API và thông tin xác thực luôn phải được lưu trữ an toàn bằng trình quản lý bí mật.

Mối đe dọa số 6: Tấn công confused deputy

Tấn công confused deputy (“người được ủy quyền bị lừa”) xảy ra khi kẻ tấn công lừa một ứng dụng đáng tin cậy sử dụng quyền của nó để thực hiện một hành động mà người dùng hợp pháp không cho phép. Trong trường hợp này, máy chủ MCP chính là “người được ủy quyền” (deputy).

Phóng to

Kẻ tấn công sẽ khai thác một lỗ hổng của máy chủ MCP (chẳng hạn như cơ chế xác minh OAuth yếu) để thực thi một tiến trình độc hại, như lệnh gọi công cụ hoặc truy xuất dữ liệu.

Cách phòng chống tấn công confused deputy

Kiểm tra phân quyền, trong đó mọi lệnh gọi công cụ đều được xác minh là thuộc về một người dùng cụ thể, giúp hạn chế tấn công confused deputy. Ngoài ra, các hành động nhạy cảm như xuất dữ liệu cần có sự cho phép rõ ràng.

Mối đe dọa số 7: Máy chủ độc hại và phần phụ thuộc bị xâm phạm

Máy chủ MCP có thể chứa mã độc (về bản chất, chúng là các chương trình bên ngoài) hoặc dựa vào các phần phụ thuộc bị xâm phạm, chẳng hạn như thư viện của bên thứ ba. Đây là vấn đề của chuỗi cung ứng phần mềm, chứ không phải vấn đề riêng của MCP.

Một cách đơn giản để điều này xảy ra là khi kẻ tấn công phân phối một tích hợp trông có vẻ hợp pháp. Sau khi được thiết lập, tích hợp đó có thể đánh cắp và tái sử dụng thông tin xác thực, truy cập dữ liệu nhạy cảm và thực thi các thao tác trái phép.

Cách phòng chống máy chủ độc hại và phần phụ thuộc bị xâm phạm

Chỉ cài đặt máy chủ MCP từ các nguồn đáng tin cậy và đã được thẩm định. Nếu có thể, hãy xem xét mã nguồn của chúng và luôn kiểm tra mọi phần phụ thuộc bên ngoài. Đảm bảo máy chủ được cập nhật và vá lỗi thường xuyên.

Mối đe dọa số 8: Giả mạo yêu cầu phía máy chủ (SSRF)

Giả mạo yêu cầu phía máy chủ (SSRF) là khi kẻ tấn công lừa máy chủ MCP gửi các yêu cầu mạng đến những địa chỉ nội bộ mà người dùng không có ý định truy cập.

Điều này có thể xảy ra khi máy chủ MCP cung cấp một công cụ truy xuất thông tin từ URL. Nếu kẻ tấn công có thể tác động đến tham số URL, chúng có thể đổi tham số này thành địa chỉ mạng mà chúng muốn, chẳng hạn như một API nội bộ hoặc dịch vụ đám mây. Điều này có thể dẫn đến việc dữ liệu nhạy cảm bị truy xuất và có khả năng bị lộ ra ngoài

Cách phòng chống giả mạo yêu cầu phía máy chủ (SSRF)

Máy chủ MCP luôn phải kiểm tra tính hợp lệ của URL, chặn truy cập vào các địa chỉ mạng nội bộ bị hạn chế và ngăn truy cập mạng ra bên ngoài. Các lệnh chuyển hướng cũng phải tuân theo quy tắc này.

Mối đe dọa số 9: Chiếm quyền điều khiển phiên

Chiếm quyền điều khiển phiên là khi kẻ tấn công giành quyền kiểm soát một kết nối đang hoạt động giữa máy khách MCP và máy chủ.

Ví dụ: kẻ tấn công có thể đánh cắp mã định danh phiên từ một ứng dụng MCP được bảo mật kém (như ứng dụng chủ hoặc máy chủ). Nếu máy chủ MCP chấp nhận mã định danh này, kẻ tấn công có thể gọi các công cụ bằng quyền hợp pháp của người dùng.

Cách phòng chống

Có thể giảm rủi ro chiếm quyền điều khiển phiên bằng cách xác minh danh tính nghiêm ngặt trên tất cả các ứng dụng trong hệ thống MCP. Mã hóa giữa máy khách MCP và máy chủ từ xa cũng rất cần thiết để ngăn mã định danh phiên bị phát hiện.

Mối đe dọa số 10: Tấn công mix-up

Trong một cuộc tấn công mix-up, kẻ tấn công lừa máy khách MCP gửi mã ủy quyền đến một máy chủ ủy quyền độc hại nằm giữa máy khách và máy chủ MCP. Máy chủ ủy quyền là ứng dụng cấp token truy cập OAuth sau khi kiểm tra rằng quyền truy cập được yêu cầu đã được cho phép.

Phóng to

Nếu một ứng dụng chủ MCP kết nối với nhiều dịch vụ, mỗi dịch vụ dùng một máy chủ ủy quyền khác nhau, kẻ tấn công có thể kiểm soát một trong số đó (chẳng hạn bằng cách đăng ký một dịch vụ độc hại) và khiến máy khách gửi mã ủy quyền do một máy chủ hợp pháp cấp đến máy chủ độc hại. Sự nhầm lẫn này có thể cho phép kẻ tấn công mạo danh ứng dụng được ủy quyền và truy cập vào các dịch vụ được bảo vệ.

Cách phòng chống tấn công mix-up

Máy khách MCP nên xác minh danh tính của máy chủ ủy quyền trong suốt quy trình OAuth. Cụ thể, máy khách cần đối chiếu mã định danh bên phát hành (iss) của máy chủ với danh tính dự kiến và từ chối nếu không khớp.

Mối đe dọa số 11: Máy chủ MCP cục bộ bị xâm phạm

Nhiều máy chủ MCP chạy trên máy cục bộ của người dùng. Người dùng có thể cài đặt máy chủ từ bên thứ ba hoặc tự xây dựng. Nếu kẻ tấn công có thể xâm phạm máy chủ MCP cục bộ này, chúng có thể truy cập vào phần lớn hệ thống cục bộ.

Kẻ tấn công có thể giành quyền truy cập theo nhiều cách. Chúng có thể phân phối một máy chủ độc hại được ngụy trang thành tích hợp hợp pháp, sửa đổi cấu hình của ứng dụng chủ MCP để nó đưa ra một lệnh độc hại, hoặc truy cập một máy chủ MCP đang chạy trong môi trường thiếu các biện pháp kiểm soát bảo mật, chẳng hạn như thông qua DNS rebinding, một kỹ thuật lừa trình duyệt gửi yêu cầu đến một dịch vụ localhost.

Cách phòng chống máy chủ MCP cục bộ bị xâm phạm

Cơ chế Sandbox và các quy trình xin sự đồng ý nghiêm ngặt rất quan trọng khi sử dụng máy chủ MCP cục bộ. Chỉ nên cài đặt máy chủ MCP từ các nhà cung cấp đáng tin cậy, và quyền của hệ điều hành cần giới hạn những thư mục mà máy chủ có thể truy cập.

Lỗ hổng MCP thường là “bình mới rượu cũ”

Lỗ hổng MCP thường bắt nguồn từ những cách áp dụng mới của các rủi ro và phương thức tấn công đã biết. MCP tạo ra những cách mới để kẻ tấn công khai thác các lỗ hổng này thông qua sự tương tác giữa LLM, máy chủ MCP và các dịch vụ bên ngoài.

Tất nhiên, vẫn tồn tại những mối đe dọa riêng của MCP. Tuy nhiên, cần lưu ý rằng các quy trình bảo mật tiêu chuẩn, như thực thi phân quyền nghiêm ngặt, sử dụng nhà cung cấp đáng tin cậy và phòng chống chèn lời nhắc, sẽ góp phần đáng kể vào việc bảo vệ mọi triển khai MCP.