MCP serveri ülevaatus enne, kui AI-agent saab tööriistad

Suhtuge MCP serverisse kui kolmanda osapoole koodi, mis tegutseb teie mandaatidega, ja vaadake see üle enne, kui agent saab seda kutsuda. Allpool toodud kontrollid tuginevad MCP autoriseerimisspetsifikatsioonile (redaktsioon 2025-06-18) ja MCP turvalisuse parimatele tavadele (redaktsioon 2025-11-25). Redaktsioonid erinevad, seega kontrollige enne ühegi nõude najale toetumist kehtivat spetsifikatsiooni.

Autoriseerimine on valikuline, seega kontrollige, kas see on olemas

HTTP-transpordil töötavad serverid peaksid järgima autoriseerimisspetsifikatsiooni. STDIO-serverid seda ei peaks, vaid võtavad mandaadid keskkonnast. Lokaalse STDIO-serveri puhul koostage loend keskkonnamuutujatest, mille teie kliendi konfiguratsioon protsessile edastab, ja küsige iga muutuja kohta, kas seda on tõesti vaja.

HTTP-serveri puhul saatke autentimata päring:

curl -i https://mcp.example.com/mcp

Vastuseks peaksite saama 401 Unauthorized koos WWW-Authenticate päisega, mis annab ressursi metaandmete URL-i. Laadige see dokument alla ja veenduge, et selles on authorization_servers vähemalt ühe kirjega. Kui server vastab hoopis andmetega, lõpetage kontroll siinkohal.

Seejärel veenduge punktides, mille spetsifikatsioon märgib kohustuslikuks:

• Klient saadab igas HTTP-päringus Authorization: Bearer <access-token> ning token ei ilmu kunagi URI päringustringis.
• Autoriseerimisserveri lõpp-punktid kasutavad HTTPS-i ning redirect URI-d on kas localhost või HTTPS.
• Autoriseerimisserver võrdleb redirect URI-sid täpselt eelnevalt registreeritud väärtustega.
• Kliendid realiseerivad PKCE.

Kliendid peaksid kontrollima ka state parameetrit ning autoriseerimisserverid peaksid väljastama lühiajalisi juurdepääsutokeneid.

Tokeni audience ja scope

Klient peab saatma resource parameetri (RFC 8707) nii autoriseerimis- kui ka tokenipäringus ning server peab kontrollima, et iga token on väljastatud just temale. Vastasel juhul töötavad teistele teenustele väljastatud tokenid selle serveri vastu.

Token passthrough on veelgi hullem: server aktsepteerib tokenit, mida talle ei väljastatud, ja edastab selle muutmata kujul allavoolu. Sellised kontrollmehhanismid nagu rate limiting ja monitooring võivad sõltuda tokeni audience'ist ning allavoolu logid võivad omistada päringud valele identiteedile, mis raskendab juurdluse tegemist.

Audience'i sidumise testimiseks küsige registreeritud kliendiga autoriseerimisserveri metaandmetes olevast token_endpoint lõpp-punktist token teise ressursi jaoks. Esitage see uuesti MCP serveri vastu:

curl -i -H "Authorization: Bearer $OTHER_TOKEN" https://mcp.example.com/mcp

Oodata on 401. Kehtiv token, millel puuduvad vajalikud õigused, peaks saama vastuseks 403. Kui autoriseerimisserver sellist tokenit ei väljasta, küsige tarnijalt, kuidas MCP server audience'i kontrollib.

Uurige ka, kus server tokeneid hoiab. Avalike klientide puhul tuleb refresh tokeneid roteerida ning serveris vahemällu salvestatud või logitud tokenid on varguse sihtmärk.

Proxy-serverid ja nõusolek

Kui MCP server asub kolmanda osapoole API ees ühe staatilise client ID-ga, lugege parimate tavade dokumendist confused deputy jaotist. Rünne eeldab staatilist client ID-d, dünaamilist kliendiregistreerimist, kolmanda osapoole autoriseerimisserveri nõusolekuküpsist ja seda, et proxy juures puudub kliendipõhine nõusolek. Viimase parandamine on teie ülesanne: proxy peaks pidama iga kasutaja kohta registrit kinnitatud client_id väärtustest ning näitama oma nõusolekulehel kliendi nime, scope'e ja redirect URI-d. Nõusolekuleht peab iframe'i sisse paigutamise blokeerima, kasutades frame-ancestors või X-Frame-Options: DENY.

Koostage tööriistade allowlist ja seejärel kitsendage seda

