Что такое код xmlrpc_get_type

Содержание

xmlrpc_get_type

(PHP 4 >= 4.1.0, PHP 5, PHP 7)

xmlrpc_get_type — Получает XML-RPC тип для значения PHP

Описание

Эта функция является ЭКСПЕРИМЕНТАЛЬНОЙ. Поведение этой функции, ее имя и относящаяся к ней документация могут измениться в последующих версиях PHP без уведомления. Используйте эту функцию на свой страх и риск.

Эта функция особенно полезна для base64 и строки, содержащей дату.

Список параметров

Возвращаемые значения

Возвращает тип XML-RPC.

Примеры

Пример #1 Пример XML-RPC типа

Смотрите также

  • xmlrpc_set_type() — Устанавливает тип XML-RPC, base64 или datetime для значения строки PHP

Чистим WordPress

Если вы устанавливали WordPress с нуля, то замечали, что из коробки он предоставляет довольно избыточный функционал, например, вставляет в head много лишних тегов: wp-json, xmlrpc, pingback, canonical, feed, emoji, generator, profile, wmlmanifest, link rel next и prev, и тому подобные. Большинству сайтов они ни к чему, и поэтому им стоит избавиться от лишнего хлама.

Что такое WP JSON и как его отключить и удалить

WP JSON — это сокращение от WordPress JSON REST API. Описание сложное, поэтому объясню проще — это функционал, с помощью которого для WordPress можно написать приложение на абсолютной любой платформе и на любом языке, и с помощью этого приложения управлять сайтом — добавлять, изменять и удалять содержимое, настраивать темы, меню, виджеты и прочее.

В общем, из всего этого описания вам должно быть ясно, что wp-json — пока что совершенно лишнее на вашем сайте, и его надо отключать. К тому же, Яндекс любит выкидывать wp-json в индекс как подраздел сайта. Конечно, это лечится с помощью закрытия от индексирования /wp-json/ в robots.txt , но, всё же, лучше отключить и настроить выдачу ошибки 404 Not Found по этому адресу.

Что неприятно, если не закрыть /wp-json/ , то он предоставляет возможность любым ботам вызнавать довольно конфиденциальную информацию о пользователях. Например, по такому адресу http://example.com/wp-json/wp/v2/users/ будет выдана информация о пользователях сайта с их личными данными: логин, email и прочее, что там указывается.

Чтобы избежать выдачи информации по пользователям WordPress, не отключая WP REST API, можно воспользоваться следующим кодом:

Отключая функционал WordPress REST API, помните, что его используют некоторые популярные плагины, например Contact Form 7 и Yoast SEO. Поэтому, если вдруг у вас перестала работать форма обратной связи, посмотрите, а не отключен ли REST API?

Есть 2 способа избавиться от wp-json, плагин и код.

Отключаем WP JSON REST API с помощью плагина Disable REST API

Для отключения wp-json можно воспользоваться плагином Disable REST API, так как его автор будет поддерживать код в актуальном состоянии в зависимости от возможных изменений в будущих версиях движка WordPress.

Плагин WordPress для отключения wp-json — Disable JSON API

Плагин, конечно, функционал JSON REST API отключит, но вот от раздела /wp-json/ на сайте не избавит. Поэтому, этот вариант немного не то, что нам надо. Идём дальше.

Код для отключения и удаления wp-json и oembed в WordPress

Код взят из разных источников, в основном отсюда, и в том числе, и из вышеуказанного плагина

Код вставляется в functions.php или mu-plugin (желательно).

Результат: вы полностью отключите механизм wp-json на сайте, в поиске будут отсутствовать мусорные страницы, а страница http://example.com/wp-json/ будет отдавать ошибку 404 Not Found

Что такое XML-RPC и как его отключить и удалить

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

Не напоминает WP JSON REST API? Так и есть, xmlprc — его предок, который используется WordPress в текущее время. Почему один замещают другим — возможно, ответ кроется в громоздкости формата XML по сравнению с JSON. Да и не особо это важно в свете текущей статьи. Главное — как избавиться от xmlrpc, не навредив сайту.

Просто удалить файл xmlrpc.php из корня сайта нельзя — им пользуются некоторые популярные плагины навроде JetPack.
Чтобы решить вопрос верно, вы можете воспользоваться 2 вариантами: плагином или кодом.

Отключаем XML-RPC с помощью плагина Disable XML-RPC Pingback

Если сайт на WordPress сильно тормозит, и Вы не понимаете, почему, советую заглянуть в логи ошибок сервера и изучить их:

Обратите внимание на POST /xmlrpc.php . Если она присутствует и часто появляется, значит, сайт атакуют, и нужно срочно закрывать XML-RPC.

Полностью XML-RPC отключать нельзя — им пользуются некоторые плагины. Но некоторые методы, позволяющие проводить атаки на сайты, предупредить можно. И в этом помогает плагин Disable XML-RPC Pingback.

Плагин WordPress для отключения опасных свойств XML-RPC — Disable XML-RPC Pingback

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

Код для отключения и удаления XML-RPC

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

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

Результат: отключили опасные методы работы механизма XML-RPC для WordPress

Что такое Emoji и как их отключить и удалить

