xml rpc что это

Xml rpc что это

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

Что же это такое?

Сообщение XML-RPC передается методом POST-протокола HTTP. Сообщения бывают трех типов: запрос, ответ и сообщение об ошибке.

Запрос
XML-RPC запрос Описание
POST /RPC2 HTTP/1.0
User-Agent: MyAPP-Word/5.1.2 (WinNT)
Host: server.localnet.com
Content-Type: text/xml
Content-length: 172

CheckWord

задаются параметры, которые передаются в метод. Секция может содержать произвольное число подэлементов

Типы данных

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

Логический тип данных представляется тегом и может иметь значения 0 (false) или 1 (true). Можно использовать как 1/0, так и символьные константы true/false.

Ответ сервера
XML-RPC ответ Описание
HTTP/1.1 200 OK
Connection: close
Content-Length: 166
Content-Type: text/xml
Date: Fri, 17 Jul 1998 19:55:08 GMT
Server: MyWordCheckSerwer/5.1.2-WinNT

Окончательный вариант

POST /RPC2 HTTP/1.0
User-Agent: MyAppWord/5.1.2 (WinNT)
Host: server.localnet.com
Content-Type: text/xml
Content-length: 172

TranslateWord

Сервер, приняв наш запрос, передает его программе-демону, которая производит парсинг запроса, выделяет из него нужные данные и, найдя (например, по таблице) ссылку на нужный метод, вызывает его с переданными параметрами. Если тип и количество параметров правильные, то по окончании работы метода программа-демон принимает возвращенное значение, преобразует его в XML-описание и формирует ответ.

HTTP/1.1 200 OK
Connection: close
Content-Length: 166
Content-Type: text/xml
Date: Fri, 17 Jul 1998 19:55:08 GMT
Server: MyWordCheckSerwer/5.1.2-WinNT

MyAppWord
Сообщение об ошибке:

HTTP/1.1 200 OK
Connection: close
Content-Length: 166
Content-Type: text/xml
Date: Fri, 17 Jul 1998 19:55:08 GMT
Server: MyWordCheckSerwer/5.1.2-WinNT

faultCode
10

faultString

Перевод невозможен. Слово отсутствует в словаре.

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

Хотя наш пример, на первый взгляд, кажется надуманным и простым, тем не менее, на нем показано, как можно уже сегодня использовать XML-RPC для решения конкретных задач. Конечно, его возможности намного шире, и можно, например, представить себе распределенную ОС, построенную на XML-RPC, или системы визуализации данных, построенные по архитектуре X Window, но с применением все того же XML-RPC.

XML-RPC vs SOAP

Если для реализации удаленного вызова вы используете XML, то у вас есть выбор: использовать XML-RPC или же SOAP (Simple Object Access Protocol). О последней уже написано множество статей, поэтому предлагаем только сравнить обе технологии.

Вот некоторые характеристики, которые определяют различия XML-RPC или же SOAP:

Характеристика XML-RPC SOAP
Скалярные типы данных + +
Структуры + +
Массивы + +
Именованные массивы и структуры +
Определяемые разработчиком кодировки +
Определяемые разработчиком типы данных +
Детализация ошибок + +
Легкость освоения и практического применения +

Конечно, на первый взгляд «минус» в столбце SOAP встречается только единожды. Это создает иллюзию «всереализуемости всего» в нем. Но давайте присмотримся внимательнее. Основные типы данных у обоих конкурентов одинаковые. Но в XML-RPC отсутствует возможность задавать имена для массивов и структур (все структуры и массивы являются «анонимными»). Возможно, это упущение разработчиков, но решить эту проблему можно и самому, например вводя еще одну строковую переменную с именем массива или структуры (в случае, если таких объектов много, можно завести специальный массив «имен массивов»).

Да, ни одна из этих технологий не является панацеей от всех бед и не претендует на полноту. Большинство программистов и разработчиков спецификаций сходятся на том, что:

Выбрав SOAP, сразу смиритесь с тем, что у вашей команды разработчиков (или у вас самих) впереди много головной боли, которая начнется уже с момента чтения спецификаций. Но ведь зато вы будете иметь возможность в конце концов построить систему практически любой сложности и функциональности.

Источник

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

Источник

Описание WEB-сервисов, XML-RPC

Концепция WEB-сервиса связана с созданием такого RPC, который можно включить в HTTP пакеты. Таким образом началась разработка стандарта, определяющего процесс взаимодействия приложений по протоколу HTTP, чтобы приложения могли функционировать на разных аппаратно-программных платформах и использовать различные технологии и языки разработки. С появлением WEB-сервисов началось развитие сервис-ориентированной архитектуры веб-приложений SOA (Service Oriented Architecture). Наибольшее распространение получили следующие протоколы реализации WEB-сервисов :

XML-RPC XML-вызов удалённых процедур
SOAP Simple Object Access Protocol
REST Representational State Transfer

Практический пример создания клиента WEB-сервиса SOAP с отправкой сообщений и получением ответов представлен здесь.

Приведем очень упрощенный пример. Приложение, обрабатывая данные на локальной машине, вызывает некоторый метод. Если реализация этого метода присутствует в программе, то он (процедура/функция) принимает параметры, выполняет действие и возвращает результирующие данные. Но если этот метод является удаленным вызовом, то необходимо знать, где он будет исполняться. Запрос на выполнение метода вместе с параметрами записывается в виде XML-документа и по протоколу HTTP передается по сети на другой компьютер, где из XML-документа извлекается имя метода и его параметры. После завершения работы метода формируется ответ, который передается компьютеру, пославшему запрос. По этому принципу функционируют все системы, и различия в реализации и процедуре обмена не оказывают существенного влияния на его суть.

Применение XML для описания данных существенно упрощает разработку распределенных приложений, снижаются требования к клиенту и серверу. Программы разбора (парсинга) XML сейчас существуют практически для всех операционных систем и на всех языках программирования.

Протокол WEB-сервиса XML-RPC

Протокол WEB-сервиса XML-RPC, разработанный Дэйвом Винером из компании «UserLand Software» в сотрудничестве с Майкрософт в 1998 году, использует в качестве транспортого механизма протокол HTTP и в качестве формата передаваемых данных XML. Это снимает ограничения, налагаемые как на конфигурацию сети, так и на маршрут следования пакетов. Вызовы XML-RPC представляют собой простой тип данных text/xml и свободно проходят сквозь шлюзы везде, где допускается ретрансляция http-трафика. Однако корпорация Майкрософт вскоре сочла этот протокол слишком упрощённым, и начала расширять его функциональность. После нескольких циклов по расширению функциональности, появилась система, ныне известная как SOAP.

Сообщения XML-RPC передаются методом POST протокола HTTP и бывают трех типов: запрос, ответ и сообщение об ошибке.

Пример запроса, вызов метода CheckWord

Сначала определяется стандартный заголовок http-запроса, MIME-тип данных (Content-Type) которых должен быть text/xml. Размер Content-length должен присутствовать обязательно и иметь корректное значение, равное длине передаваемого сообщения.

Корневой узел определяется тегом и не допускает вложенности, а следовательно в запросе можно вызвать только один метод. Тегом определяется название вызываемого метода. Формат названия метода предполагает необязательное наименование класса и наименование метода, разделенные точкой. Можно также включить путь и наименование программы. В примере вызывается метод CheckWord некоторого объекта.

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

Типы данных

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

Пример ответа на вызов метода CheckWord

Ответ включает стандартный http заголовок сервера. MIME-тип данных должен быть text/xml, длина Content-Length должна обязательно присутствовать и иметь значение, равное длине передаваемого сообщения.

Корневой узел ответа начинается с тега и не допускает вложенности. Теги

Если сервер отвечает HTTP-кодом 200 ОК, то это значит, что запрос успешно обработан. Т.е. данные по сети переданы корректно и сервер сумел их обработать. Но метод может вернуть ошибку, которая не будет связана с протоколом, а будет ошибкой бизнес-логики приложения. В этом случае передается соответствующее сообщение и структура, которая описывает код ошибки. Пример возвращения кода ошибки :

В примере ошибка передается в виде структуры из двух элементов: первый элемент содержит код ошибки 2, а второй элемент описывает ошибку.

Источник

Что такое xmlrpc.php в WordPress и зачем его отключать

В WordPress всегда был встроенный инструмент для удалённого обращения к вашему сайту. Действительно, иногда нужно добраться до своего сайта, а компьютер далеко от вас. Длительное время решением был файл под названием xmlrpc.php. Однако последние годы этот файл стал большей проблемой, чем решением.

Ниже мы подробнее разберём xmlrpc.php и почему он был создан. Мы также рассмотрим общие проблемы безопасности, которые он может вызвать и как их исправить для вашего сайта на WordPress.

Что такое Xmlrpc.php?

