Агенттік жүйелердегі қашықтағы MCP-сервер арқылы SSRF

Сыртқы MCP-серверді қосу API-мен жасалатын кәдімгі интеграция емес. Сіз агенттік жүйеге жаңа қашықтағы мекенжайды, модельге арналған жаңа нұсқаулар жиынтығын және көбіне желіге шығатын құралдарға апаратын жаңа жолды қосасыз. Егер бұл жолды қосылмай тұрып шектемесеңіз, SSRF агентті localhost, бұлттың қызметтік endpoint-тері, ішкі API-лар және пайдаланушы кіре алмайтын сегменттерге арналған ыңғайлы проксиге айналдырады.

Ең жиі кездесетін қате сырттай қарағанда қауіпсіз көрінеді: команда пайдаланушыға MCP-серверінің URL мекенжайын көрсетуге рұқсат береді, жолдың https:// арқылы басталатынын тексереді де, осы жеткілікті деп ойлайды. Кейін клиент DNS-ті өзі ажыратады, redirect-ті автоматты түрде орындайды, қосылымды қайта ашады, ал браузер құралы сервер жұмысының нәтижесінде келген мекенжайға кіру туралы бұйрық алады. Бұл сұлбада тек жолдың өзі тексерілді. Сұраулар мүлде басқа жерге кетті.

Қашықтағы MCP бір ғана шығыс қосылымы емес

Қашықтағы MCP желілік әрекеттердің кемінде екі түрлі класын тудырады және оларды араластыру қауіпті.

Бірінші класс - клиенттен серверге баратын транспорт. Агенттік MCP-клиент сервердің мекенжайына HTTP-сұраулар жібереді немесе ағынды қосылымды ұстап тұрады. Егер мекенжайды пайдаланушы, tenant конфигурациясы немесе басқа сыртқы сервис берсе, бұл клиенттің өзіндегі SSRF үшін кіру нүктесіне айналады.

Екінші класс - қосылғаннан кейін модель жасайтын әрекеттер. Сервер fetch_url құралын сипаттауы, модельге браузерде сілтемені ашуды ұсынатын мәтін қайтаруы, URL арқылы құжат импорттауды ұсынуы немесе URL-ді агенттің бұрыннан сенімді құралына беруі мүмкін. Сервер желілік қолжетімділікті автоматты түрде алмайды, бірақ агентте бұрыннан бар қолжетімділікті пайдалану туралы модельдің шешіміне әсер ете алады.

Бұл екі бөлек қорғаныс контуры.

• MCP транспорты үшін тіркеу URL-ін, DNS-ті, IP мекенжайын, портты, TLS-ті, redirect-ті және процесс маршрутын бақылайсыз.
• Құралдар үшін шақыру схемасын, рұқсат етілген аргументтерді, орындаушының құқықтарын, желілік саясатты және сенімсіз мәтінді өңдеуді бақылайсыз.

Екі жағдайды да «localhost-қа қосылмаймыз» деген бір ережеге сыйғызсаңыз, қорғаныс толық болмайды. OWASP схемалардың, порттардың және тағайындалған орындардың оң тізімін беруді, HTTP redirect-ті өшіруді және тексеру мен мекенжайды пайдалану арасындағы жарыс жағдайымен бірге DNS rebinding-ті ескеруді ұсынады.

MCP шығыс желі тәртібінің кәдімгі талаптарын өзгертпейді. Model Context Protocol спецификациясы Streamable HTTP үшін кіріс қосылымдарында Origin мәнін тексеруді бөлек талап етеді, жергілікті серверлерге тек 127.0.0.1 адресін тыңдауды ұсынады және аутентификацияны талап етеді. Бұл жергілікті MCP-серверді браузер жағындағы DNS rebinding-тен қорғауға арналған. Клиент жағы үшін қорытынды одан да қатаң: сыртқы сервер атауына қарап емес, нақты мекенжайы мен желілік маршрутына қарап сыртқы болуы керек.