С версии WordPress 4.2 в дистрибутив этой CMS был встроен функционал Emoji. Эмоджи — это набор иконок и смайликов, реализованные в Вордпрессе с помощью библиотеки Twemoji от Twitter, и сами по себе неплохи. Если у вас развлекательный сайт или блог, в котором они будут уместны, стоит задуматься, удалять ли их с сайта. Но большинству остальных сайтов, что не используют данный функционал, стоит устранить его, так как смайлики Emoji в WordPress подгружаются с внешних серверов WordPress.org , да и лишний код в head ни к чему.

Есть 2 способа отключить Emoji, отдельным плагином и просто кодом, причём оба имеют право на жизнь.

Плагин WordPress для отключения Emojis — Disable Emojis

Можно обойтись простым плагином Disable Emojis. Не надо его бояться, он не содержит лишних настроек, лишь пару фильтров, код которых, по сути, мы и дублируем к себе в следующем пункте.

В чём преимущество плагинов — их авторы, как правило, следят за обновлениями WordPress и вносят необходимые коррективы в функционал своих плагинов, выпуская обновления, в отличие от нас с вами :) Поэтому, я бы рекомендовал воспользоваться текущим вариантом.

Плагин WordPress для отключения Emojis — Disable Emojis

Учтите, что плагин не вносит изменения в базу данных, которая с версии WordPress 4.2 имеет формат кодировки utf8mb4 , что подразумевает под собой возможность сохранять сами знаки emoji в страницах и записях независимо от наличия или отсутствия Disable Emojis на сайте. При этом, смайлики emoji будут отображаться только в самых современных браузерах.

Код для отключения Emoji в WordPress

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

Код вставляется в functions.php или mu-plugin (желательно).

Результат: удалён вывод javascript-кода поддержки emoji в секции head. Но здесь то же самое, что и с плагином — emoji сохранять в постах можно, но отображаться они теперь будут не во всех браузерах, а только тех, что их поддерживают (как правило, в самых современных).

Удаляем pingback, canonical, meta generator, wlwmanifest, EditURI, shortlink, prev, next, RSS, feed, profile из заголовков head

Настроим редирект с /feed/ на главную

По поводу /feed/ . Если вы хотите дополнительно добавить редирект с http://example.com/feed/ на главную страницу, можете добавить следующий код

Если вы пользуетесь Feedburner, добавляете изменения в .htaccess

Убираем CSS стили .recentcomments

Если вы пользуетесь виджетом Последние комментарии, то WordPress для него пропишет в коде стили css с классом .recentcomment , которые довольно сложно перебить своими. Чтобы не бодаться с этой проблемой, пользуемся следующим кодом

Далее, перейдём к очистке header.php

Удаляем лишний код из header.php

Если в вашей теме WordPress есть header.php , откройте его в любой программе с подсветкой синтаксиса, например Notepad++ или Far Manager.
В секции head найдите лишний код и удалите его.

Удаляем лишний код из head секции

Например, на скрине я выделил код:

В 1 строке — это заголовок, указывающий на то, что на странице используется микроформат XFN. Если вы его не используете (а это, скорее всего, так) — удаляйте.
Во 2 строке — это ссылка, указывающая, по какому адресу оставлять пингбеки. Их мы не позволяем оставлять, поэтому удаляем код.

