OAuth у MCP наладжаны — але 96,6% сервераў усё роўна маюць адну дзірку

Бяспечная аўтарызацыя аддаленага MCP-сервера патрабуе праверак на ўсім шляху: ад рэгістрацыі кліента і вяртання кода да прызначэння токена і правоў на выклік інструмента. У даследаванні аддаленых MCP-сервераў хаця б адну памылку дынамічнай рэгістрацыі кліентаў выявілі ў 115 з 119 прыдатных для праверкі OAuth-сервераў, або ў 96,6% выбаркі. Даследчыкі адбіралі серверы з дынамічнай рэгістрацыяй, таму вынік не апісвае ўсе MCP-серверы.

Паслядоўнасць наладкі такая: замацаваць кліента за дапушчальным адрасам вяртання, абараніць код аўтарызацыі, выдаць токен для канкрэтнага MCP-сервера і правяраць права на дзеянне пры кожным запыце. Сам факт, што кліент прайшоў OAuth-працэс, не пацвярджае правільнасць гэтых асобных праверак.

Рэгістрацыя кліента: каму вернецца код

Пры рэгістрацыі кліента сервер аўтарызацыі звязвае яго client_id з дазволенымі redirect URI. Падчас аўтарызацыі ён павінен параўноўваць пададзены адрас з зарэгістраваным значэннем дакладна. Праверце абодва этапы: нават бездакорнае параўнанне пазней не дапаможа, калі ананімны заяўнік раней змог зарэгістраваць уласны адрас як дазволены.

Для ўмоўнага кліента з адрасам вяртання https://client.example/callback бяспечная праверка адхіліць іншы дамен, зменены шлях і дадатковы адрас, якога няма ў яго рэгістрацыі. Небяспечная рэгістрацыя прымае любы redirect URI і выдае client_id без абмежаванняў: зламыснік можа атрымаць сапраўдны ідэнтыфікатар для свайго адраса, а потым падвесці карыстальніка да згоды на аўтарызацыю. Менавіта прыём адвольнага адраса ад ананімнага заяўніка быў найбольш частай канкрэтнай памылкай у даследаванай групе.

Калі вашым кліентам дастаткова папярэдняй рэгістрацыі, не адкрывайце endpoint дынамічнай рэгістрацыі. Калі яна патрэбная, вызначце дапушчальныя redirect URI і палітыку даверу да новых кліентаў; не лічыце выданы client_id доказам іх надзейнасці. Пры згодзе карыстальнік павінен бачыць, якому кліенту і адрасу вяртання ён дазваляе доступ.

Код аўтарызацыі: прывяжыце абмен да пачатага запыту

Кліенту патрэбны PKCE: ён перадае code_challenge пры пачатку аўтарызацыі, а адпаведны code_verifier — пры абмене кода на токен. Сервер аўтарызацыі мусіць адхіляць запыт без патрэбнага challenge і абмен з няправільным verifier. Наяўнасць параметраў у звычайным паспяховым запыце яшчэ не паказвае, ці будзе сервер прымушаць кліента імі карыстацца.

Параметр state звязвайце з сесіяй і канкрэтным пачатым запытам; адказ з адсутным або чужым state адхіляйце. Код аўтарызацыі павінен працаваць аднойчы, і паўторны абмен ужо выкарыстанага кода мусіць завяршацца адмовай. Калі MCP-сервер сам пачынае аўтарызацыю ў знешнім сэрвісе, праверкі кода і кантэксту патрэбныя таксама на гэтым асобным этапе.

Токен: адзін атрымальнік і асобны доступ да знешняга API

Патрабаванні бяспекі MCP абавязваюць кліента пазначаць мэтавы рэсурс праз параметр resource ў запытах аўтарызацыі і токена, а сервер — прымаць толькі токены, выдадзеныя менавіта для яго. Пры ўваходным запыце правярайце прызначэнне токена: калі ён выдадзены для іншага API, правільны подпіс сам па сабе не дае доступу да MCP-інструментаў.