XML-RPC – это функциональное средство WordPress, которое позволяет передавать данные, с HTTP выступающим в качестве транспорта и XML – для кодирования. Поскольку WordPress не является закрытой системой и часто общается с другими системами, для этой задачи были найдены решения.

Например, скажем вы хотите сделать публикацию на своём сайте с вашего мобильного телефона. Вам нужно использовать удалённый доступ предоставляемый xmlrpc.php.

Главным функционалом xmlrpc.php являются возможность подключаться к сайту со смартфона, реализация трекбеков и линкбеков с других сайтов и некоторые функции, связанные с плагином Jetpack.

Зачем был создан Xmlrpc.php и как он использовался?

Реализация XML-RPC уходит далеко в ранние дни WordPress и даже до того, как WordPress стал WordPress-ом.

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

Решением (на тот момент) было создание клиента для офлайн блоггинга, где вы могли составлять свой контент, затем подключаться к своему блогу и публиковать его. Это подключение осуществлялось через XML-RPC. С основным функционалом XML-RPC ранние приложения используя подобные подключения предоставляли людям возможность заходить на их сайты WordPress с других устройств.

XML-RPC сегодня

В 2008 году с версией 2.6 WordPress, появилась опция включения и выключения XML-RPC. Однако с релизом WordPress приложения для iPhone, поддержка XML-RPC была включена по умолчанию и не было возможности для отключения. Так осталось и поныне.

Конечно функциональность, предоставляемая этим файлом значительно уменьшилась со временем, и размер файла уменьшился с 83kb до 3kb, он уже не играет такой роли, как прежде.

Свойства XML-RPC

С новым интерфейсом программирования приложений (API) WordPress мы можем ожидать, что XML-RPC будет уже отключён полностью. Сегодня этот новый API всё ещё на этапе испытаний и может быть включён только через специальный плагин.

Хотя вы можете ожидать, что API будет включён непосредственно в ядро WordPress в будущем, что полностью исключит необходимость использования xmlrpc.php.

Новый API не идеален, но он обеспечивает хорошую надёжную защиту, в отличие от xmlrpc.php.

Зачем отключать Xmlrpc.php

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

Конечно вы можете защититься очень надёжный паролем и плагинами WordPress, обеспечивающими безопасность. Но лучшим режимом защиты будет просто его отключить.

Есть два основных слабых места XML-RPC, которые использовали в прошлом.

Первое – использует атаку путём прямого подбора пароля (brute force attacks) для получения доступа к вашему сайту. Атакующий попытается получить доступ к вашему сайту, используя xmlrpc.php подбирая различные комбинации имён пользователей и паролей. Они могут эффективно использовать одну команду для тестирования сотен различных паролей. Это позволяет им обходить инструменты безопасности, которые обычно обнаруживают и блокируют атаки прямого подбора.

Второе – перевод сайта в офлайн путём DDoS атаки. Хакеры будут использовать обратное уведомление в WordPress для отправки его тысячам сайтов одновременно. Этот функционал xmlrpc.php даёт хакерам почти бесконечное количество IP-адресов для распространения атаки DDoS.

Чтобы проверить, работает ли XML-RPC на вашем сайте, вы можете запустить его с помощью инструмента под названием XML-RPC Validator. Запустите свой сайт с помощью инструмента, и если вы получите сообщение об ошибке, значит, у вас нет поддержки XML-RPC.

Если вы получите сообщение об успешном завершении, вы можете остановить xmlrpc.php одним из двух подходов ниже.

Метод 1: отключение Xmlrpc.php при помощи плагина

Отключить XML-RPC на вашем сайте WordPress невероятно просто.

Перейдите в раздел Плагины › Добавить новый в вашей админ консоли WordPress. Найдите плагин Disable XML-RPC и установите его, он выглядит как на картинке ниже:

Активируйте плагин и всё готово. Этот плагин автоматически вставит необходимый код для отключения XML-RPC.

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

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

Метод 2: отключение Xmlrpc.php вручную

Если вы не хотите использовать плагин и предпочитаете делать это вручную, следуйте этому подходу. Он остановит все входящие запросы xmlrpc.php до того, как он будет передан в WordPress.

Вставьте этот код в файл .htaccess:

Заключительные мысли

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

Чтобы ваш сайт оставался в безопасности, рекомендуется полностью отключить xmlrpc.php, если вам не нужны некоторые функции, необходимые для удаленной публикации и плагина Jetpack. Затем вы можете использовать обходные плагины, которые позволяют использовать эти функции, при этом исправляя дыры в безопасности.

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

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