Кстати, не забудьте проверить, отключены ли у вас пингбеки. Для этого, зайдите в админку в НастройкиОбсуждение ( https://example.com/wp-admin/options-discussion.php ) и убедитесь в том, что галочкой не отмечен пункт Разрешить оповещения с других блогов (уведомления и обратные ссылки) на новые статьи

Запретить оповещения с других блогов (уведомления и обратные ссылки) на новые статьи

Таким же методом можно удалить и другой код, который не удалился с помощью фильтров, например

Не забывайте делать резервные копии изменяемых файлов, чтобы откатить всё назад, если удалили лишнего

По сути, всё, что должно остаться в head в header.php, это что-то примерно следующего содержания

Что не следует удалять из заголовков

Некоторые советуют также удалять dns-prefetch:

Я бы не стал этого делать, потому что dns-prefetch призван ускорить загрузку страниц со внешних источников, а точнее, ресурсов, которые на них располагаются. По адресам, указанным в dns-prefetch , браузер будет делать предварительный резолв, что на медленном интернете может показать себя особенно хорошо.

Илон Маск рекомендует:  Псевдокласс last-child

На этом чистка закончена. Далее пройдёмся по дополнительным пунктам настройки, которые могут пригодиться.

Что ещё пригодится при настройке WordPress

Далее, список советов, что нужно использовать ещё, чтобы оптимизировать работу сайта:

  • Автоматическая простановка заголовка Last-Modified
  • Настройка кеширующего плагина WP Super Cache
  • EWWW Image Optimizer — плагин для сжатия png, jpeg, gif изображений без потери качества
  • Автоматическое проставление атрибута alt. Используем SEO Friendly Images. Плагин не обновлялся уже 2 года, однако, до сих пор исправно работает и пользуется популярностью. Я лично не считаю этот пункт крайней необходимостью, так как у каждого изображения должен быть прописан уникальный alt, а не взят тот, что в названии статьи, но, возможно, кому-то этот пункт покажется важным.
  • Редирект с https на http. Лучше, когда редиректом занимается сервер, а не WordPress, тем самым мы снимаем ненужную нагрузку на систему.
    Изменения добавляем в .htaccess в корне сайта, в самое начало файла

Защита wordpress от XML-RPC атаки

Некоторое время назад мониторинг показал повышенную нагрузку на веб-сервера. Традиционно сразу же пошел проверять лог веб сервера nginx на предмет подозрительной активности. Активность эта сразу же была замечена в виде запросов к файлу xmlrpc.php. Почитал в интернете, что это за файл и принял решение запретить к нему доступ, так как мне он не нужен.

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

Для примера, будем считать, что веб сервер настроен по статье — настройка web сервера nginx, php-fpm, php7 на CentOS 7. Там есть такое правило в конце перечисления locations в nginx:

Изменяем его, добавив блокировку файла xmlrpc.php и ставим его в списке самым первым location.

Перечитываем конфиг nginx:

Проверяем, работает ли реально блокировка файла xmlrpc.php. Для этого сначала просто пройдите по ссылке, в моем случае такой — https://serveradmin.ru/xmlrpc.php Это мы проверили GET запрос. Чтобы проверить POST запрос, введите в адресной строке браузера следующую конструкцию:

В появившейся форме введите любое значение и нажмите Enter на клавиатуре.

Проверяем лог файл.

Все в порядке, веб сервер выдает ошибку 404. Закрыли доступ к файлу xmlrpc.php, через который можно брутфорсить учетки, либо искать уязвимости.

Для повышения безопасности и защиты сайта на wordpress, читайте материалы на сайте по данной теме:

Что такое Xmlrpc.php для WordPress и как его отключить

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

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

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

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

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

Проверить можно с помощью XML-RPC Validator. Для этого:

В поле Address введите ваш домен и нажмите Check:

Если вы получили сообщение «Congratulation! Your site passed the first check», то xmlrpc.php на вашем сайте включен.

Если ответ «Failed to check your site at http://domain.ru because of the following error», то xmlrpc.php отключен.

Чтобы отключить XML-RPC выберите нужную инструкцию:

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

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

Если вы хотите сделать все вручную без установки плагина:

Откройте или создайте (если он отсутствует) файл .htaccess и вставьте в конце файла строки:

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

Для тех, кто не знает, что такое XML-RPC — это WordPress API, позволяющий (удалённо) выводить, создавать, редактировать и удалять:

  • посты,
  • таксономии (рубрики, метки и прочее),
  • медиафайлы,
  • комментарии,
  • пользователей.

А также получать доступ к настройкам и изменять их.

Именно благодаря этому API работают различные приложения для iPhone, iPad и устройств на Android.

Так вот, в предыдущих версиях WordPress была вот такая штука в настройках:

Как известно, от «атома» WordPress отказался полностью, а протокол XML-RPC теперь установлен включенным по умолчанию.

Дело в том, что раньше протокол содержал некоторые уязвимости, а теперь их все залатали.

Для параноиков (я и сам такой) — чтобы отключить XML-RPC, вставляем этот код в functions.php :

Мне вот например не приходится пользоваться приложениями для iOS или Android, я пробовал конечно — ну вообще не понравилось, так что этот протокол мне ни к чему.

Удаляем метатеги с xmlrpc.php из head сайта

Насколько я знаю, существует два метатега:

  • (RSD) и
  • .

    Первый удаляется достаточно просто — хуком на wp_head. Чтобы удалить второй, вам скорее всего придётся открыть файл header.php в вашей теме wp и вручную удалить его из HTML-кода.

    В теме вашего сайта этих тегов может и не быть.

    Смотрите также

    Впервые познакомился с WordPress в 2009 году. С 2014 года меня можно встретить на WordCamp по всему миру — официальной конфе по WordPress, иногда там выступаю, но с 2020 выступаю только на тех, которые сам организовываю. Также периодически школа Epic Skills и LoftSchool приглашают меня вести у них уроки/вебинары.

    Если вам нужна помощь с вашим сайтом или может даже разработка с нуля — пишите мне.

    Комментарии 17

    Прочитал статью про программу Windows Live Writer, и решил пользоваться ею, как все цивилизованные блогеры. Но при установке связи и авторизации с блогом возникли проблемы. Выскакивает окошко с надписью»Программа Windows Live Writer не может автоматически определять настройки блога. Для продолжения выберите тип блога» Выбираю WordPress 2.2 + Ниже окно для ввода адреса блога, предлагает ввести адрес в виде»http:////xmlrpc.php» Вот здесь и начинаются мучения. После ввода адреса дает ошибку:
    «Произошла ошибка при попытке подключится к вашей службе блога по адресу http://ayasam.ru/xmlrpc.php «. Когда ввожу этот адрес в командную строку, получаю такой ответ «XML-RPC server accepts POST requests only.»
    Все другие варианты дают ошибку 404. мой сайт на WordPress 3.5 Искал в Инете инфу не нашел. Может кто сталкивался с этой проблемой?

    Windows Live Writer не использую, однако я заметил вот что:

    Что такое XML RPC WordPress и как его отключить

    Table of Contents

    Зачем создавался XML RPC и как он помогал владельцам сайтов?

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

    XML RPC WordPress стандартизирует связь между различными системами. Например с платформами для ведения блога, такими как Blogger или Movable Type, или при отправке данных с десктопных клиентов или официальных мобильных приложений. Раньше XML RPC был в этом незаменимым помощником. Протокол использует HTTP как механизм транспорта и XML как механизм кодирования, который позволяет передавать большой объем данных.

    Одними из основных функций xmlrpc.php являются управление веб-сайтом с помощью мобильного приложения (IOS и Android), а также осуществление трекбеков и пингбеков с других ресурсов.

    Актуальность XML RPC WordPress

    Десять лет назад в редакции WordPress 2.6 появилась возможность активации и деактивации XML RPC. Но с появлением Вордпресс приложения для iPhone поддержка протокола была активирована без возможности отключения. Так система работает до сих пор.

    С созданием нового Интерфейса программирования приложений Вордпресс (Rest API) мы можем предположить, что XML RPC в будущем будет полностью деактивирован и упразднен. Rest API внедрен в само ядро Вордпресс, необходимости в работе файла xmlrpc.php почти нет. Созданный Rest API не подвергает риску безопасность сайта, чем не может похвастать xmlrpc.php.

    Чем опасен хmlrpc.php?

    Безопасность – самое уязвимое место XML RPC WordPress. Дело в том, что его можно использовать как мишень для DDoS атак на ваш сайт. Хакеры используют обратное уведомление в Вордпресс для отправки его огромному количеству сайтов единовременно. Такая уязвимость дает злоумышленникам почти неограниченное число IP-адресов для распространения атаки.

    Другое слабое место XML RPC – это уязвимость перед хакерской атакой. Специальная программа использует файл xmlrpc.php для прямого подбора паролей и имен пользователей до тех пор пока не получит доступ.

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

    Отключение XML RPC с помощью бесплатного плагина Clearfy

    Мы предлагаем вам повысить защиту сайта с помощью плагина Clearfy. Всего в несколько кликов. Достаточно лишь выполнить следующие шаги:

    1. Скачайте и установите бесплатный плагин Clearfy
    2. В левом боковом меню перейдите в раздел «Защита»
    3. В верхней части настроек вы увидите вкладку “Защита”, внутри «Базовые настройки»

    Следует нажать кнопку «ВКЛ» в строке «Отключить XML-RPC». Теперь ваш сайт стал еще более защищенным, нежели вы бы просто установили надежный пароль.

    Отключение XML RPC с помощью кода

    Однако если вы не готовы пользоваться плагином и хотите самостоятельно решить проблему безопасности сайта, то добавьте код в functions.php:

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

    • Использование кода позволяет сэкономить ресурсы вашего сервера, однако эта экономия невелика. Вы только отказываетесь от интерфейса администратора.
    • Может быть полезно для улучшения своих навыков
    • Вы можете адаптировать это решение конкретно для своего сайта
    • Эта часть кода не обновляется и не поддерживается разработчиками, поэтому в какой-то момент он может быть не совместим с новой версией WordPress
    • Вы используете его на свой страх и риск
    • Код может быть несовместим с вашими плагинами и темами
    • Вы не получите поддержку, в случае если ваш сайт будет сломан
    • Если у вас много сайтов, обновление кода превратится в сплошную рутину

    Важно: Код на сайте нужно редактировать очень осторожно. Не забудьте сделать резервную копию сайта перед тем, как внести изменения. Если у вас совсем нет опыта и уверенности в своих силах, лучше прибегнуть к услугам разработчика или воспользоваться готовым решением в виде плагина Clearfy.

    Уязвимость WordPress через файл xmlrpc.php. Решение есть!

    2015-11-28 / Вр:01:02 / просмотров: 24973

    Совсем недавно я позакрывал все дыры к адресу для входа в админ панель и думал, что все – атаки на вход админ панель прекратятся. Но я был абсолютно неправ, вечером мне пришло сообщение, что было заблокировано еще два IP адреса, которые ломились в админ (плагин limit login attempts).

    Я был в шоке, как им это удается?

    Но, так как у меня на WordPress установлен плагин «WordPress Firewall 2», мне пришло на почту уведомление о том, что были две атаки на файл «xmlrpc.php» .

    Заметьте, IP адреса совершенно одинаковы как в первом скриншоте, так и во втором. Значит, взломщик не использовал для взлома прямой адрес для входа в админ, он это делал через «xmlrpc.php» (мои догадки и они могут быть спорными).
    Почитал в интернете о файле «xmlrpc.php» и оказалось действительно, что это файл является дверью для взломщика, которая плохо защищенная. Именно большинство атак происходит благодаря этой лазейке, которая по умолчанию включена на всех сайтах WordPress. Вот те на! Называется, защитил свой блог. Это все равно, что позакрывал все окна и двери от вора на замки, но черный вход оставил открытым!

    Нужен ли файл «xmlrpc.php»?
    Прочитав некоторую информацию, я понял, что файл «xmlrpc.php» не такой уж и важен для WordPress. Просто с его помощью можно управлять блогом через различные приложения. Не знаю как вы, но я этой возможностью не пользуюсь, значит, зачем мне этот файл нужен, тем более, если он еще такой уязвимый. Будем отключать файл «xmlrpc.php» !

    Чтобы отключить файл «xmlrpc.php» , для самых ленивых рекомендуют использовать плагин «Disable XML-RPC». А поскольку мы не такие, то все сделаем сами, тем более это не сложно.

    Зайдите в файл функции темы «functions.php» и в самом конце файла перед знаком « ?> » вставьте вот этот код:

    Зайдите в файл «header.php» и найдите вот такую строчку:

    В файле «.htaccess» в самом конце вставьте вот такой код:

    Этим кодом мы всем запретим доступ к файлу «xmlrpc.php» .
    Я думаю, этого достаточно!

    С сегодняшнего дня я буду тестировать результат в течение месяца. Если за этот период не появится новая статья о том, что снова кто-то лезет в админку, значит задача решена и можно на некоторое время расслабиться .

    На сегодня все! Надеюсь, что статья была вам полезна, так как защита блога – это всегда важно и актуально.

    Интересно, какие еще загадки и сюрпризы таит в себе мой любимый движок WordPress?

    Статья Получение контроля над WordPress с помощью использования XML-RPC

    WebWare Team

    ООО Кодебай

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

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

    Эта уязвимость впервые

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

    Step 1 Тестирование на наличие уязвимости

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

    Вы можете просто проверить свой сайт на наличие файла /xmlrpc.php, как сделал я выше на своем локальном WordPress (замените «localhost» на URL вашего вебсайта). Если XML-RPC прослушивается, или находится там, вам сообщат об этом. Похоже, что мы нашли потенциально уязвимый блог (вам сообщат «forbidden» или что-то на подобие).

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

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

    Когда вы пытаетесь войти в WordPress, ваши имя пользователя/пароли отслеживаются следующим образом:

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

    Это все, что я хотел рассказать в этом разделе.

    Step 2 Взлом сервера

    Ниже приведен пример того, как это выглядит в формате XML. Выделенный раздел, это только одна попытка подбора пароля, так что вам придется повторить этот раздел множество раз, используя различные пароли. Как вы можете себе представить, это займет много времени, перебирать варианты пароля один за другим.

    Чтобы ускорить этот процесс, мы используем скрипт, найденный на GitHub, который читает наш список паролей и автоматически повторяет выделенную секцию, показанную выше, каждый раз подставляя новый пароль из нашего списка. Так что, перейдите на

    на GitHub и скачайте файлы через HTTP ссылку (Скачайте ZIP, или Git если вы зарегистрированы в нем.)

    Откройте окно терминала и перейдите в директорию, в которую вы сохранили скачанный файл, затем разархивируйте его в следующее место:

    Я выделил инструкцию голубым цветом. Для локального хоста это:

    Необходимо соблюсти вышеуказанный порядок, а именно, имя Python файла, затем имя сервера, затем имя файла с паролем и, наконец, имя пользователя. Здесь мы используем файл passwords.txt, который включает в себя скачанный файл GitHub (который включает в себя небольшое количество паролей), и мы будем использовать admin, как имя пользователя. Если вы хотите использовать свой собственный список паролей, просто включите его в команду, вместо предыдущего, и используйте имя пользователя, которое считаете подходящим – этот инструмент работает только с паролями.

    Так что, когда вы произведете указанные выше действия, используя имя вашего целевого сервера вместо «localhost,» ваш файл пароля и ваше имя пользователя, Python скрипт пропустит их через включенный файл passwords.txt и запустится в большей мере не обнаруженным способом. Если все прошло успешно, скрипт выдаст ваш логин в форме имя пользователя/пароль.

    Как защититься от этого эксплойта

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

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

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

    Настольный справочник по атакам на XML-приложения

    Содержание статьи

    С одной стороны, тема XML injection — это жуткий баян, а с другой — она так популярна, что баги такого типа присутствовали во многих X-конкурсах последнего времени, например ZeroNights HackQuest и месяце поиска уязвимостей в Яндексе. В этой статье мы постарались собрать и систематизировать все, что известно об XML injection на данный момент.

    WARNING

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

    Часть первая, теоретическая

    Начнем издалека. Стандартом определены два уровня правильности документа XML:

    1. Правильно построенный (well-formed) документ. Такой документ соответствует общим правилам синтаксиса XML, применимым к любому XML-документу. И если, например, начальный тег не имеет соответствующего ему конечного тега, то это неправильно построенный XML.
    2. Действительный (valid) документ. Действительный документ дополнительно соответствует некоторым семантическим правилам. Это более строгая проверка корректности документа на соответствие заранее определенным, но уже внешним правилам. Эти правила описывают структуру документа: допустимые названия элементов, их последовательность, названия атрибутов, их тип и тому подобное. Обычно такие правила хранятся в отдельных файлах специального формата — схемах.

    Основные форматы определения правил валидности XML-документов — это DTD (Document Type Definition) и XML Schema. Остановимся на DTD. Стандартом предусмотрено два варианта связывания документа с его схемой: либо через ссылку на схему в заголовке XML-документа (этот заголовок называется Document Type Declaration):

    либо через описание схемы в документе inline (аналогия: подключение CSS через ссылку или inline):

    Самое интересное в DTD — это то, что умные люди придумали так называемые сущности. Придумали, чтобы можно было подключать часто используемые фрагменты XML-документов по имени. Сущность определяется в DTD через директиву и используется в документе как &name;. А потом кто-то подумал, что глобализация должна быть глобальной, и придумал еще и внешние сущности (external entities). Например, можно определить внешнюю сущность current-date:

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

    Успешное разрешение внешней сущности, указывающей на /etc/passwd

    Хакер #156. Взлом XML Encryption

    Соответственно, наш пример с добавлением текущей даты заказа перепишется так:

    Последний элемент технологии — парсеры, которые, собственно, и разбирают XML-документы, валидируют их, разрешают внешние сущности, реализуют стандартный интерфейс к построенной объектной модели (DOM) и тому подобное. Парсеры бывают валидирующими и невалидирующими. Вот что сказано в стандарте о поведении парсера при наличии в документе ссылок на внешние сущности:

    «When an XML processor recognizes a reference to a parsed entity, in order to validate the document, the processor must include its replacement text. If the entity is external, and the processor is not attempting to validate the XML document, the processor may, but need not, include the entity’s replacement text. »

    Это важно! Тут говорится, что валидирующий парсер обязан включить в документ содержимое внешнего файла (логично, иначе как парсер проверит правильность структуры документа?), а невалидирующий — по желанию. Однако на практике это свойство «по желанию» выполняется практически у всех популярных парсеров.

    Популярные XML-парсеры

    Интерпретируемые языки (PHP, Perl, Python, Ruby и другие):

    • большинство парсеров используют библиотеки libxml2 (xmlsoft.org, последняя версия — 2.7.8) и libxslt (xmlsoft.org/XSLT/);
    • некоторые парсеры используют другие библиотеки (например, модуль expat-XML::Parser в Perl использует библиотеку Expat XML Parser) либо полностью реализуются на «родном» языке (например, парсер REXML в Ruby).

    Java:

    • Apache Xerces: xerces.apache.org, последняя версия — 2.11.0;
    • (для XSLT) Apache Xalan-Java: xml.apache.org/xalan-j/, последняя версия — 2.7.1;
    • работа с XML-парсерами в Java реализуется через общий интерфейс Java API for XML Processing (JAXP. В ранних версиях Java через JAXP был доступен парсер Crimson от Sun).

    Windows-платформа, .NET:

    • в большинстве Windows-приложений (написанных на Delphi, JScript, VBScript и так далее) для обработки XML используется парсер MSXML (goo.gl/hPdbg, последняя версия — 6.0 SP2);
    • в .NET-приложениях для парсинга XML используются классы из пространства имен System.XML (XmlTextReader, XslTransform и другие).

    Часть вторая, переходная

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

    Что бы мы хотели получить в идеале? Конечно, возможность чтения локальных файлов вроде этого:

    1. В HTTP-запрос, в котором на сервер передается XML, вставляем .
    2. В теле XML-документа даем ссылку на сущность — &xxe; .
    3. В ответе получаем содержимое локального файла.

    Однако в реальности, как говорится в одном анекдоте, «есть нюанс». Прежде всего попробуем рассмотреть XML-парсеры чуть более подробно. Как они обрабатывают внешние сущности по умолчанию?

    Есть три класса популярных платформ: .NET, Java и интерпретируемые языки (PHP, Perl, Python, Ruby и подобные). Отметим, что все перечисленные ниже парсеры по умолчанию не производят валидацию обрабатываемого документа. В Windows и .NET используются MSXML-парсер и пакет System.xml соответственно. Только начиная с шестой версии, библиотека MSXML перестала разрешать ссылки на внешние сущности по умолчанию. В Java обычно используются пакеты Xerces и Xalan (для XSLT). И в том и в другом пакете ссылки на внешние сущности по умолчанию разрешаются. Наши же любимые интерпретируемые языки используют библиотеки libxml2 и libxslt (для XSLT), которые тоже по умолчанию разрешают ссылки на внешние сущности. Вывод: запрет на разрешение внешних сущностей в подавляющем большинстве случаев (библиотек) — ответственность программиста.

    SOAP и DTD

    Спецификация протокола SOAP подробно регламентирует структуру SOAP-сообщения, в частности явно запрещает использование DTD:

    «The XML infoset of a SOAP message MUST NOT contain a document type declaration information item».

    Таким образом протокол защищен от возможности проведения XXE-атак. С другой стороны, конкретные реализации протокола часто не следуют спецификации.

    Для того чтобы понять, насколько много уязвимостей XXE присутствует в реальном мире, надо разобраться с тем, где и когда в веб-приложениях используются парсеры. Мы выделяем два класса использования парсеров: на уровне платформы / стандартных библиотек и на уровне прикладного (своего) кода. Типичный пример использования парсеров на уровне платформы —поддержка протоколов XML-RPC и SOAP, на уровне прикладного кода — реализация обмена данными между приложением и пользователем: импорт, экспорт и так далее. Со вторым случаем все ясно — вряд ли найдется много программистов, которые при инициализации XML-парсеров подумают о том, чтобы запретить разрешение внешних сущностей. Поэтому большинство функций импорта данных в веб-приложение через XML являются уязвимыми к внедрению внешних сущностей (за примером далеко ходить не надо: LFI через XXE-уязвимость в phpMyAdmin — goo.gl/5RDrM).

    Разберемся теперь с первым случаем — уровнем платформы. Посмотрим, что говорят спецификации протоколов XML-RPC и SOAP про внешние сущности. В спецификации SOAP нас расстраивают: «a SOAP message MUST NOT contain a document type declaration information item». Как показывает опыт, наличие правил в стеке еще не означает, что их будут выполнять на практике. Тем не менее, шансов найти уязвимость в коде платформы, реализующей SOAP, намного меньше, чем в прикладном коде. С протоколом XML-RPC ситуация значительно лучше (для нас): про запрет внешних сущностей или подключение DTD в спецификации не сказано ни слова.

    В результате всего изложенного мы сможем вывести классы приложений, которые, вероятнее всего, будут уязвимы к разрешению внешних сущностей (в порядке убывания вероятности):

    1. Custom-приложения с функцией импорта данных в XML.
    2. Приложения, реализующие протокол XML-RPC.
    3. Веб-сервисы, реализующие протокол SOAP.

    Защищаемся

    На примере Xerces-парсера покажем, как можно защититься от XXE. Итак, устанавливаем необходимые значения для свойств парсера:

    При помощи метода setEntityResolver можно задать свой обработчик внешних сущностей (появляется возможность не просто игнорировать сущности, но и обнаруживать XXE-атаки на наше приложение!). Для других XML-парсеров можно найти аналогичные свойства.

    • Протокол XML-RPC: разработан в 1998 году (xmlrpc.scripting.com/spec.html), автор — Дэйв Уинер (Dave Winer).
    • Протокол SOAP: разработан в 1998 году, текущая версия спецификации Simple Object Access Protocol specification Version 1.2 (www.w3.org/TR/soap12-part1/).

    Часть третья, практическая

    Следующий шаг — научиться понимать, разрешает заданное приложение внешнюю сущность или нет. Сделать это крайне просто:

    1. Необходимо разместить на своем веб-сервере тестовый документ extdoc.txt с каким-нибудь содержимым, например «include me please!» (на самом деле файл можно даже не размещать!).
    2. Дать ссылку на него в XML-теле HTTP-запроса.
    3. Проверить access.log нашего веб-сервера — а не обратился ли кто к нему? (Или ищем ошибку 404, если не размещали.)

    Входной параметр — URL модуля, который сделает XSLT-трансформацию
    по XSL-файлу

    Учитывая, что в протоколах SOAP и XML структура ожидаемого на сервере документа известна, описанный процесс тестирования легко автоматизируется (скрипты и описание ты найдешь на диске):

    1. Берем список URL, реализующих XML-протоколы, и в цикле отправляем по каждому адресу XML-документ (мы его заготовили заранее) формата SOAP или XML-RPC с внешней сущностью, которая ссылается на файл с нашего сервера. При отправке записываем IP-адрес и доменное имя очередного кандидата в файл.
    2. Наш веб-сервер сконфигурирован не отдавать документ с телом XML-сущности как статический файл, а перенаправлять запросы к нему на специальный обработчик (например, php). Mod_Rewrite в помощь. Обработчик фиксирует все входящие запросы в журнал, записывая IP-адрес отправителя.
    3. Чекаем полученные списки по IP-адресам и понимаем, какие URL заходили к нам за файлом.
    4. Здесь следует учесть, что сетевой фильтр на стороне тестируемого веб-приложения может запрещать исходящие соединения в интернет, тогда наш метод «в лоб» не сработает. Внимательный читатель спросит: откуда же взять эти начальные списки URL для проверки? Конечно, у заказчика тестирования, ответим мы; после чего случайно оброним парочку намеков на паттерны гуглопоиска:

    XXE в Safari позволяет вредоносной веб-странице считывать локальные файлы с машины клиента

    Итак, тестируемое нами приложение разрешает внешние сущности. Что дальше?

    1. DoS — на никсах и на винде (последнее работает нестабильно).
    2. Сканируем локальную сеть — . Помни, что сообщения об ошибках и временные задержки — наше все! Кстати, про случай из жизни, связанный с этим трюком, написано в статье «Funny hacks» Владимира Воронцова в этом номере.
    3. Читаем локальные файлы. Казалось бы, все должно быть просто: вставляем и мы на коне! Но нет.

    Во-первых, тебе кто-то обещал, что сущность, которую ты определил в HTTP-запросе, попадет в HTTP-ответ? Правильно, никто не обещал. Должно повезти. Стоит сказать пару слов про методику тестирования. В custom-приложениях и SOAP-сервисах формат обрабатываемого XML-документа известен (помним про WSDL). То есть нам необходимо во все теги отправляемого документа запихнуть ссылку на нашу сущность и посмотреть, вернется ли она в ответе. С XML-RPC дела обстоят хуже: в общем случае мы не знаем сигнатур методов, реализуемых приложением. Т.е. автоматизировать подстановку сущностей в параметры вызываемых RPC-методов в общем случае нам не удастся. Тут тебе в помощь может прийти спек, описывающий расширение XML-RPC, — http://xmlrpc-c.sourceforge.net/introspection.html. Используя его, ты, например, можешь получить список методов, поддерживаемых на сервере. Увы, далеко не все XML-RPC приложения реализуют интроспекцию. Во-вторых, почему после подстановки сущности итоговый XML должен остаться правильно построенным? Хорошо, что как минимум в случае с PHP по этому поводу беспокоиться не стоит, — делаем base64-обертку вокруг считываемых данных:

    Далее мы должны познакомить тебя еще с одним интересным методом внедрения XML. Данный метод может привести к выполнению кода на сервере. Есть такая технология, называется XSLT (см. врезку). Обычно она используется для перевода XML-документов, обрабатываемых веб-приложением, в пригодный для отображения в браузере вид. Для трансформации нужны два XML-документа: исходный документ, который мы хотим трансформировать, например, в XHTML, и документ с описанием трансформации. В 99% случаев документ, описывающий трансформацию, лежит на сервере веб-приложения, а путь к нему прописан в каком-нибудь конфиге. В остальном проценте случаев путь к нему передается в URL (:facepalm:). Учитывая такой дизайнерский шаг, можно быть уверенным в том, что интересующий нас HTTP-параметр не подвергается никакой обработке, то есть мы сможем указать XSL-документ, лежащий на нашем сервере. А дальше, если XSLT-трансформатор был инициализирован в PHP-коде кривого веб-приложения следующим образом:

    то мы сможем внутри XSL-документа использовать PHP-функции, например, вот так:

    Хорошо, что подобных приложений в природе мало (google кунг-фу поможет тебе их найти) и с каждым днем становится все меньше :).

    XSL и XSLT

    Extensible Stylesheet Language (XSL) — это группа языков, предназначенных для преобразования XML-документов или их визуального представления. Эта группа состоит из трех частей:

    • XSL Transformations (XSLT) — язык преобразований XML-документов;
    • XSL Formatting Objects (XSL-FO) — язык, специфицирующий визуальное представление XML-документа;
    • XML Path Language (XPath) — язык, предназначенный для доступа к определенным частям XML-документа (используется как в контексте XSLT, так и самостоятельно).

    Специфицируется консорциумом W3C (Extensible Stylesheet Language (XSL) Version 1.1).

    Часть четвертая, демонстрационная

    Мы подумали: интересно, а за сколько мы сможем найти в интернете приложение, уязвимое не просто к классической XXE-атаке, а чтобы там еще и XSLT-трансформация была? Сказано — сделано.

    Перво-наперво мы пошли на сервисы поиска программного кода (opensearch.krugle.org, koders.com), а также в Google (пользуясь случаем, хочу выразить глубокое сожаление по поводу так не вовремя закрытого сервиса Google Code Search). Нас интересовал заведомо уязвимый участок кода, связанный с загрузкой XML- или XSL-документа для последующей XSLT-трансформации, имя которого берется прямо из параметра GET-запроса. Таким образом мы искали строки вида «$xsldoc->load($_GET» и «$xmldoc->load($_GET». В результате нашлись проекты с уязвимым кодом, но масштаб проектов нам не понравился, и мы решили не связываться с ними. Следующей идеей был поиск веб-приложений, в которых есть модули XSLT-трансформации, принимающие в качестве аргумента имя XML-документа: inurl:»transform.php?xml=» (и потрясающее inurl:»transform.py?xml=» — от структуры URL на сайтах из выдачи слезы наворачивались на глаза). В итоге для дальнейшего анализа мы взяли одно из приложений, в URL которого было значение /path/transform.php?xml= . Нам повезло, что обо всех ошибках, возникших при трансформации, приложение радостно сообщало в HTTP-ответе. Первым делом нам интересно было узнать, что произойдет, если вместо имени локального XML-файла указать что-то удаленное: /path/transform.php?xml=http://ya.ru/. Как мы и предполагали, оно деловито полезло за XML-документом на Яндекс, но поперхнулось (см. иллюстрацию).

    Дальше план был таков:

    1. Скачать на управляемый нами веб-сервер исходный XML-документ, который успешно проходит трансформацию. Документ, очевидно, был доступен как /path/ .
    2. Добавить в документ inline-DTD, в которой определить парочку сущностей — простую и внешнюю:

    а в самом XML-документе сослаться на простую сущность pi (для начала).

  • Запросить трансформацию заряженного XML с нашего сервера: /path/transform.php?xml=http://youllneverguessthena.me/inc.xml и поискать в ответе число пи (почему его там могло не оказаться — читай ниже). Нам повезло — сущности, разрешаемые парсером в исходном документе, проходили трансформацию в конечный документ. Нам оставался последний шаг.
  • Модифицируем XML-документ на нашем сервере второй раз, добавляя ссылку на внешнюю сущность (&htaccess;) в тело документа, и повторяем запрос на трансформацию. Конечно, читать остальные файлы (в том числе /etc/passwd и /dev/zero) мы не стали, зато уведомили администратора сайта об уязвимости.
  • XXE в Яндексе обнаружилась при обработке SOAP (к слову о specification vs implementation)

    Теперь пару слов о том, почему нам повезло. Вообще-то XSLT-трансформатор не обязан выводить в итоговый документ сущности, разрешенные в исходном. Чтобы заставить его это сделать, в libxml2 (а следовательно, и в PHP) нужен дополнительный вызов. В итоге код, реализующий трансформацию, должен быть примерно таким (ключевая строка — substituteEntities ):

    • Спецификация XML 1.0L: goo.gl/nUKXz.
    • Список XML-протоколов от W3C: goo.gl/KzUVZ.
    • Блог Владимира Воронцова, описание XXE в Яндексе: goo.gl/9KIax.

    Заключение

    Вообще отношение к сущностям во время трансформации сильно зависит (внезапно!) от конкретного парсера. Так что на практике тебе придется проверять поведение в каждом конкретном случае. Сохранение сущностей после трансформации в современных XML-парсерах — отличная тема для хорошего и очень востребованного обзора. Anyone? У нас все.

    xmlrpc_get_type

    (PHP 4 >= 4.1.0, PHP 5)

    xmlrpc_get_type — Gets xmlrpc type for a PHP value

    Описание

    Эта функция является ЭКСПЕРИМЕНТАЛЬНОЙ. Поведение этой функции, ее имя и относящаяся к ней документация могут измениться в последующих версиях PHP без уведомления. Используйте эту функцию на свой страх и риск.

    This function is especially useful for base64 and datetime strings.

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

    Илон Маск рекомендует:  Что такое код getservbyport
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL