FlawOpen

flawopen.com/AI Security/mcp-typescript-sdk-bearer-token-audience-validation

● CWE-863 · CVSS 6.8 · मध्यम
सुरक्षा अनुसंधान · FlawOpen

MCP TypeScript SDK में Bearer token की audience जाँच नहीं थी

GHSA-rvq5-wwqv-78pq उन MCP HTTP सर्वरों को प्रभावित करता है जो audience जाँचे बिना token स्वीकार करते थे। अपडेट करें, expectedResource सक्षम करें और सत्यापित audience को AuthInfo.resource में लौटाएँ।[1]

💡 आसान भाषा में (ELI5)

सुरक्षा गार्ड वैध प्रवेश-पत्र स्वीकार करता है, लेकिन यह नहीं देखता कि वह किस इमारत के लिए है। एक ही जारीकर्ता कई इमारतों के लिए पत्र दे तो पड़ोसी इमारत का पत्र भी चल सकता है। MCP सर्वर को पत्र का गंतव्य अपने resource URL से मिलाना चाहिए।[1]

इस पेज के मुख्य शब्द

Audience (`aud`)
वह resource या service जिसके लिए access token जारी हुआ है। सही signature या सफल introspection यह साबित नहीं करता कि token इसी MCP सर्वर के लिए था।[1], [7]
`expectedResource`
ठीक किए गए middleware की स्पष्ट रूप से चालू की जाने वाली setting। यह configured resource URL को token verifier द्वारा बताए गए resource से मिलाती है और अंतर होने पर HTTP 401 देती है।[1], [2], [7]
`AuthInfo.resource`
विश्वसनीय token-validation या introspection डेटा से verifier द्वारा निकाला गया resource URL। जाँच चालू होने पर ठीक किए गए middleware को यह मान चाहिए; इसके बिना अनुरोध अस्वीकार होते हैं।[1], [2], [7]
प्रभावित पैकेज
Advisory में @modelcontextprotocol/sdk 1.6.0–1.31.0, @modelcontextprotocol/server 2.0.0–2.2.0, @modelcontextprotocol/express 2.0.0–2.0.1 और @modelcontextprotocol/server-legacy 2.0.0–2.3.0 शामिल हैं। CVE नहीं दिया गया; vendor ने CWE-863 दिया है।[1], [3], [6]

फ्रेमवर्क मैपिंग

  • इस गाइड में बताई गई कमजोरी के लिए CWE संदर्भ: CWE-863

हमले का चरण-दर-चरण प्रवाह

चरण 1

एक issuer कई API के लिए token देता है

प्रभावित deployment MCP HTTP bearer authentication इस्तेमाल करता है और authorization server कई services के लिए token जारी करता है। दूसरे API के लिए बना token भी सही तरह signed और अभी valid हो सकता है।[1]

चरण 2

Token जाँचा जाता है, उसका गंतव्य नहीं

प्रभावित integration में requireBearerAuth() / verifyBearerToken() के पास expected resource की अंतर्निहित जाँच नहीं थी। यदि application का verifyAccessToken() भी aud न जाँचे तो MCP server दूसरे service के लिए बना token स्वीकार कर सकता था।[1], [2], [5]

चरण 3

दूसरे service का token MCP authorization तक पहुँचता है

दूसरे service का valid token रखने वाला caller इस MCP server पर authenticated माना जा सकता है। Advisory ने CVSS 3.1 6.8 और CWE-863 दिया है; इसमें किसी वास्तविक exploitation incident की पुष्टि नहीं है।[1], [4]

चरण 4

अपडेट करें और जाँच को MCP resource से बाँधें

ठीक किया गया release लगाएँ, expectedResource में इस server का resource identifier दें और verifyAccessToken() से सत्यापित audience को AuthInfo.resource में लौटाएँ। केवल update से विकल्प चालू नहीं होता; resource न होने पर सभी अनुरोध 401 होंगे।[1], [2], [5], [3], [6], [7]

