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
Появился 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