Xml rpc что это

XML-RPC — Краткое руководство

RPC обозначает Удаленный вызов процедур. Как видно из его названия, это механизм для вызова процедуры или функции, доступной на удаленном компьютере. RPC — намного более старая технология, чем Интернет. По сути, RPC предоставляет разработчикам механизм определения интерфейсов, которые можно вызывать по сети. Эти интерфейсы могут быть простыми, как один вызов функции, или сложными, как большой API.

Что такое XML-RPC?

XML-RPC — один из самых простых и надежных подходов к веб-сервисам, который позволяет компьютерам легко вызывать процедуры на других компьютерах.

XML-RPC позволяет программам выполнять вызовы функций или процедур по сети.

XML-RPC использует протокол HTTP для передачи информации с клиентского компьютера на серверный компьютер.

XML-RPC использует небольшой словарь XML для описания характера запросов и ответов.

Клиент XML-RPC указывает имя процедуры и параметры в запросе XML, а сервер возвращает либо ошибку, либо ответ в ответе XML.

Параметры XML-RPC представляют собой простой список типов и содержимого. Структуры и массивы являются наиболее сложными доступными типами.

XML-RPC не имеет понятия об объектах и ​​не имеет механизма для включения информации, которая использует другой словарь XML.

Однако с помощью XML-RPC и веб-сервисов Интернет становится набором процедурных соединений, в которых компьютеры обмениваются информацией по тесно связанным путям.

XML-RPC появился в начале 1998 года; оно было опубликовано UserLand Software и первоначально внедрено в их продукт Frontier.

XML-RPC позволяет программам выполнять вызовы функций или процедур по сети.

XML-RPC использует протокол HTTP для передачи информации с клиентского компьютера на серверный компьютер.

XML-RPC использует небольшой словарь XML для описания характера запросов и ответов.

Клиент XML-RPC указывает имя процедуры и параметры в запросе XML, а сервер возвращает либо ошибку, либо ответ в ответе XML.

Параметры XML-RPC представляют собой простой список типов и содержимого. Структуры и массивы являются наиболее сложными доступными типами.

XML-RPC не имеет понятия об объектах и ​​не имеет механизма для включения информации, которая использует другой словарь XML.

Однако с помощью XML-RPC и веб-сервисов Интернет становится набором процедурных соединений, в которых компьютеры обмениваются информацией по тесно связанным путям.

XML-RPC появился в начале 1998 года; оно было опубликовано UserLand Software и первоначально внедрено в их продукт Frontier.

Почему XML-RPC?

Если вам нужно интегрировать несколько вычислительных сред, но вам не нужно обмениваться сложными структурами данных напрямую, вы обнаружите, что XML-RPC позволяет быстро и легко устанавливать связь.

Даже если вы работаете в одной среде, вы можете обнаружить, что подход RPC упрощает подключение программ, которые имеют разные модели данных или ожидания обработки, и что он может обеспечить легкий доступ к повторно используемой логике.

XML-RPC является отличным инструментом для установления различных соединений между компьютерами.

XML-RPC предлагает интеграторам возможность использовать стандартный словарь и подход для обмена информацией.

Наиболее очевидная область применения XML-RPC — это подключение различных сред, позволяющих Java общаться с Perl, Python, ASP и так далее.

XML-RPC является отличным инструментом для установления различных соединений между компьютерами.

XML-RPC предлагает интеграторам возможность использовать стандартный словарь и подход для обмена информацией.

Наиболее очевидная область применения XML-RPC — это подключение различных сред, позволяющих Java общаться с Perl, Python, ASP и так далее.

Технический обзор XML-RPC

XML-RPC состоит из трех относительно небольших частей:

Модель данных XML-RPC : набор типов для использования при передаче параметров, возвращаемых значений и ошибок (сообщений об ошибках).

Структуры запросов XML-RPC : HTTP-запрос POST, содержащий информацию о методах и параметрах.

Структуры ответов XML-RPC : HTTP-ответ, содержащий возвращаемые значения или информацию об ошибках.

Модель данных XML-RPC : набор типов для использования при передаче параметров, возвращаемых значений и ошибок (сообщений об ошибках).

Структуры запросов XML-RPC : HTTP-запрос POST, содержащий информацию о методах и параметрах.

