Máy chủ MCP có thể xác minh
Attestable MCP Server mang lại xác thực từ xa và điện toán bảo mật cho quy trình FlowHunt, cho phép các tác nhân AI và khách hàng xác minh tính toàn vẹn của máy...
6 phút đọc
Security
AI Infrastructure
+4
Xác thực là cổng kiểm soát xác định liệu các khả năng mạnh mẽ của máy chủ MCP có sẵn cho người dùng hợp pháp hay cho kẻ tấn công. Nếu làm sai, mọi biện pháp kiểm soát bảo mật khác trở nên vô nghĩa — một máy chủ MCP không được xác thực hoặc được xác thực kém với quyền truy cập vào email, tệp và cơ sở dữ liệu là một lỗ hổng nghiêm trọng bất kể bạn đã tăng cường bảo mật mọi thứ khác tốt đến đâu.
Hướng dẫn của Dự án Bảo mật OWASP GenAI xác định xác thực và phân quyền là một trong tám lĩnh vực bảo mật cốt lõi cho các máy chủ MCP, với các yêu cầu cụ thể vượt xa những gì hầu hết các nhà phát triển triển khai theo mặc định. Bài viết này giải thích tại sao các yêu cầu đó tồn tại và cách triển khai chúng một cách chính xác.
Thách thức Xác thực trong MCP
Các máy chủ MCP đối mặt với bối cảnh xác thực phức tạp hơn các dịch vụ truyền thống vì chúng trung gian giữa nhiều bên chính:
- Người dùng có hướng dẫn điều khiển trợ lý AI
- Mô hình AI diễn giải hướng dẫn và gọi các công cụ
- MCP client (ứng dụng lưu trữ AI)
- Máy chủ MCP thực thi các lệnh gọi công cụ
- Các dịch vụ Downstream mà máy chủ MCP gọi thay mặt người dùng
Mỗi mối quan hệ này yêu cầu các biện pháp kiểm soát xác thực và phân quyền riêng. Một điểm yếu trong bất kỳ liên kết nào có thể bị khai thác để bỏ qua các liên kết khác.
Bắt buộc: OAuth 2.1 và OIDC cho Máy chủ Từ xa
Đối với các máy chủ MCP từ xa — những máy chủ được truy cập qua mạng thay vì thông qua STDIO cục bộ hoặc Unix sockets — hướng dẫn OWASP GenAI rất rõ ràng: OAuth 2.1 với OIDC là bắt buộc, không phải tùy chọn.
Yêu cầu này tồn tại vì:
OAuth 2.1 cung cấp kiểm soát phạm vi rõ ràng. Mọi token truy cập đều khai báo chính xác tài nguyên và hành động nào mà nó cho phép. Máy chủ MCP có thể xác minh tại thời điểm gọi công cụ rằng token được trình bày có phạm vi cụ thể cần thiết cho hành động đó — không chỉ là người dùng được xác thực, mà họ được phép cho hoạt động cụ thể này.
OIDC cung cấp danh tính mật mã. OpenID Connect bổ sung các khẳng định danh tính (ID token) mà máy chủ MCP có thể xác minh mà không cần khứ hồi đến nhà cung cấp danh tính. Máy chủ xác thực iss (issuer), aud (audience), exp (expiry) và chữ ký trên mỗi yêu cầu.
Các token OAuth 2.1 có thời hạn ngắn theo thiết kế. Đặc tả OAuth hiện đại (tổng hợp và thay thế các phương pháp hay nhất của OAuth 2.0) nhấn mạnh các token truy cập có thời hạn ngắn phải được làm mới thường xuyên. Điều này hạn chế cửa sổ thiệt hại nếu token bị xâm phạm.
Những gì Cần Xác thực trên Mỗi Yêu cầu
Đừng chỉ xác thực token khi thiết lập phiên. Xác thực trên mỗi lần gọi công cụ:
def validate_token(token: str, required_scope: str) -> TokenClaims:
claims = jwt.decode(
token,
key=get_public_key(claims_preview['kid']),
algorithms=["RS256", "ES256"]
)
assert claims['iss'] == EXPECTED_ISSUER
assert EXPECTED_AUDIENCE in claims['aud']
assert claims['exp'] > time.time()
assert required_scope in claims['scope'].split()
return claims
Không bao giờ lưu kết quả xác thực trong bộ nhớ cache giữa các yêu cầu. Một token hợp lệ khi bắt đầu phiên có thể bị thu hồi giữa phiên.
Môi trường Client Động
Trong môi trường mà các MCP client thay đổi thường xuyên (ví dụ: các trợ lý AI khác nhau kết nối với cùng một máy chủ), các API key tĩnh hoặc bí mật được chia sẻ trước là không đủ. Sử dụng đăng ký client động với OAuth 2.1 hoặc OIDC để xác minh danh tính client tại thời điểm kết nối. Danh sách cho phép, chính sách kết nối được mã hóa cứng hoặc mutual TLS (mTLS) phù hợp cho các mối quan hệ tĩnh đã biết giữa các client và máy chủ cụ thể.
Sẵn sàng phát triển doanh nghiệp của bạn?
Bắt đầu dùng thử miễn phí ngay hôm nay và xem kết quả trong vài ngày.
Vấn đề Confused Deputy
Hiểu về Cuộc Tấn công
Confused Deputy là một lỗ hổng phân quyền cổ điển với biểu hiện đặc biệt nguy hiểm trong kiến trúc MCP. Cuộc tấn công khai thác sự mơ hồ về quyền hạn của ai mà máy chủ MCP đang hành động.
Xem xét kịch bản này:
- Người dùng Alice được xác thực với máy chủ MCP với quyền hạn hạn chế — cô ấy có thể đọc các tệp của riêng mình nhưng không phải của người khác
- Máy chủ MCP có quyền tài khoản dịch vụ rộng để đọc tất cả các tệp trong tổ chức
- Máy chủ MCP sử dụng token passthrough: nó chuyển tiếp token của Alice đến các dịch vụ downstream
Khi Alice yêu cầu trợ lý AI “tóm tắt thư mục dự án của tôi”, máy chủ sử dụng token của Alice để truy cập các tệp của cô ấy — hành vi đúng. Nhưng nếu kẻ tấn công lừa máy chủ thực hiện yêu cầu sử dụng thông tin xác thực dịch vụ của chính nó (có thể thông qua cuộc tấn công đầu độc công cụ hoặc tiêm prompt gián tiếp), các quyền được nâng cao của máy chủ được sử dụng để truy cập các tệp mà Alice không được phép xem.
Máy chủ là “confused deputy” — nó đã bị lừa sử dụng quyền hạn của mình thay mặt cho người không có quyền hạn đó, hoạt động như một proxy cho việc leo thang đặc quyền.
Tại sao Token Passthrough Tạo ra Lỗ hổng Này
Nhiều triển khai MCP chuyển tiếp token của client đến các API downstream để đơn giản. Điều này có vẻ trực quan — token của người dùng đại diện cho quyền của người dùng, vì vậy việc sử dụng nó cho tất cả các cuộc gọi downstream duy trì kiểm soát truy cập chính xác.
Vấn đề: các API downstream nhận ra máy chủ MCP là một trung gian đáng tin cậy có thể cấp các yêu cầu sử dụng cấp độ danh tính của máy chủ, không phải cấp độ của token người dùng được chuyển tiếp. Và nếu máy chủ MCP bao giờ hành động theo sáng kiến của chính nó — thông qua việc ra quyết định AI mà người dùng không yêu cầu rõ ràng — nó có thể sử dụng thông tin xác thực của chính nó thay vì token của người dùng.
Chuyển tiếp token người dùng cũng:
- Phá vỡ chuỗi kiểm toán (nhật ký downstream hiển thị danh tính người dùng, không phải danh tính máy chủ, che khuất lớp MCP)
- Cung cấp cho kẻ tấn công xâm phạm máy chủ MCP quyền truy cập vào tất cả các token người dùng được chuyển tiếp
- Tạo ra các vấn đề tuân thủ nếu các token cho người dùng khác nhau có thể bị nhầm lẫn hoặc phát lại
Cách Khắc phục: Ủy quyền Token Rõ ràng với Luồng On-Behalf-Of
Thay vì chuyển tiếp token của client, máy chủ MCP nên lấy các token của riêng nó để truy cập dịch vụ downstream bằng cách sử dụng luồng On-Behalf-Of (OBO) của OAuth:
Người dùng xác thực với MCP client → client nhận token truy cập người dùng
MCP client trình bày token người dùng cho máy chủ MCP
Máy chủ MCP trao đổi token người dùng lấy token máy chủ thông qua luồng OBO:
POST /token
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=<user_access_token>
scope=<minimum_required_scope>
Máy chủ MCP sử dụng token OBO của riêng nó cho các cuộc gọi downstream
Token OBO:
- Được phạm vi rõ ràng đến các quyền tối thiểu cần thiết cho lệnh gọi công cụ cụ thể
- Xác định máy chủ MCP là bên gọi (với người dùng là chủ thể)
- Được gắn với sự kiện xác thực của người dùng (có thể được thu hồi khi phiên của người dùng kết thúc)
- Không để lộ token đầy đủ của người dùng cho các dịch vụ downstream
Token Có Thời hạn Ngắn, Có Phạm vi
Hướng dẫn OWASP GenAI đưa ra khuyến nghị cụ thể: cấp token truy cập có thời hạn được đo bằng phút, không phải giờ. Điều này áp dụng cho cả các token mà máy chủ MCP chấp nhận từ client và các token mà nó lấy để truy cập dịch vụ downstream.
Tại sao Thời hạn Ngắn Quan trọng
Một token truy cập bị đánh cắp có giá trị trong toàn bộ thời hạn của nó bất kể người dùng hợp pháp đã đăng xuất, thay đổi mật khẩu hay thu hồi phiên của họ. Một token 24 giờ bị đánh cắp vào đầu phiên cung cấp cho kẻ tấn công 24 giờ truy cập liên tục. Một token 5 phút bị đánh cắp giữa phiên cung cấp tối đa 5 phút.
Token có thời hạn ngắn cũng thực thi các sự kiện xác thực lại thường xuyên, cung cấp cơ hội để:
- Kiểm tra lại xem tài khoản của người dùng đã bị tạm ngừng hay quyền của họ đã thay đổi chưa
- Phát hiện các mẫu xác thực bất thường (thời gian, vị trí hoặc tần suất bất thường)
- Áp dụng xác thực tăng cường cho các hoạt động nhạy cảm
Giảm thiểu Phạm vi Token
Mỗi token chỉ nên mang các phạm vi cần thiết cho hoạt động cụ thể đang được thực hiện. Đừng cấp token với phạm vi read:files write:files delete:files khi lệnh gọi công cụ hiện tại chỉ cần read:files. Điều này hạn chế thiệt hại nếu token bị chặn hoặc mô hình bị thao túng thành các lệnh gọi công cụ không mong muốn.
def get_tool_token(user_id: str, tool_name: str) -> str:
# Ánh xạ công cụ đến các phạm vi tối thiểu cần thiết
required_scopes = TOOL_SCOPE_MAP[tool_name]
return oauth_client.get_token(
subject=user_id,
scopes=required_scopes,
lifetime_seconds=300 # Thời hạn 5 phút
)
Tham gia bản tin của chúng tôi
Nhận các mẹo, xu hướng và ưu đãi mới nhất miễn phí.
Coi Phiên là Trạng thái, Không phải Danh tính
Một sai lầm phổ biến là sử dụng ID phiên làm proxy phân quyền: nếu một yêu cầu mang ID phiên hợp lệ, máy chủ cho rằng nó được phép. Điều này nhầm lẫn quản lý trạng thái với xác minh danh tính.
Mô hình đúng: ID phiên quản lý trạng thái hội thoại. Phân quyền được xác minh độc lập trên mỗi yêu cầu bằng cách xác thực các claims của token OAuth. Ngay cả một yêu cầu mang ID phiên hợp lệ cũng phải trình bày một token OAuth hợp lệ, chưa hết hạn, có phạm vi phù hợp trước khi bất kỳ lệnh gọi công cụ nào được cho phép.
Điều này quan trọng vì ID phiên có thể bị đánh cắp, đoán hoặc phát lại theo những cách mà token OAuth — mang đảm bảo toàn vẹn mật mã — không thể.
Thực thi Chính sách Tập trung
Thay vì triển khai các kiểm tra phân quyền rải rác trong các trình xử lý công cụ riêng lẻ, hướng dẫn OWASP GenAI khuyến nghị một cổng chính sách tập trung mà:
- Chặn tất cả các yêu cầu gọi công cụ trước khi chúng đến mã cụ thể của công cụ
- Xác thực xác thực (chữ ký token, issuer, audience, expiry)
- Thực thi phân quyền (phạm vi yêu cầu cho công cụ cụ thể này)
- Áp dụng xác minh sự đồng ý (người dùng đã cho phép rõ ràng loại hành động này chưa?)
- Triển khai lọc công cụ (công cụ này có được phép trong ngữ cảnh triển khai này không?)
- Ghi lại tất cả các quyết định với ngữ cảnh đầy đủ để kiểm toán
Tập trung hóa đảm bảo các chính sách được áp dụng nhất quán trên tất cả các công cụ và tác nhân. Một kiểm tra phân quyền cụ thể của công cụ có thể bị quên hoặc bỏ qua trong quá trình phát triển; một kiểm tra cổng thì không thể.
Tóm tắt: Danh sách Kiểm tra Xác thực
Đối với các máy chủ MCP từ xa, thanh bảo mật xác thực tối thiểu là:
- OAuth 2.1 / OIDC được thực thi cho tất cả các kết nối
- Chữ ký token, issuer, audience và expiry được xác thực trên mỗi lần gọi công cụ
- Không có token passthrough đến các API downstream — sử dụng OBO hoặc token do máy chủ cấp
- Token truy cập được phạm vi đến quyền tối thiểu cần thiết cho mỗi công cụ
- Thời hạn token được đo bằng phút với làm mới bắt buộc
- ID phiên không được sử dụng làm proxy phân quyền
- Cổng thực thi chính sách tập trung đã có
- Tất cả các sự kiện xác thực và quyết định phân quyền được ghi lại bất biến
