Burp-MCP-Unrestricted: что же в нём действительно unrestricted — 27 июля 2026 г. в 10:06:53.592
Burp-MCP-Unrestricted: что же в нём действительно unrestricted Появился Burp-MCP-Unrestricted — неофициальная копия PortSwigger/mcp-server с восемью дополнительными MCP-инструментами. Автор решает прикладную проблему: официальный сервер годится для работы в Burp, но агенту неудобно вести через него длинную сессию. В upstream нельзя прочитать историю прокси с конца: get_proxy_http_history просто перебирает api.proxy().history(). Каждый элемент ещё и обрезается на 5000 символах. Нет доступа к site map как к списку найденных URL. В Repeater можно создать вкладку, но нельзя нажать Send и забрать ответ, что явно минус Форк добавляет get_proxy_http_history_latest, get_site_map, active_scan_url, crawl_url и четыре инструмента для Repeater. maxLength=0 снимает обрезание ответа у двух новых инструментов чтения. Для Burp Pro это делает связку с агентом удобнее: можно взять свежий запрос, пройтись по site map, запустить crawl или audit, а затем работать с Repeater без постоянного переключения в UI. Но я посмотрел на этот проект с помощью diff'а: В официальной версии HTTP-запросы проходят HttpRequestSecurity.checkHttpRequestPermission; доступ к данным — checkDataAccessOrDeny. По умолчанию оба действия требуют подтверждения. В форке дефолты меняются на обратные: подтверждение запросов и чтения выключено, а изменение конфигурации включено. Это было бы обычным компромиссом в пользу автоматизации, если бы новые инструменты пользовались теми же проверками. Они не пользуются. active_scan_url вызывает startAudit, crawl_url — startCrawl, repeater_send нажимает кнопку через Swing, а repeater_read читает текст из видимых редакторов. В этих обработчиках нет вызовов ни checkHttpRequestPermission, ни checkDataAccessOrDeny. То есть возврат галочек в MCP+ не ставит новые операции под тот же контроль, что есть у upstream. MCP-клиент всё равно сможет начать сканирование, crawl, отправить запрос из Repeater или прочитать его панели. Сервер слушает 127.0.0.1, поэтому это не уяза. Риск появляется в локальной связке Burp + MCP-клиент: доступ к содержимому HTTP-трафика и право действовать от имени Burp оказываются у одного агента без отдельного подтверждения. Отдельно про доверие к билду. Репозиторий создан 25 июля, в истории один коммит от одного автора; GitHub считает его самостоятельным репозиторием, а не техническим fork. В изменённом Tools.kt добавлено 262 строки, тестов на новые инструменты нет. Это не обвинение автора и нисколечки не признак бэкдора. Но готовый JAR от такого проекта я бы не загружал в рабочий Burp: проще собрать из зафиксированного commit и сначала посмотреть diff. Форк полезен как набор конкретных доработок для лабораторной или выделенной машины. Для регулярной работы ему не хватает трёх проверок: gate перед startAudit/startCrawl, gate перед repeater_send и контроль доступа перед repeater_read. Туто: upstream, добавленные инструменты, изменённые дефолты. @poxek | @poxek_ai | MAX