Küsige serverilt tema tööriistade loend ja võrrelge seda ülesande vajadustega. Kõik üleliigne on OWASP LLM06:2025 mõistes liigne funktsionaalsus. Eemaldage see või takistage agendil seda kutsumast.

Salvestage loend baseline'ina ja tehke pärast iga serveri uuendust diff, et uuenduses lisandunud tööriist vaadataks üle enne, kui agent saab seda kutsuda. Seejärel kontrollige iga allesjäänud tööriista:

• Kas see on piirideta, nagu "käivita shelli käsk" või "too URL"? Asendage see kitsa tööriistaga. OWASP-i näide on shellipääsu asemel failikirjutamise tööriist.
• Millist identiteeti see allavoolu kasutab? Andmeid lugev tööriist peaks ühenduma ainult SELECT õigusega, mitte UPDATE, INSERT ja DELETE õigustega.
• Kas see tegutseb ühe kasutaja nimel? Siis peaks see autentima OAuthi kaudu minimaalse scope'iga, mitte üldise privilegeeritud konto kaudu.

Rakendage piirangud allavoolu süsteemis. OWASP nimetab seda complete mediation'iks: ärge toetuge sellele, et mudel otsustab, kas tegevus on lubatud.

Inimese kinnitus kirjutamistoimingutele

Hallutsinatsioon ja prompt injection on kahjulike tegevuste sagedased vallandajad, seega vajavad suure mõjuga tegevused inimest ahelas. OWASP kirjeldab meiliassistenti, mis teeb saabuvatest kirjadest kokkuvõtteid. Süstitud kiri meelitab seda skannima postkasti tundliku info leidmiseks ja edastama selle ründajale.

Selle rünnaku oleks katkestanud igaüks neist: ainult lugemisõigusega laiendus, ainult lugemist lubav OAuthi scope või iga koostatud kirja käsitsi ülevaatus enne saatmist. Kihistage neid, kus võimalik.

Kõik, mis kustutab, saadab või postitab, kuulub kinnitusloendisse. Paigutage kinnitus laiendusse või allavoolu süsteemi. Logimine ja rate limiting ei takista excessive agency't, kuid muudavad soovimatud tegevused kergemini märgatavaks.

Kui klient töötab serveripoolselt

OAuthi discovery käigus laadib klient alla serveri antud URL-e, sealhulgas resource_metadata, authorization_servers ja token_endpoint. Pahatahtlik server võib suunata need sisevõrgu aadressidele või pilve metaandmete lõpp-punktile aadressil 169.254.169.254.

Nõudke tootmises HTTPS-i, blokeerige privaatsed ja reserveeritud vahemikud ning kontrollige suunamiste sihtkohti või keelake automaatsed suunamised. Ärge kirjutage IP-valideerimist käsitsi, sest oktaal-, heksa- ja IPv4-mapped IPv6 nipid võidavad isekirjutatud parserid. Kaaluge egress proxy'd, näiteks Smokescreen.

Seejärel testige. Seadke püsti vaenulik testserver, mis tagastab 401 vastuse, mille WWW-Authenticate päis sisaldab resource_metadata URL-i, mis osutab aadressile http://169.254.169.254/, ning korrake testi URL-iga, mis suunab sisevõrgu aadressile. Klient peaks mõlemast keelduma ja sisemise sihtkoha kuulaja ei tohiks näha ühtegi päringut.

Kust alustada

1. Koostage loend kõigist MCP serveritest, mida teie agendid kasutavad, koos transpordi ja operaatoriga. Eemaldage need, mille olemasolu te põhjendada ei suuda.
2. Käivitage iga HTTP-serveri vastu curl -i ja veenduge, et tulemuseks on 401 koos WWW-Authenticate päisega. Seejärel esitage uuesti teisele ressursile väljastatud token.
3. Staatilise client ID-ga proxy-serverite puhul vaadake üle nõusolekuvoog: kliendipõhine register, nõusolekulehe sisu, kaitse raamistamise vastu.
4. Salvestage iga serveri tööriistade loend baseline'ina, kärpige see ülesande vajaduseni, andke igale tööriistale minimaalsete õigustega identiteet ning nõudke kirjutamis- ja kustutamistööriistade puhul inimese kinnitust.
5. Serveripoolsete klientide puhul tehke SSRF-test vaenuliku testserveriga.
6. Korrake samme 2-5 iga kord, kui server uuendub, saab uue tööriista või muudab oma scope'e.

Välise ülevaatuse jaoks vaadake meie konsultatsiooniteenust. Meie penetratsioonitestimise teenus saab teie lahenduse vastu läbi viia token'i- ja nõusolekukontrollid.