URL жолы ештеңені дәлелдемейді

startsWith("https://") тексеруі тағайындалған орынды тексеру емес. URL-ді стандартты парсермен ажыратып, нормализациялап, оның бөліктерін бөлек тексеріңіз: схема, хост атауы, порт, жол және authority ішінде есептік деректердің болмауы.

Мына нұсқалар DNS-ке дейін-ақ қабылданбауы керек:

• http:// және саясат тек HTTPS-ке рұқсат етсе, кез келген стандартты емес схема;
• user@host бар URL, мұнда көзге бір хост көрініп, қосылым басқа хостқа кетуі мүмкін;
• саясат тек нақты домен атауларына рұқсат етсе, IP литералдары;
• серверге тек 443 қажет болғанда, стандартты емес порттар;
• кері қиғаш сызықтар, қате кодтау және IPv4 пен IPv6 жазбаларының екіұшты түрлері.

Бұл жерде регулярлық өрнек стандартты URL парсерінен көбіне нашар. Ол нормализацияның барлық ережесін білмейді, ал шабуылдаушы regex авторы ескермеген жазылу түрлерін іздеуге уақыт табады. OWASP-тың Node.js жөніндегі өзекті нұсқаулығында alternate IP formats, IPv4-mapped IPv6, backslash, Unicode және embedded credentials арқылы жасалатын айналып өту тәсілдері жеке аталған.

Тіркеудің екі режимін бөліңіз.

Сенімді каталог режимі продакшенге жарайды. Конфигурацияда алдын ала мақұлданған сервер атаулары, рұқсат етілген порттар және күтілетін аутентификация тәсілі сақталады. Пайдаланушы мекенжайды өзі енгізбейді, каталогтан сервер таңдайды.

Зерттеу құмсалғышы режимі пайдаланушы URL-іне рұқсат береді, бірақ корпоративтік желіге, бұлт есептік деректеріне, production DNS-іне және ортақ браузер профиліне қолжетімсіз бөлек worker іске қосады. Ол бір қолданбадан шақырылғаны үшін негізгі агенттің құқықтарын мұра етпеуі керек.

Бұл режимдерді allow_custom_mcp_url деген бір жалаушамен біріктіруге тырыспаңыз. Продакшенде ол әдетте «артық құқықтары бар процестен кез келген шығыс сұрауға рұқсат беру» дегенді білдіреді.

DNS-ті қосылу сәтінде тексеру керек

DNS rebinding «алдымен доменге рұқсат беріп, кейін атау арқылы қосыламыз» деген сұлбаны бұзады. Алғашқы сұрауда mcp.example тексеруден өтетін жария IP мекенжайын қайтаруы мүмкін. Кейін TTL аяқталады, клиент жаңа resolve жасайды, ал сол атау 127.0.0.1, корпоративтік желідегі мекенжайды немесе metadata service-тің link-local адресін қайтарады.

Код A және AAAA жазбаларының бір мекенжайын тексеріп, HTTP кітапханасы басқасын таңдаса, жағдай одан да қауіпті. Тексеру мен қосылу екі бөлек операцияға айналады.

Жұмыс істейтін ереже мынадай: клиент атауды ажыратып, алынған әрбір мекенжайды тексеруі, рұқсат етілген мекенжайды таңдап, TCP қосылымын дәл сонымен ашуы керек. Әр жаңа қосылымда бүкіл цикл қайталанады. TLS кезінде SNI және сертификатты тексеру үшін күтілетін сервер атауын сақтау қажет, бірақ кітапханаға атауды сіз бақылай алмайтын тәсілмен қайта ажыратуға еркіндік бермеу керек.

Псевдокод қажетті ретті көрсетеді:

url = parse_and_normalize(input)
assert url.scheme == "https"
assert url.port in {443}
assert hostname_in_allowlist(url.hostname)

answers = resolve_all(url.hostname)
assert answers is not empty
for ip in answers:
    assert is_public_routable(ip)

ip = choose_address(answers)
socket = dial_tcp(ip, url.port, timeout=3s)
tls = handshake(socket, server_name=url.hostname, verify_certificate=true)
http = send_request_over(tls, host=url.hostname, redirect="error")

Нақты кодта dial_tcp шынымен IP алуы маңызды, атау емес. Әйтпесе кітапхана жасырын түрде екінші DNS resolve жасап, осалдықты қайтарады.

DNS тексеруі аудитке кемінде бастапқы атауды, алынған мекенжайлар тізімін, таңдалған мекенжайды, портты, уақытты, рұқсат немесе бас тарту ережесін және MCP қосылымының идентификаторын жазуы керек. Бұл деректер жай ғана әдемілік үшін қажет емес. Тергеу «агент неге 169.254.169.254 адресіне баруға тырысты?» деген сұрақтан басталғанда, нақты IP көрсетілмеген журналдың пайдасы шамалы.

Жеке мекенжайлар тыйым салынған аймақтың бір бөлігі ғана

RFC 1918 диапазондарын бұғаттау міндетті, бірақ бұл SSRF мәселесін толық жаппайды. RFC 1918 10.0.0.0/8, 172.16.0.0/12 және 192.168.0.0/16 диапазондарын жеке IPv4 мекенжайлар кеңістігі ретінде анықтайды. Ішкі сервис, localhost немесе metadata service осы үш диапазоннан тыс жерде болуы мүмкін.

is_public_routable(ip) функциясы «бірнеше қауіпті мекенжайды» емес, нақты контур үшін рұқсат етілген жария тағайындалған орын болып саналмайтын барлық мекенжайды қабылдамауы керек. Қабылданбайтын ең аз жиынға мыналар кіреді:

• IPv4 loopback, unspecified және 0.0.0.0/8;
• RFC 1918, link-local 169.254.0.0/16, carrier-grade NAT 100.64.0.0/10, multicast және резервтелген диапазондар;
• IPv6 ::, ::1, link-local fe80::/10, unique local fc00::/7, multicast ff00::/8;
• IPv4-mapped IPv6, оларды түрлендіргеннен кейін бастапқы IPv4 мекенжайын тексеру керек;
• желілік маршрут жалпы ережеден ерекше көрінсе де, бұлттағы metadata service мекенжайлары.

OWASP denylist үшін localhost, RFC 1918, multicast және 169.254.169.254 сияқты ең аз жиынды келтіреді, бірақ denylist-ті айналып өтуге болатынын және allowlist артық екенін ескертеді. Басымдықты осылай бөлу дұрыс: тыйым салынған тізім белгілі қауіпті мекенжай кластарын ұстайды, ал рұқсат тізімі процеске жалпы қайда баруға болатынына жауап береді.

«Бұл біздің ішкі MCP» деген себеппен жеке мекенжайға рұқсат бермеңіз. Ішкі серверге сервис желісі, mTLS, бөлек DNS zone және жеке policy арқылы бөлек қосылу қажет. Бір код пен бір жалауша жария және ішкі мекенжайларға қатар бара алса, біреу ерте ме, кеш пе сыртқы тіркеу жолы арқылы ішкі мекенжай береді.

Redirect сіздің тексеруіңізден кейін тағайындалған орынды өзгертеді

Қашықтағы серверді тіркегенде автоматты redirect әсіресе қауіпті. Клиент https://approved.example/mcp мекенжайын тексеріп, аутентификация тақырыптарын жібереді де, 302 Location: http://127.0.0.1:8080/admin алады. Кітапхана өтуді өзі орындаса, алғашқы тексерудің мәні қалмайды.

Қосылу кезеңінде redirect-ке тыйым салу оңай әрі қауіпсіз. Клиент кез келген 3xx мәртебесін алып, әрекетті тоқтатып, оқиғаны журналға жазады. MCP endpoint үшін бұл қалыпты бизнес қажеттілігін сирек туғызады: жұмыс істейтін сервер мекенжайы соңғы мекенжай болуы керек.