Елена имеет профессиональное техническое образование в области информационных технологий и опыт программирования на разных языках под разные платформы и системы. Более 10 лет посвятила сфере веб, работая с разными CMS, такими как: Drupal, Joomla, Magento и конечно же наиболее популярной в наши дни системой управления контентом – WordPress. Её статьи всегда технически выверены и точны, будь то обзор для WordPress или инструкции по настройке вашего VPS сервера.

Источник

Xml rpc что это

В Сети существует много разных ресурсов, которые предоставляют пользователям определенную информацию. Имеются в виду не обычные статические страницы, а, к примеру, данные, извлекаемые из базы данных или архивов. Это может быть архив финансовых данных (курсы валют, данные котировок ценных бумаг), данные о погоде, или же более объемная информация — новости, статьи, сообщения из форумов. Такая информация может представляться посетителю страницы, к примеру, через форму, как ответ на запрос, или же каждый раз генерироваться динамически. Но трудность в том, что часто такая информация нужна не столько конечному пользователю — человеку, сколько другим системам, программам, которые эти данные будут использовать для своих расчетов или других потребностей.

Реальный пример: страница банковского сайта, на которой показываются котировки валют. Если вы заходите на страницу как обычный пользователь, через браузер, вы видите все оформление страницы, баннеры, меню и другую информацию, которая «обрамляет» истинную цель поиска — котировки валют. Если вам надо вносить эти котировки в свой интернет-магазин, то ничего другого не останется, как только вручную выделить нужные данные и через буфер обмена перенести на свой сайт. И так придется делать каждый день. Неужели нет выхода?

Да, сейчас веб-сервисы, SOAP и XML у всех на слуху, их начинают активно внедрять и крупные корпорации вроде IBM и Microsoft выпускают новые продукты, призванные помочь тотальному внедрению веб-сервисов.

Потому существует еще один, с натяжкой можно сказать альтернативный стандарт на обмен информацией — XML-RPC. Он был разработан при участии Microsoft компанией UserLand Software Inc и предназначен для унифицированной передачи данных между приложениями через Интернет. Он может заменить SOAP при построении простых сервисов, где не надо все «корпоративные» возможности настоящих веб-сервисов.

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

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

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

POST /RPC2 HTTP/1.0
User-Agent: eshop-test/1.1.1 (FreeBSD)
Host: server.localnet.com
Content-Type: text/xml
Content-length: 172

В первых строках формируется стандартный заголовок HTTP запроса POST. К обязательным параметрам относятся host, тип данных (MIME-тип), который должен быть text/xml, а также длина сообщения. Также в стандарте указывается, что поле User-Agent должно быть заполнено, но может содержать произвольное значение.

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

Далее задаются передаваемые параметры. Для этого служит секция

, которая может содержать произвольное число подэлементов

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

Tеперь разберем ответ сервера. Заголовок HTTP ответа обычный, если запрос успешно обработан, то сервер возвращает ответ HTTP/1.1 200 OK. Также как в запросе, следует корректно указать MIME-тип, длину сообщения и дату формирования ответа.

Само тело ответа следующее:

Если при обработке вашего запроса произошла ошибка, то вместо

А теперь рассмотрим кратко типы данных в XML-RPC. Всего типов данных есть 9 — семь простых типов и 2 сложных. Каждый тип описывается своим тегом или набором тегов (для сложных типов).

Целые числа — тег или ;

ASCII-строка — описывается тегом и может содержать произвольную строку символов;

Дата и время — описывается тегом и должна соответствовать формату iso8601. Для дальнейшей обработки в скриптах такой формат немного неудобен, поэтому его всегда конвертируют при отправке/получении запроса. Это может делать специальная функция в составе библиотеки, или, если такой нет, разработчик должен конвертировать дату вручную.

Конечно, кто-то скажет, что такой перечень типов данных очень беден и «не позволяет развернуться». Да, если надо передавать сложные объекты, или большие объемы данных, то лучше использовать SOAP. А для небольших, нетребовательных приложений вполне подходит и XML-RPC, более того, очень часто даже его возможностей оказывается слишком много! Если учесть легкость развертывания, очень большое количество библиотек для почти любых языков и платформ, широкую поддержку в PHP, то XML-RPC часто просто не имеет конкурентов. Хотя сразу советовать его в качестве универсального решения нельзя — в каждом конкретном случае надо решать по обстоятельствах.

Источник

Читайте также:  аденоциркома желудка что это
Информ портал о технике и не только