Умоўны бяспечны сцэнар: кліент атрымлівае токен для https://mcp.example, і гэты сервер адхіляе токен, прызначаны для https://api.example. Небяспечны сцэнар: сервер давярае любому сапраўднаму токену таго самага пастаўшчыка ідэнтычнасці без праверкі атрымальніка. Такая памылка дазваляе выкарыстоўваць паўнамоцтвы за межамі рэсурсу, для якога іх выдалі.

Калі інструмент MCP звяртаецца да знешняга API, сервер выступае перад ім асобным кліентам. Для гэтага звароту патрэбны асобны токен з адпаведным прызначэннем і правамі; перадаваць уваходны токен MCP-кліента далей нельга. Так захоўваецца мяжа паміж дазволам карыстальніка на доступ да MCP-сервера і дазволам самога сервера на дзеянне ў знешняй сістэме.

Правы: вузкі scope і рашэнне для канкрэтнага дзеяння

Практычнае кіраўніцтва OWASP для MCP рэкамендуе OAuth 2.1 або OIDC, кароткачасовыя токены з вузкімі scopes і паўторную праверку подпісу, прызначэння і тэрміну дзеяння токена перад кожным выклікам інструмента або доступам да рэсурсу. Перад адчувальным дзеяннем трэба зноў праверыць і дазвол. Ідэнтыфікатар сесіі дапамагае захоўваць стан злучэння, але не служыць самастойным пацвярджэннем асобы і правоў.

Супастаўце кожны інструмент з мінімальным правам, якое патрэбна для яго аперацыі. Умоўны інструмент пошуку запісаў можа патрабаваць толькі права чытання; выдаленне патрабуе асобнага права. Але нават пры патрэбным scope сервер павінен вызначыць, ці мае гэты карыстальнік доступ да канкрэтнага запісу або набору даных. Інакш права на аперацыю ператворыцца ў доступ да чужых аб’ектаў.

Не выдавайце шырокі scope усім кліентам дзеля зручнасці наступных падключэнняў. Кароткі тэрмін дзеяння скарачае час, на працягу якога можна выкарыстаць выкрадзены токен; вузкі scope абмяжоўвае даступныя з ім дзеянні. Гэтыя меры вырашаюць розныя задачы, таму адна не замяняе другую.

Праверка перад адкрыццём доступу

Правярайце адмову на кожнай мяжы аўтарызацыі, а не толькі паспяховае падключэнне. Запускайце такія пробы са сваімі тэставымі кліентамі і ўліковымі запісамі:

1. Зарэгіструйце кліента з дазволеным redirect URI, затым падайце іншы адрас пры аўтарызацыі. Асобна паспрабуйце зарэгістраваць новага кліента з недапушчальным адрасам: абодва варыянты павінны быць адхіленыя паводле вашай палітыкі.
2. Паўтарыце аўтарызацыю без PKCE, абмяняйце код з няправільным verifier, падайце чужы state і паўторна выкарыстайце ўжо пагашаны код. На кожным этапе чакайце адмовы да выдачы токена.
3. Адпраўце MCP-серверу сапраўдны токен для іншага рэсурсу. Інструмент не павінен выконвацца, нават калі подпіс токена правільны.
4. Выклічце інструмент змены даных з правам толькі на чытанне, а інструмент чытання — для аб’екта, недаступнага карыстальніку. Абодва запыты павінны спыніцца да дзеяння з данымі.
5. Паўтарыце дазволены выклік пасля заканчэння тэрміну дзеяння токена і праверце зварот сервера да знешняга API. Пратэрмінаваны токен трэба адхіліць, а знешні API павінен атрымаць асобны, прызначаны для яго токен.

Для інструментаў, якія выконваюць адчувальныя дзеянні або апрацоўваюць недавераны ўвод, пасля аўтарызацыі патрэбны таксама кантроль самога дзеяння і праверка ўваходных даных. Дазвол карыстальніка вызначае межы доступу, але не робіць любыя параметры выкліку бяспечнымі.

Чытайце таксама:

• GitHub ці GitLab на сваім серверы: ліцэнзія не аплачвае адміністраванне
• ШІ закранае кожную чацвёртую працу — але гэта яшчэ не прагноз звальнення
• Першыя крыптабанкі Беларусі зарэгістраваныя, але працаваць яшчэ нельга