D2
Администратор
- Регистрация
- 19 Фев 2025
- Сообщения
- 4,380
- Реакции
- 0
Введение
Всех привествую. В прошлой статье мы с вами посмотрели как взаимодействовать с фреймворком при помощи RPC-api. Однако, как вы заметили, это апи не лишено нескольких существенных минусов, которые чуть усложняют работу с ним. Но, так как функция удаленного управления через апи для такого фреймворка это вещь очень полезная, логическое ее развитие и улучшение было лишь вопросом времени.
Поэтому, в пятой версии фреймворка разработчики добавили возможность взаимодействовать с фреймворком через JSON-API, которое в отличие от своего предшественника имеет ряд приемуществ. Но и этим дело не ограничилось – в последних версиях metasploit повился веб-сервис для базы данных, который предоставляет в том числе API для взаимодействия со всеми сущностями в базе данных.
Именно об этих двух api я и постараюсь рассказать в этой статье.
Messagepack-RPC-api VS JSON-RPC-api
Так как мы с вами уже знакомы с Messagepack-RPC-api метасплоита (а если нет – рекомендую посмотреть предыдущую статью цикла), начинать с полного нуля нам с вами не придется. Несмотря на то, что в использовании апи довольно сильно различаются, общая идея остается примерно одинаковой. Поэтому, прежде чем приступать, предлагаю определиться – что у этих версий общего, а чем они различаются.
Схожие черты:
Несмотря на большое количество различий, общая суть апи осталась неизменной. Под капотом, обе версии используют одинаковые методы для работы с ядром фреймоврка, если вы решите покопаться в файлах фреймворка, вы это увидите. Отличаются лишь интерфейсы управления и способ взаимодействия. А принцип тот же – отправляем запрос на один определнный url, в теле запроса указываем команду (метод), при необходимости доавляем параметры команды, в ответ получаем результат либо статус операции. Забегая вперед, многие группы и методы, которые мы использовали в обычном RPC-api точно так же работают и здесь. Но, способ работы с этими методами очень сильно отличается и стал куда более удобным. Об этом и поговорим далее
Различия:
1. Первое существенно различие апи – стандартизация. Как вы помните, обычное RPC-api было собранно видимо по собственному виденью разработчиков и не имело общего формата ответов, который из которых для каждого запроса, был разным, не имеющий общего шаблона. В случае же с JSON-API разработчики взяли за основу стандарт JSON-API-2.0 про который вы можете почитать тут. А это, в свою чередь, значит что запросы теперь стандартизированы, ответы тоже, а так же используются HTTP-коды для ответов (не всегда, но разработчики местами постарались), и прочие вещи, которые здорово упрощают разработку клиентов под эти API.
2. Формат запросов и ответов. Как вы помните, в обычном RPC, процесс отправки запроса выглядел так – сначала формируем строку, которая в большинстве случаев содержит массив с элементами в виде команды, токена доступа, и параметрами команды. Далее заворачиваем все это дело в messagepack, и кладем в тело запроса, в хэдере которого указываем что это messagepack. Далее получаем ответ, который так же запакован в mesaagepack, и который еще надо распаковать и привести в удобночитаемый вид. В случае же c JSON-API все это сильно упростилось, сделав разработчикам клиентов жизнь куда проще. Здесь просто формируется запрос, в тело которого кладется не запакованный массив, а обычная json-структура определнного вида (какого именно далее в статье), и ответ так же приходит определенного вида. Так как json является очень распостраненным способом предачи данных в http-протокле, работа с ним не вызовет никаких проблем у любого начинающего кодера в любом из популярных язков программирования.
3. Авторизация. Еще одно существенное отличие, которое появилось в этой версии апи, это авторизация через bearer токен. Это довольно распостраненная практика при работе с апи. Но, забегая вперед, важным моментом так же является то, что токен этот будет общим для этого апи, и того что используется c msfdb. Это достигается за счет того, что пользователь не просто указывается при запуске сервиса, а создается в бд, и на основе его данных создается один токен для этого пользователя, с помощью которого он и может получить доступ к функциям апи. Таким образом мы получаем общую систему авторизации для как минимум двух сервисов.
Несмотря на то, что json-rpc-api имеет ряд очевидных приемуществ перед обычным rpc-api, вам следует понимать, что это апи еще не доработано до конца и разработчики активно его дорабатывают. А это значит, что от версии к версии могут появляться различные изменения, а так же вы можете столкнуться с тем, что какие-то механизмы работают не так как ожидалось. Помимо этого, большим минусом на данный момент является отсутствие внятной документации, описывающей все методы апи, порядок и способ взаимодействия с ним. Максимум что вы найдете в документации метасплойта – это несколько примеров использования основных методов через curl.
Но, несмотря на все эти минусы, это апи может быть очень полезным. Далее мы в этом и убедимся ,а пока давайте посмотрим что оно вообще из себя представляет.
Описание JSON-RPC-API и его методов
После того, как мы с вами запустили сервер, мы можем приступать к написанию кода. Однако, прежде чем это делать нам желательно понимать с чем именно мы имеем дело в теории. Поэтому, давайте сначала посмотрим на само апи:
Первое что нам нужно знать – на какой url отправлять запросы. В нашем случае это будет
http://<ip>:<port>/api/v1/json-rpc
Второй момент – струкутра запросов и ответов. Так как за основу взят стандарт JSON-RPC второй версии, структура запросов и ответов будет выглядеть согласно стандарту.
Это всегда будет POST-запрос, со следующими хэдерами
'Content-Type: application/json' – показывающий с чем мы работаем
'Authorization: Bearer <token>' - для авторизации
Тело запроса будет вот таким:
JSON: Скопировать в буфер обмена
Мы передаем
1. Версию используемого json-rpc (всегда будет 2.0).
2. Метод, который хотим вызывать.
3. Свой айдишник, который будет служить дополнительным идентификатором запросов.
4. Параметры для вызываемого метода. Если таковых не требуется, то отправляем пустой массив.
Ответ будет выглядеть вот так.
JSON: Скопировать в буфер обмена
Если же что-то пойдет не так, то ответ не особо изменится – ошибка и ее описание придется в “result”.
В результате мы получаем довольно удобную станартизированную систему общения с сервером, в которой довольно просто отправлять запросы, расшифровывать ответы, и что не менее важно - отлавливать ошибки.
И что еще следует обязательно упомянуть – это то, что количество методов, поддерживаемых json_rpc_api крупнее, чем в случае с обычным RPC. Часть очень полезных групп и методов часто не работают как положено с апи, работающим через messagepack. Теперь о них чуть Скачать
Всех привествую. В прошлой статье мы с вами посмотрели как взаимодействовать с фреймворком при помощи RPC-api. Однако, как вы заметили, это апи не лишено нескольких существенных минусов, которые чуть усложняют работу с ним. Но, так как функция удаленного управления через апи для такого фреймворка это вещь очень полезная, логическое ее развитие и улучшение было лишь вопросом времени.
Поэтому, в пятой версии фреймворка разработчики добавили возможность взаимодействовать с фреймворком через JSON-API, которое в отличие от своего предшественника имеет ряд приемуществ. Но и этим дело не ограничилось – в последних версиях metasploit повился веб-сервис для базы данных, который предоставляет в том числе API для взаимодействия со всеми сущностями в базе данных.
Именно об этих двух api я и постараюсь рассказать в этой статье.
Messagepack-RPC-api VS JSON-RPC-api
Так как мы с вами уже знакомы с Messagepack-RPC-api метасплоита (а если нет – рекомендую посмотреть предыдущую статью цикла), начинать с полного нуля нам с вами не придется. Несмотря на то, что в использовании апи довольно сильно различаются, общая идея остается примерно одинаковой. Поэтому, прежде чем приступать, предлагаю определиться – что у этих версий общего, а чем они различаются.
Схожие черты:
Несмотря на большое количество различий, общая суть апи осталась неизменной. Под капотом, обе версии используют одинаковые методы для работы с ядром фреймоврка, если вы решите покопаться в файлах фреймворка, вы это увидите. Отличаются лишь интерфейсы управления и способ взаимодействия. А принцип тот же – отправляем запрос на один определнный url, в теле запроса указываем команду (метод), при необходимости доавляем параметры команды, в ответ получаем результат либо статус операции. Забегая вперед, многие группы и методы, которые мы использовали в обычном RPC-api точно так же работают и здесь. Но, способ работы с этими методами очень сильно отличается и стал куда более удобным. Об этом и поговорим далее
Различия:
1. Первое существенно различие апи – стандартизация. Как вы помните, обычное RPC-api было собранно видимо по собственному виденью разработчиков и не имело общего формата ответов, который из которых для каждого запроса, был разным, не имеющий общего шаблона. В случае же с JSON-API разработчики взяли за основу стандарт JSON-API-2.0 про который вы можете почитать тут. А это, в свою чередь, значит что запросы теперь стандартизированы, ответы тоже, а так же используются HTTP-коды для ответов (не всегда, но разработчики местами постарались), и прочие вещи, которые здорово упрощают разработку клиентов под эти API.
2. Формат запросов и ответов. Как вы помните, в обычном RPC, процесс отправки запроса выглядел так – сначала формируем строку, которая в большинстве случаев содержит массив с элементами в виде команды, токена доступа, и параметрами команды. Далее заворачиваем все это дело в messagepack, и кладем в тело запроса, в хэдере которого указываем что это messagepack. Далее получаем ответ, который так же запакован в mesaagepack, и который еще надо распаковать и привести в удобночитаемый вид. В случае же c JSON-API все это сильно упростилось, сделав разработчикам клиентов жизнь куда проще. Здесь просто формируется запрос, в тело которого кладется не запакованный массив, а обычная json-структура определнного вида (какого именно далее в статье), и ответ так же приходит определенного вида. Так как json является очень распостраненным способом предачи данных в http-протокле, работа с ним не вызовет никаких проблем у любого начинающего кодера в любом из популярных язков программирования.
3. Авторизация. Еще одно существенное отличие, которое появилось в этой версии апи, это авторизация через bearer токен. Это довольно распостраненная практика при работе с апи. Но, забегая вперед, важным моментом так же является то, что токен этот будет общим для этого апи, и того что используется c msfdb. Это достигается за счет того, что пользователь не просто указывается при запуске сервиса, а создается в бд, и на основе его данных создается один токен для этого пользователя, с помощью которого он и может получить доступ к функциям апи. Таким образом мы получаем общую систему авторизации для как минимум двух сервисов.
Несмотря на то, что json-rpc-api имеет ряд очевидных приемуществ перед обычным rpc-api, вам следует понимать, что это апи еще не доработано до конца и разработчики активно его дорабатывают. А это значит, что от версии к версии могут появляться различные изменения, а так же вы можете столкнуться с тем, что какие-то механизмы работают не так как ожидалось. Помимо этого, большим минусом на данный момент является отсутствие внятной документации, описывающей все методы апи, порядок и способ взаимодействия с ним. Максимум что вы найдете в документации метасплойта – это несколько примеров использования основных методов через curl.
Но, несмотря на все эти минусы, это апи может быть очень полезным. Далее мы в этом и убедимся ,а пока давайте посмотрим что оно вообще из себя представляет.
Описание JSON-RPC-API и его методов
После того, как мы с вами запустили сервер, мы можем приступать к написанию кода. Однако, прежде чем это делать нам желательно понимать с чем именно мы имеем дело в теории. Поэтому, давайте сначала посмотрим на само апи:
Первое что нам нужно знать – на какой url отправлять запросы. В нашем случае это будет
http://<ip>:<port>/api/v1/json-rpc
Второй момент – струкутра запросов и ответов. Так как за основу взят стандарт JSON-RPC второй версии, структура запросов и ответов будет выглядеть согласно стандарту.
Это всегда будет POST-запрос, со следующими хэдерами
'Content-Type: application/json' – показывающий с чем мы работаем
'Authorization: Bearer <token>' - для авторизации
Тело запроса будет вот таким:
JSON: Скопировать в буфер обмена
Код:
{
"jsonrpc": "2.0",
"method": "my.method",
"id": 1,
"params": []
}1. Версию используемого json-rpc (всегда будет 2.0).
2. Метод, который хотим вызывать.
3. Свой айдишник, который будет служить дополнительным идентификатором запросов.
4. Параметры для вызываемого метода. Если таковых не требуется, то отправляем пустой массив.
Ответ будет выглядеть вот так.
JSON: Скопировать в буфер обмена
Код:
{
"jsonrpc": "2.0",
"result": {<data>},
"id": 1
}Если же что-то пойдет не так, то ответ не особо изменится – ошибка и ее описание придется в “result”.
В результате мы получаем довольно удобную станартизированную систему общения с сервером, в которой довольно просто отправлять запросы, расшифровывать ответы, и что не менее важно - отлавливать ошибки.
И что еще следует обязательно упомянуть – это то, что количество методов, поддерживаемых json_rpc_api крупнее, чем в случае с обычным RPC. Часть очень полезных групп и методов часто не работают как положено с апи, работающим через messagepack. Теперь о них чуть Скачать
View hidden content is available for registered users!