Егер архитектура өтулерді қолдауды талап етсе, әр Location мәнін мүлде жаңа URL ретінде өңдеңіз. Схеманы, атауды, портты, DNS-ті және таңдалған IP мекенжайын қайта ажыратып, тексеріңіз. Өтулер санын шектеңіз. Жеке ереже болмаса, басқа origin-ге Authorization, cookies және арнайы тақырыптарды тасымалдамаңыз.

MDN Response.redirected қасиетін жауаптан кейін тексеру кеш екенін ескертеді: сұрау қалаусыз мекенжайға кетіп үлгеруі мүмкін. Redirect-ке fetch шақырылған сәтте тыйым салу керек, кейін болған фактіні анықтау жеткіліксіз.

Одан да байқалмайтын нұсқа бар: құрал ішіндегі redirect. MCP-сервер read_document(url) құралын береді, агент оған тек жеткізуші доменіне рұқсат етеді, бірақ құралдың өзі басқа домендегі файлға немесе ішкі мекенжайға өтеді. Бақылау тек шақыру алдындағы аргумент валидаторында емес, құралдың HTTP-клиентінде болуы керек.

Браузер құралын бөлек контурда ұстау керек

Браузерде Same-Origin Policy болғандықтан, оны жиі қауіпсіз деп санайды. Агентті SSRF-тен қорғау үшін бұл дұрыс модель емес. Браузер агент бұйрығымен URL ашады, навигацияны орындайды, суреттер мен скрипттерді жүктейді, прокси қолданады, кейде cookies немесе SSO сессиясына ие болады. Браузер саясаты бетке жауапты оқуға мүмкіндік бермесе де, желілік сұраудың өзі жасалып қойды.

Сыртқы MCP-сервер браузерді тікелей шақырмауы мүмкін. Оған «жалғастыру үшін тексеру мекенжайын ашыңыз» деген мәтінді қайтару жеткілікті, ал модель оны тапсырманың бір бөлігі деп қабылдауы мүмкін. Бұл желілік салдары бар indirect prompt injection.

Сондықтан браузер құралы төрт шектеуді қажет етеді.

1. Бөлек egress. Оның процесі немесе контейнері production ішкі желілерін, кластерді басқару endpoint-ін, metadata service және ішкі DNS атауларын көрмеуі керек.
2. Бөлек есептік деректер. Құмсалғышта корпоративтік cookies, әкімшілік панель токендері, SSH-агенттері және ортақ профиль файлдары болмауы керек.
3. Навигация саясаты. Тек HTTPS-ке және мүмкін болса, бекітілген домендер жиынына рұқсат беріңіз. Әр навигация мен әр өтуді бастапқы сілтемамен ғана шектелмей тексеріңіз.
4. Сезімтал әрекеттерге нақты растау. Файл жүктеу, форма жіберу, SSO арқылы кіру, орындалатын мазмұнды жүктеп алу және жаңа доменге сұрау жасау құрал мәтін қайтарғаны үшін ғана орындалмауы керек.

Браузерді web_search атауының артына жасырмаңыз. Атауы оның құқықтарын өзгертпейді. Құрал тек іздей ме, жария беттерді аша ма, файл жүктей ме, форма жібере ме немесе аутентификацияланған сессиямен әрекет ете ме, бұл құжаттама мен аудит журналдарынан көрініп тұруы керек.

Желілік саясат кодтағы қатеден де төтеп беруі керек

Қолданбадағы URL тексеруі қажет, бірақ парсингтегі бір қате, жаңа кітапхана немесе басқа құрал арқылы жасалған айналып өту қолжетімділікті қайта ашуы мүмкін. Сондықтан агент процесі код соны сұраған жағдайда да қауіпті мекенжайға қосыла алмауы керек.