प्रभावित MCP TypeScript SDK पैकेज

पैकेजप्रभावित संस्करणठीक किया गया संस्करण
@modelcontextprotocol/sdk1.6.0–1.31.01.32.0 या बाद का
@modelcontextprotocol/server2.0.0–2.2.02.3.0 या बाद का
@modelcontextprotocol/express2.0.0–2.0.12.0.2 या बाद का
@modelcontextprotocol/server-legacy2.0.0–2.3.02.3.1 या बाद का
verifyAccessToken() में अपना aud validation करने वाला कोई भी packageApplication में helper की अनुपस्थित जाँच पहले से लागू हो सकती है।पुष्टि करें कि तुलना strict है और अपेक्षित resource identifier का उपयोग करती है।

सोर्स कोड: कमज़ोर बनाम सुरक्षित कार्यान्वयन

यह उदाहरण SDK के दस्तावेज़ और शामिल किए गए सुधार के अनुरूप है। verifyJwt application के मौजूदा JWT validator या introspection call को दर्शाता है। सुधार से पहले middleware में expectedResource नहीं था और audience की तुलना नहीं होती थी; ठीक किया गया version configured resource को AuthInfo.resource से मिलाता है। Authorization server aud में जो सटीक identifier रखता है, वही उपयोग करें; उदाहरण समान origin वाला audience URL चुनता है और पूरे resource की तुलना SDK पर छोड़ता है। SDK 1.x को 1.32.0 या बाद में अपडेट करें; 2.x के लिए @modelcontextprotocol/server 2.3.0 या बाद का उपयोग करें। Express के साथ @modelcontextprotocol/express को भी 2.0.2 या बाद में अपडेट करें। क्योंकि AuthInfo.resource का प्रकार URL है, इसलिए सामान्य गैर-URL aud मान की तुलना expectedResource से नहीं की जा सकती। ऐसे deployment में verifyAccessToken() के भीतर उस identifier की सख्ती से जाँच करें और expectedResource सेट न करें। verifyJwt का implementation application-specific है और छोड़ा गया है; token forgery या exploit steps नहीं दिए गए हैं।[1], [2], [5], [3], [6], [7]

कमज़ोर कार्यान्वयन
import { requireBearerAuth } from '@modelcontextprotocol/sdk/server/auth/middleware/bearerAuth.js';

const mcpServerUrl = new URL('https://api.example.com/mcp');
const auth = requireBearerAuth({
  verifier: {
    async verifyAccessToken(token) {
      const payload = await verifyJwt(token); // ऐप्लिकेशन JWT सत्यापन
      return {
        token,
        clientId: payload.sub,
        scopes: payload.scopes,
        expiresAt: payload.exp,
        // यहाँ resource लौटाया नहीं जाता, और प्रभावित helper में expectedResource विकल्प नहीं था।
      };
    },
  },
});
सुरक्षित और सुदृढ़ फ़िक्स
import { requireBearerAuth } from '@modelcontextprotocol/sdk/server/auth/middleware/bearerAuth.js';

const mcpServerUrl = new URL('https://api.example.com/mcp');
const auth = requireBearerAuth({
  verifier: {
    async verifyAccessToken(token) {
      const payload = await verifyJwt(token); // ऐप्लिकेशन JWT सत्यापन
      // aud स्ट्रिंग, सूची या अनुपस्थित हो सकता है। इस सर्वर की प्रविष्टि लौटाएँ।
      const audience = [payload.aud ?? []].flat().find(
        aud => URL.canParse(aud) && new URL(aud).origin === mcpServerUrl.origin,
      );
      const resource = audience ? new URL(audience) : undefined;
      return {
        token,
        clientId: payload.sub,
        scopes: payload.scopes,
        expiresAt: payload.exp,
        resource,
      };
    },
  },
  expectedResource: mcpServerUrl,
});

इंजीनियरिंग और सिस्टम सुरक्षा चेकलिस्ट

स्रोत

← AI Security Directory →