Структуры ответов XML-RPC : HTTP-ответ, содержащий возвращаемые значения или информацию об ошибках.

Мы будем изучать все эти три компонента в следующих трех главах.

XML-RPC — модель данных

Спецификация XML-RPC определяет шесть основных типов данных и два составных типа данных, которые представляют комбинации типов.

Основные типы данных в XML-RPC

Следующий массив содержит четыре целых числа:

Массивы также могут содержать смеси разных типов, как показано здесь:

Создание многомерных массивов просто — просто добавьте массив внутри массива:

Простая структура может выглядеть так:

Таким образом, вы можете реализовать практически все типы данных, поддерживаемые любым языком программирования.

XML-RPC — формат запроса

Запросы XML-RPC представляют собой комбинацию содержимого XML и заголовков HTTP. Содержимое XML использует структуру типизации данных для передачи параметров и содержит дополнительную информацию, определяющую, какая процедура вызывается, а заголовки HTTP предоставляют оболочку для передачи запроса через Интернет.

Заголовки HTTP для этих запросов будут отражать отправителей и содержимое. Базовый шаблон выглядит следующим образом:

В собранном виде весь запрос будет выглядеть так:

Это обычный HTTP-запрос с тщательно сконструированной полезной нагрузкой.

XML-RPC — Формат ответа

Ответы очень похожи на запросы, с несколькими дополнительными поворотами. Если ответ успешен — процедура была найдена, выполнена правильно и вернула результаты — тогда ответ XML-RPC будет очень похож на запрос, за исключением того, что элемент methodCall заменяется элементом methodResponse, а элемент methodName отсутствует:

Ответ XML-RPC может содержать только один параметр.

Этот параметр может быть массивом или структурой, поэтому можно возвращать несколько значений.

Всегда требуется возвращать значение в ответе. «Значение успеха» — возможно, логическое значение true (1).

Ответ XML-RPC может содержать только один параметр.

Этот параметр может быть массивом или структурой, поэтому можно возвращать несколько значений.

Всегда требуется возвращать значение в ответе. «Значение успеха» — возможно, логическое значение true (1).

Как и запросы, ответы упакованы в HTTP и имеют заголовки HTTP. Все ответы XML-RPC используют код ответа 200 OK, даже если в сообщении содержится ошибка. Заголовки используют общую структуру, аналогичную структуре запросов, и типичный набор заголовков может выглядеть следующим образом:

XML-RPC требует только поддержки HTTP 1.0, но HTTP 1.1 совместим.

Тип содержимого должен быть установлен на text / xml.

Заголовок Content-Length указывает длину ответа в байтах.

XML-RPC требует только поддержки HTTP 1.0, но HTTP 1.1 совместим.

Тип содержимого должен быть установлен на text / xml.

Заголовок Content-Length указывает длину ответа в байтах.

Полный ответ с заголовками и полезной нагрузкой будет выглядеть следующим образом:

После доставки ответа от сервера XML-RPC клиенту XML-RPC соединение закрывается. Последующие запросы необходимо отправлять как отдельные соединения XML-RPC.

XML-RPC — формат ошибок

Ошибка также будет иметь код ошибки. XML-RPC вообще не стандартизирует коды ошибок. Вам нужно проверить документацию для конкретных пакетов, чтобы увидеть, как они обрабатывают сбои.

Реакция на ошибку также может выглядеть так:

XML-RPC — Примеры

Чтобы продемонстрировать XML-RPC, мы собираемся создать сервер, который использует Java для обработки сообщений XML-RPC, и мы создадим Java-клиент для вызова процедур на этом сервере.

Java-часть беседы использует Apache XML-RPC Apache XML Project, доступный по адресу http://xml.apache.org/xmlrpc/.

XML-RPC клиент

Давайте посмотрим, что произошло в приведенном выше примере клиента.

Пакет Java org.apache.xmlrpc содержит классы для клиентов Java XML-RPC и сервера XML-RPC, например XmlRpcClient.

Пакет java.util необходим для класса Vector.

Функция server.execute (…) отправляет запрос на сервер. Сумма процедуры (17,13) вызывается на сервере, как если бы это была локальная процедура. Возвращаемым значением вызова процедуры всегда является Object.

Здесь «образец» обозначает обработчик, который определен на сервере.