Орынды сұлба мынадай:

agent-orchestrator
  -> тек LLM API және тапсырмалар кезегі
mcp-worker
  -> тек egress proxy арқылы бекітілген MCP endpoint-тер
browser-worker
  -> корпоративтік ішкі желілерсіз бөлек proxy арқылы жария HTTPS
internal-tools-worker
  -> ерікті URL-сіз тек нақты ішкі сервистер

Бұл міндетті түрде төрт виртуалды машина дегенді білдірмейді. Бөлек workload, network namespace, контейнерлер, service account және egress firewall ережелері де жарайды. Маңызды қағида мынау: ерікті URL-мен жұмыс істейтін құрал банк, CRM немесе ішкі каталогтан дерек оқитын құралмен бірдей маршрутқа ие болмауы керек.

Желі деңгейінде әдепкі ереже қойыңыз: барлық шығыс трафикке тыйым салып, тек белгілі тағайындалған орындарды ашыңыз. Сыртқы MCP endpoint-тері үшін бұл әдетте бақыланатын proxy арқылы рұқсат етілген FQDN немесе жеткізушінің тұрақты болса, белгілі CIDR диапазондары. Ішкі endpoint-тер үшін ортақ allowlist-ке кең диапазон қосудың орнына бөлек gateway пен mTLS қолданған дұрыс.

Прокси hostname, ажыратудан кейінгі IP, SNI, порт, әдіс, мәртебе, көлем және сұрауға рұқсат берген ережені журналдауы керек. DNS, proxy және құрал журналдарында ортақ trace ID болсын. Әйтпесе модельдің ниетін немесе желілік фактіні ғана көріп, екеуін байланыстыра алмайсыз.

Қосылымды ғана емес, құралдың әрекетін де тексеріңіз

Команда көбіне бір дұрыс endpoint-ті тексеріп, сәтті initialize нәтижесін алған соң мәселе жабылды деп ойлайды. Тексеру әрқайсысы бақыланатын бас тартумен және журналдағы жазбамен аяқталуы тиіс теріс сценарийлер жиынтығы болуы керек.

Оқшауланған тест ортасын және өзіңіз басқаратын тест хосттарын пайдаланыңыз. Бөтен мекенжайларды сканерлеп, қорғанысты тексермеңіз. Ең аз жиын мынадай:

DNS rebinding тесті тексеру мен қосылымның нақты байланысын дәлелдеуі керек. Алғашқы кезеңде рұқсат етілген мекенжайға, кейін тыйым салынған мекенжайға ажыратылатын тест атауын іске қосыңыз. Келесі қосылым кезінде клиент бас тартуы керек, бұрынғы шешімді шексіз рұқсат ретінде қолданбауы тиіс. Бірнеше A және AAAA жазбасы бар қосылымды да бөлек тексеріңіз: тыйым салынған мекенжайлардың кемінде бірі болса, мекенжайды таңдауды қатаң басқаратын механизм іске асқанға дейін атауды толық қабылдамаған қауіпсіз.

MCP-серверден келетін мәтіндерді де тексеріңіз. Жаңа домендегі URL-ді ашуға, архив жүктеп алуға немесе қызметтік порталға кіруге нұсқау беретін құрал жасаңыз. Агент сыртқы құралдың мәтіндік нәтижесін жоғары құқықтары бар желілік әрекетке автоматты түрде айналдырмауы керек.

MCP құралдарын сенімсіз нұсқаулар деп қабылдау керек

MCP-клиент әдетте модельге құрал атауын, сипаттамасын, аргументтердің JSON Schema-сын және орындалу нәтижесін көрсетеді. Мұның бәрі қашықтағы серверден келеді. search_docs сипаттамасында сіздің браузер құралыңызды шақыруға жасырын үндеу болуы мүмкін. get_status нәтижесінде қатені түзету үшін ішкі мекенжайға өту керек деп жазылуы мүмкін. Құрылымды JSON деректерді ыңғайлы етеді, бірақ сенімді етпейді.

Модельдің құрал таңдау мүмкіндігін құралдың әрекетті орындау құқығынан бөліңіз. Модель шақыруды ұсына алады. Саясат қабаты дәл осы аргументтермен және осы контексте шақыруға рұқсат бар-жоғын шешуі керек.

Іс жүзінде бұл мынаны білдіреді:

• қашықтағы MCP-серверге оның міндеттеріне қажеттен кең токендер бермеңіз;
• бір құралдың URL мекенжайын қайта тексермей, басқа құралға автоматты түрде беруіне жол бермеңіз;
• сыртқы құралдардың нәтижесін модель контекстінде сенімсіз дерек ретінде белгілеңіз;
• жаңа домен, файл немесе есептік жазба тапсырма шегінен шыққанда, адамнан нақты растау сұраңыз;
• агент сканерге айналмауы үшін желілік шақырулардың жиілігі мен параллельдігін шектеңіз.

MCP авторизациясы жөніндегі спецификацияда бөлек ескерту бар: қате audience мәні бар токендерді қабылдап, әрі қарай жіберетін сервер confused deputy мәселесін тудыруы мүмкін. Дәл осы логика агентке де қатысты: қашықтағы серверге процессіңіздің кеңірек желілік немесе есептік деректер тұлғасын жанама түрде пайдалануға мүмкіндік бермеңіз.

Сыртқы серверді қоспас бұрын тексеру тізімі

Алғашқы production қосылымына дейін осы тізімнен өтіп, нәтижені change request ішінде тіркеңіз.

• Сервер мекенжайы бекітілген каталогтан алынған немесе бөлек зерттеу құмсалғышында іске қосылған.
• URL парсері HTTPS пен рұқсат етілген порттарды шектейді және URL-дің екіұшты түрлеріне тыйым салады.
• DNS resolver барлық A және AAAA мекенжайларын қайтарады, ал саясат нақты қосылымға дейін олардың әрқайсысын тексереді.
• TCP қосылымы тексерілген IP арқылы ашылады, TLS сертификат пен сервер атауын тексереді, жасырын қайта resolve жасау мүмкін емес.
• Redirect өшірілген. Ерекше жағдай қажет болса, әр өту құпия тақырыптарды тасымалдамай, толық тексеру циклінен өтеді.
• Egress firewall немесе proxy процесс үшін localhost, private, link-local, metadata endpoint-терін және міндетіне қатысы жоқ ішкі желілерді бұғаттайды.
• Браузер, HTTP-fetch және ішкі құралдар әртүрлі есептік деректермен және маршруттармен бөлек контурларда іске қосылған.
• Журналдар агент шешімін, MCP құралын шақыруды, DNS жауабын, нақты IP-ді және желілік нәтижені бір trace ID арқылы байланыстырады.
• Тесттер redirect, DNS rebinding, IPv6, mixed DNS answers және сыртқы құралдың жаңа URL ашу туралы нұсқауын қамтиды.
• Интеграция иесі нақты MCP-серверді, оның кілттерін және egress ережесін тез өшіру жолын біледі.

AI Router модельдік шақыруларға арналған бірыңғай OpenAI-мен үйлесімді шлюз ретінде пайдаланылуы мүмкін, бірақ MCP-worker мен browser-worker бәрібір өздерінің желілік шекараларына ие болуы керек. Модель маршрутизациясы агенттің шығыс сұрауларына арналған саясатты алмастырмайды.

Бір жағымсыз сұраққа жауап бере алмайынша серверді қоспаңыз: «Егер ол ертең құрал сипаттамасында немесе нәтижесінде зиянды сілтеме бере бастаса, оны нақты қай процесс ашуға тырысады және оған физикалық тұрғыда қайда баруға рұқсат берілген?» Жауап «негізгі агент, кез келген жерге» болса, мәселе енді MCP-де емес.