Обратите внимание, что все параметры вызова процедуры всегда собираются в векторе.

Класс XmlRpcClient создается путем указания «веб-адреса» сервера, за которым следует / RPC2.

localhost — означает локальный компьютер

Вы можете указать номер IP вместо localhost, например, 194.80.215.219

Вы можете указать доменное имя как xyz.dyndns.org

Вы можете указать номер порта вместе с именем домена как xyz.dyndns.org:8080. Порт по умолчанию — 80

Обратите внимание, что результатом удаленного вызова процедуры всегда является Object, и он должен быть приведен к соответствующему типу.

Пакет Java org.apache.xmlrpc содержит классы для клиентов Java XML-RPC и сервера XML-RPC, например XmlRpcClient.

Пакет java.util необходим для класса Vector.

Функция server.execute (…) отправляет запрос на сервер. Сумма процедуры (17,13) вызывается на сервере, как если бы это была локальная процедура. Возвращаемым значением вызова процедуры всегда является Object.

Здесь «образец» обозначает обработчик, который определен на сервере.

Обратите внимание, что все параметры вызова процедуры всегда собираются в векторе.

Класс XmlRpcClient создается путем указания «веб-адреса» сервера, за которым следует / RPC2.

localhost — означает локальный компьютер

Вы можете указать номер IP вместо localhost, например, 194.80.215.219

Вы можете указать доменное имя как xyz.dyndns.org

Вы можете указать номер порта вместе с именем домена как xyz.dyndns.org:8080. Порт по умолчанию — 80

Обратите внимание, что результатом удаленного вызова процедуры всегда является Object, и он должен быть приведен к соответствующему типу.

Из-за вышеуказанного вызова клиент отправляет на сервер следующее сообщение. Обратите внимание, что это обрабатывается внутри server.execute (…), и вы не имеете к этому никакого отношения.

XML-RPC сервер

Ниже приведен исходный код сервера XML-RPC, написанный на Java. Он использует встроенные классы, доступные в org.apache.xmlrpc. *

Давайте посмотрим, что мы сделали на приведенном выше примере сервера.

Пакет org.apache.xmlrpc содержит класс WebServer для реализации сервера XML-RPC.

Сумма процедуры, которая вызывается удаленно, реализована как открытый метод в классе.

Экземпляр того же серверного класса затем связывается с обработчиком, который доступен клиенту.

Сервер инициализируется номером порта (здесь: 80).

Пакет org.apache.xmlrpc содержит класс WebServer для реализации сервера XML-RPC.

Сумма процедуры, которая вызывается удаленно, реализована как открытый метод в классе.

Экземпляр того же серверного класса затем связывается с обработчиком, который доступен клиенту.

Сервер инициализируется номером порта (здесь: 80).

Для вызова, упомянутого в данном примере клиента, сервер отправляет клиенту следующий ответ:

Теперь ваш сервер готов, поэтому скомпилируйте и запустите его, как показано ниже:

Теперь, чтобы проверить функциональность, позвоните на этот сервер следующим образом:

XML-RPC — Резюме

Из этого руководства вы узнали, что такое XML-RPC и зачем нам нужен XML-RPC. Мы обсудили его модель данных, а также формат сообщения запроса и ответа, которым должен обмениваться клиент и сервер. Мы привели один пример, чтобы продемонстрировать, как клиент и сервер XML-RPC работают для обмена информацией.

XML-RPC — это очень простая концепция с ограниченным набором возможностей. Эти ограничения во многих отношениях являются наиболее привлекательной особенностью XML-RPC, поскольку они существенно снижают сложность реализации протокола и тестирования его совместимости.

Хотя XML-RPC прост, креативное применение простых инструментов может создавать сложные и мощные архитектуры. В тех случаях, когда для взаимодействия требуется множество различных систем, XML-RPC может быть наиболее подходящим наименьшим общим знаменателем.

Что дальше?

Следующим шагом является изучение WSDL и SOAP.

WSDL — это язык на основе XML для описания веб-сервисов и способов доступа к ним.

WSDL описывает веб-службу, а также формат сообщения и подробности протокола для веб-службы.

SOAP — это простой протокол на основе XML, который позволяет приложениям обмениваться информацией по HTTP.

Источник

HackWare.ru

Этичный хакинг и тестирование на проникновение, информационная безопасность

Что такое файл xmlrpc.php и как он влияет на безопасность сайтов WordPress

Что такое XML-RPC?

XML-RPC — это протокол удалённого вызова процедур (RPC), который использует XML для кодирования своих вызовов и HTTP в качестве транспортного механизма.

WordPress задействует этот протокол XML-RPC, который используется для обмена информацией между компьютерными системами по сети. Короче говоря, это система, которая позволяет вам публиковать сообщения в своём блоге WordPress с помощью популярных клиентов веб-журналов, таких как Windows Live Writer, или с помощью мобильного приложения WordPress. Она также необходима, если вы хотите подключиться к таким сервисам, как IFTTT.

Чертовски полезно, если подумать. Но это происходит за счёт рисков для безопасности. К примеру, Xmlrpc brute — инструмент брутфорса WordPress методом xmlrpc.

Это относится к моему сайту на WordPress?

В прошлом были проблемы с безопасностью XML-RPC, поэтому он был отключён по умолчанию.

Однако, начиная с WordPress 3.5.x, в WordPress по умолчанию включён XML-RPC из-за некоторых популярных плагинов WordPress, таких как Jetpack, даже собственное приложение WordPress для Android и iOS использует XML-RPC.

Распространённые уязвимости в XML-RPC

Проблема заключается не в самом XML-RPC, а в том, как файл может быть использован для атаки по подбору пароля на ваш сайт.

WordPress, в котором включён xmlrpc.php для ping-back, трекбэка и т. д., может использоваться злоумышленниками как часть огромного ботнета, вызывающего серьёзные DDoS-атаки.

Проверьте, включён ли xmlrpc.php

Cross Site Port Attack(XSPA) или Подделка запросов на стороне сервера (Server Side Request Forgery(SSRF))

Получен успешный ответ со списком всех доступных методов.

Если вам удалось найти строку pingback.ping в списке методов, тогда файл xmlrpc.php потенциально может быть использован для того, чтобы вызвать DDoS-атаку против хоста жертвы.

Это достигается следующим образом:

Для той же цели можно использовать простой webhook.site.

Здесь нужно заполнить 2 вещи:

(i) IP адрес вашего сервера

(ii) Ссылка на какой-нибудь действительный пост с сайта WordPress, который используется для обратного отклика.

Как только вышеупомянутый запрос отправлен, хост-жертва (115.97.xxx.67tunneling через ngrok) получает запись в своём файле журнала с запросом, исходящим из домена WordPress, подтверждающим ответный пинг. Что видно на скриншоте выше.

Влияние

Это можно автоматизировать с нескольких хостов и использовать для массовых DDoS-атак на жертву.

Этот метод также используется для атак брут-форса паролей с целью кражи учётных данных администратора и других важных учётных данных.

Кроме того, в сети существует множество PoC, касающихся уязвимостей, связанных с XMLRPC.php на веб-сайтах WordPress, некоторые из них: https://www.rapid7.com/db/modules/exploit/unix/webapp/php_xmlrpc_eval

Как отключить WordPress XML-RPC

Есть несколько способов отключить файл xmlrpc.php: как просто заблокировав к нему доступ (даже не потребуется установка плагинов), так и с помощью плагинов WordPress.

Просто вставьте следующий код в свой файл .htaccess, находящийся в корне вашего сайта WordPress:

Это должно отключит XML-RPC на вашем сайте WordPress.

Отключение WordPress XML-RPC в iThemes Security

iThemes Security — отличный плагин, который позволяет повысить безопасность сайтов на WordPress.

XML-RPC

XML-RPC позволяет внешним сервисам получать доступ и изменять содержимое сайта. В частности примером могут служить Jetpack, WordPress мобильное приложение, и пингбэки

Доступные варианты настройки:

Множественные попытки аутентификации запросом XML-RPC

Возможности в XML-RPC позволяют сотни попыток перебора логина/пароля пользователя в одном запросе (в WordPress

Источник

Дао Вебсервиса. (Или да хватит же изобретать велосипеды!)

Недавно на Хабре была опубликована статья под провокационным заголовком и призывом к прекращению изобретений велосипедов в API-строении. Поскольку тема мне интересна, то я просто не мог пройти мимо.
Увы, реальность за хабракатом меня сильно разочаровала — я увидел очередной велосипед, да еще и с квадратными колесами. (Коллеги, ничего личного, только техническое обсуждение.) Правда, авторы честно сказали, что увидели на нескольких сайтах модное слово REST и решили сделать по нему. Только вот поняли они этот «РЭСТ» по-своему, примерно как Дед Щукарь читал и понимал толковый словарь.
В этом топике я призываю по-настоящему покончить с велосипедами в API сайтов. Ведь получается какой анекдот: АПИ разрабатывается для упрощения доступа к сайту и легкости подключения внешних систем, а получается такой, что с ним еще сложнее, чем без него 🙂

Чуть ниже под катом я подпишу смертный приговор всем велосипедам в универсальных API. Чтобы не быть голословным, я все проиллюстрирую примерами.
Но должен предупредить сразу — после прочтения статьи вы не сможете без рвотного рефлекса смотреть на очередной велосипед Васи Пупкина под гордым названием «универсальное API сайта».

Итак на сегодня наиболее распространенными способами доступа к API сайтов являются:
1. XML-RPC.
2. REST (с оговоркой, что это не протокол, а подход).
3. SOAP.

Базовые технологии и сравнение

XML-RPC

Примерно так же просто выглядят сообщения об ошибках. Такой ответ легко распарсить даже человеку, не говоря уже про машину. Такая простота сослужила ему двоякую службу: с одной стороны он не был принят заказчиком и не стал стандартом, а с другой — понравился толпе простых незамороченных программистов. Этим ребятам нужно было простое и надежное средство обмена информацией между системами, они не хотели заморачиваться на такую хрень как красивый УРЛ, схема документа и прочие академизмы. Первое, что они хотели получить — простую работающую систему. И до сих пор XML-RPC помогает им в этом.
Итак:
+ : простота, краткость сообщений, минимальная проверка формата данных,
— : недостаточная строгость, требуется отдельное описание сервиса.

POST /api/object.php?object_id=445&action=delete&user_id=255&auth_key=0Jf4tet5 HTTP/1.1

При этом, если XML-RPC использует из HTTP-протокола только транспортную часть для передачи XML-ки запроса/ответа, то REST задействует HTTP по-полной: здесь и авторизационные заголовки, content-negotiation — предпочтения по формату, языку, кодировке и виду ответа, различные служебные заголовки, безгеморная передача бинарных данных и т.п. Ошибки хорошо описываются кодами HTTP 4xx и 5xx. Можно видеть, что REST — органичная надстройка над HTTP. Это неудивительно ведь Рой — один из разработчиков протокола HTTP. Вообще, чем больше я разбираюсь с этим протоколом тем больше мне кажется, что он опередил свое время лет на 20, и чем дальше развивается веб, тем больше возможностей мы из него используем.
Само тело сообщения может передаваться в разных форматах: классическом XML либо гиковском JSON. Вообще, REST это не протокол, это подход, и как раз здесь заключена его гибкость, он как бы говорит нам: «Ребята, берите базовые принципы, а дальше делайте как вам удобно». Близость к HTTP-протоколу упрощает и ускоряет его обработку веб-серверами.
Итак:
+ : гибкость, простота, скорость обработки (особенно важно для крупных сайтов), органичность протоколу, мультиформатность, компактность.
— : отсутствие строго контроля данных, из практических соображений приходится выходить за рамки идеальной модели.

— Фак май мозг! — воскликнете вы и будете абсолютно правы — Это что же, ради передачи фитюльки на 10 байт мне надо всю эту лабуду писать?
— Да — скажет Логика, и вы, засучив рукава пойдете учить всю эту кучу технологий.

— Сюда еще и XML Schema приплели зачем-то? Какого хрена? А вы уверены, что эти ребята правильно понимают смысл слова «Simple»? — такие мысли будут вас посещать, и это хорошо — вы на верном пути.

Но и это не все: чем больше копаешься в SOAP тем больше всяких разных технологий вылазит на тебя. Когда вы дойдете до WSDL (Язык описания веб-сервисов), вы поймете почему, начиная с какой-то версии, разработчики перестали воспринимать название SOAP как аббревиатуру, а начали понимать буквально — soap («мыло»). В этот момент ваши мысли будет занимать одна идея: почему во всем этом зоопарке технологий отсутствует технология rope («веревка»).

Еще через какое-то время вы воскликните: «Ну нафиг, давайте уж без меня: сами придумали — сами и возитесь. Я вам не машина мегабайты иксэмеля в мозгу парсить!».
Поздравляю: теперь вы постигли дао вебсервисов!

Да! Дао веб-сервиса именно в этом и состоит: это язык общения машин и человеку нафиг не надо туда лезть. Надо просто его использовать. Ведь когда вам нужна какая-то программа, вы ее запускаете, а не лезете в бинарный код, чтобы исполнять его в мозгу. Точно так же вы не отправляете HTTP-запросы руками в командной строке, а используете браузер. Так зачем здесь лезть в эту гопу голыми руками, да еще хвастаться кто залез по локоть, а кто по самое плечо? Надо просто его использовать.

Просветленные API

API сайта и веб-сервисы — это не что-то милостиво спущенное на нас с небес создателями сайта! Это банальная библиотека функций, которую мы можем встроить в свою программу. Этот вывод становится совершенно естественным, когда вы начинаете мыслить глобально за пределами своего компьютера.
Если вам нужна новая уже готовая либа в проекте, что вы делаете? Скорее всего просто скачиваете, устанавливаете и используете? Пишете в начале программы use/require/import/include/… а дальше просто вызываете функции. Почему же работа с веб-библиотекой должна быть сложнее?
Вот теперь, просветлившись, мы можем начать работать с просветленным API.

Сейчас в качестве примера мы 1 минуту сделаем работу с API Аэрофлота, будем подглядывать за табло Шереметьево без отрыва задницы от стула. Я беру свой любимый язык и на нем пишу все примеры. Уверен, в вашем языке есть аналогичные модули. Ну а если их там нет, то самое время задуматься, так ли взаимна ваша любовь 😉

Вот тут аэрофлот подробно расписывает свое чудесное API. На первый взгляд, описание достаточно убогое — чисто перечисление методов и параметров. А как же это вызывать, как парсить, что вообще делать? А это уже не наши заботы — пусть об этом болит голова у машины — она же железная, а свою мне не хочется грузить фуфлом. Поэтому моя задача найти машинночитаемое описание сервиса — тот самый WSDL и скормить его компу.

Стойте-стойте, а как же вся эта лабуда с XML, REST, передачей параметров, парсингом ответов и всеми прочими атрибутами «крутого» API?
Лучше всего на это отвечает фильм «Матрица», кадр из которого мне захотелось вынести в заголовок:

Только перестав думать о ложке сайтовом API как о чем-то реальном, сложном, можно начать гнуть ее комфортно использовать.
Это и есть просветленное API — прозрачное и светлое настолько, что вы его не замечаете, когда работаете. Для вас это просто локальная библиотека. А вся остальная механика с сетевыми заморочками происходит где-то внутри и вас не напрягает.

Как отличить сайтовое API от говна.

Полагаю, внимательный читатель уже догадался?
Когда вместо простой, прозрачной и удобной работы с API сайта вам приходится морочиться с тем, как бы отправить запрос этому сайту и почему он не хочет принимать так старательно сформированный с помощью curl-а запрос, то вывод должен быть однозначным. Вам подсунули неправильный шоколад.

Выводы

В наше время наличие API для сайта претендующего на внимание программистов, всевозможные интеграции и прочее — не повод для гордости, а предмет первой необходимости. Но мало сделать API, даже если вы используете самые модные принципы — надо его сделать удобным и прозрачным. И технология передачи данных здесь имеет значение 10-й важности — это вообще не нужно прикладному программисту. Он должен просто взять и использовать вашу библиотеку.
Если вы хотите получить его внимание, чтобы он потратил свое время на интеграцию с вами — сделайте первый шаг — потратьте время на него. Дайте ему очень простую и понятную библиотеку.
Не надо кивать на то, что «мы сделали как твиттер — дали REST-подобный интерфейс». Вы забываете главное — у твиттера на каждый язык программирования по 5-10 библиотек, которые можно просто скачать и использовать не заморачиваясь на протокол rest/xmlrpc/soap.

Источник

• ← статья 115 уголовного кодекса наказание какое грозит
• Zero trust architecture что это →