Навіщо потрібен файл xmlrpc php. Змагання з програмування
Кілька днів тому я помітив, що навантаження моїх сайтів на хостинг виросла в рази. Якщо зазвичай вона становила в районі 100-120 "папуг" (CP), то за останні кілька днів вона зросла до 400-500 CP. Нічого хорошого в цьому немає, адже хостер може перевести на більш дорогий тариф, а то і зовсім прикрити доступ до сайтів, тому я почав розбиратися.
Але я вибрав метод, який дозволить зберегти функціональність XML-RPC: установку плагіна Disable XML-RPC Pingback. Він видаляє лише "небезпечні" методи pingback.ping і pingback.extensions.getPingbacks, залишаючи функціонал XML-RPC. Після установки плагін потрібно всього лише активувати - подальша настройка не потрібна.
Попутно я забив всі IP атакуючих в файл.htaccess своїх сайтів, щоб заблокувати їм доступ. Просто дописав в кінець файлу:
Order Allow, Deny Allow from all Deny from 5.196.5.116 37.59.120.214 92.222.35.159
Ось і все, тепер ми надійно захистили блог від подальших атак з використанням xmlrpc.php. Наші сайти перестали вантажити хостинг запитами, а також атакувати за допомогою DDoS сторонні сайти.
У WordPress завжди був вбудований інструмент для віддаленого звернення до вашого сайту. Дійсно, іноді потрібно дістатися до свого сайту, а комп'ютер далеко від вас. Тривалий час рішенням був файл під назвою xmlrpc.php. Однак останніми роками цей файл став більшою проблемою, ніж рішенням.
Нижче ми докладніше розберемо xmlrpc.php і чому він був створений. Ми також розглянемо загальні проблеми безпеки, які він може викликати і як їх виправити для вашого сайту на WordPress.
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 буде включений безпосередньо в ядро \u200b\u200bWordPress в майбутньому, що повністю виключить необхідність використання 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 неймовірно просто.
Перейдіть в розділ Модулі\u003e Додати новий у вашій адмін консолі WordPress. Знайдіть плагін Disable XML-RPC і встановіть його, він виглядає як на картинці нижче:
Активуйте плагін і все готово. Цей плагін автоматично вставить необхідний код для відключення XML-RPC.
Однак пам'ятайте, що встановлені плагіни можуть використовувати частини XML-RPC, і тоді його відключення може викликати конфлікт плагінів або окремих їх частин і виведення їх з робочого режиму.
Якщо ви хочете тільки відключити окремі елементи XML-RPC, але дозволити іншим плагинам і функцій працювати, тоді зверніться до таких плагінів:
- Stop XML-RPC Attack. Цей плагін зупинити все XML-RPC атаки, але він дозволити продовжити роботу таких плагінів як Jetpack і інші автоматичні інструменти і плагіни, надаючи їм доступ до файлів xmlrpc.php.
- Control XML-RPC Publishing. Це дозволяє вам зберегти контроль і використовувати віддалено публікації.
Метод 2: відключення Xmlrpc.php вручну
Якщо ви не хочете використовувати плагін і вважаєте за краще робити це вручну, дотримуйтесь цього підходу. Він зупинить всі вхідні запити xmlrpc.php до того, як він буде переданий в WordPress.
Відкрийте файл.htaccess. Можливо, вам доведеться включити 'показати приховані файли' в файловому менеджері або FTP-клієнті, щоб знайти цей файл.
Вставте цей код в файл .htaccess:
# Block WordPress xmlrpc.php requests
заключні думки
В цілому, XML-RPC був добротним рішенням деяких проблем, які виникали через віддаленої публікації на вашому сайті WordPress. Однак разом з тим з'явилися деякі дірки в безпеці, які виявилися досить небезпечними для деяких власників сайтів на WordPress.
Щоб ваш сайт залишався в безпеці, рекомендується повністю відключити xmlrpc.php, якщо вам не потрібні деякі функції, необхідні для віддаленої публікації і плагіна Jetpack. Потім ви можете використовувати обхідні плагіни, які дозволяють використовувати ці функції, при цьому виправляючи діри в безпеці.
Згодом ми можемо очікувати, що функції XML-RPC стануть інтегрованими в новий WordPress API, який буде підтримувати віддалений доступ, не жертвуючи безпекою.
Ви заблокували доступ до XML-RPC через плагін або вручну? Або виникли будь-які проблеми з безпекою через те, що він був перш за активним? Поділіться своїм досвідом в коментарях нижче.
His post also shows how to do browser authentication, as below:
$ Request \u003d xmlrpc_encode_request ( "methodName", array ( "methodParam"));
$ Auth \u003d base64_encode ($ username. ":". $ Password);
$ Header \u003d (version_compare (phpversion (), "5.2.8"))
? array ( "Content-Type: text / xml", "Authorization: Basic $ auth")
: "Content-Type: text / xml \\ r \\ nAuthorization: Basic$ Auth "; //
$ Context \u003d stream_context_create (array ( "http" \u003d\u003e array (
"Method" \u003d\u003e "POST",
"Header" \u003d\u003e $ header,
"Content" \u003d\u003e $ request
)));
$ Webservice \u003d "Http://www.example.com/rpc";
$ File \u003d file_get_contents ($ webservice, false, $ context);
$ Response \u003d xmlrpc_decode ($ file);
if (xmlrpc_is_fault ($ response)) (
return "xmlrpc: $ response [faultString] ($ response [faultCode])";
) Else (
return $ response;
}
?>
1 - EDITOR NOTE: THIS IS A FIX FROM "SandersWang dt php at gmail dot com"
16 years ago
Binary strings (set with xmlrpc_set_type) go into a
Silly though it may be, it causes real problems for some XML-RPC servers, such as http://jakarta.apache.org/xmlrpc/ (nee Helma). Stripping out those entities with something like
$ Req \u003d preg_replace ( "/ /", "", xmlrpc_encode_request ( "my.method", $ args));
works around the problem.
11 years ago
It should be noted that encoding does not seem to encode anything, just specify what goes into the XML header.
We had problems with double-encoded UTF strings being saved to database when using this function, sending it of to a apache xml-rpc servlet and storing it in mysql database. It was solved by setting "escaping" to just "markup" and "encoding" to "UTF-8" (don "t forget to set" utf-8 "in xmlrpc_decode too).
It seems that UTF-8 encoded strings gets escaped with their bytes as entities instead of their characters as entites.
9 years ago
Ever tried transmitting an array like the following with xmlrpc?
$ Var1 \u003d array (7 \u003d\u003e 14,9 \u003d\u003e 18);
The output array looks quite different! It will look like that:
$ Var2 \u003d array (14,18);
The only solution i found is to prepend a space to the index:
$ Var3 \u003d array ( "7" \u003d\u003e 14, "9" \u003d\u003e 18);
Using that method you "ll get the right result. ($ Var1)
16 years ago
This function should be used by an XML-RPC client to create an XML payload for an XML-RPC request;
$ Params \u003d "system.methodSignature";
$ Method \u003d "system.methodHelp";
$ Request \u003d xmlrpc_encode_request ($ method, $ params);
echo ($ request);
?>
Produces;
The second argument recognises the type of variable and generates the correct XML-RPC structure. See xmlrpc_encode () for more details.
12 years ago
Simple OO client with function Overload:
the php metho test_helloworld is translated to xmlrpc method test.helloworld.
class RpcClient (
Private $ _methods;
private $ _context;
private $ _url;
Function __construct ($ url, $ user, $ passwd) (
$ Auth \u003d base64_encode (sprintf ( "% s:% s", $ user, $ passwd));
$ This -\u003e _ context \u003d stream_context_create (array (
"Http" \u003d\u003e array (
"Method" \u003d\u003e "POST",
"Header" \u003d\u003e "Content-Type: text / xml \\ r \\ n".
"Authorization: Basic $ auth",
)
));
$ This -\u003e _ url \u003d $ url;
$ This-\u003e registerMethod ( "Test_HelloWorld");
Function __call ($ methodName, $ params) (
if (array_key_exists ($ methodName, $ this -\u003e _ methods)) (
// on appelle la fonction RPC
$ M \u003d str_replace ( "_", ".", $ MethodName);
$ R \u003d xmlrpc_encode_request ($ m, $ params, array ( "verbosity" \u003d\u003e "newlines_only"));
$ C \u003d $ this -\u003e _ context;
stream_context_set_option ($ c, "http", "content", $ r);
$ F \u003d file_get_contents ($ this -\u003e _ url, false, $ c);
$ Resp \u003d xmlrpc_decode ($ f);
return $ resp;
) Else (
// on appelle la fonction de l "objet
call_user_method_array ($ methodName, $ this, $ params);
}
}
Private function registerMethod ($ method) (
$ This -\u003e _ methods [$ method] \u003d true;
}
З полудня суботи на моєму сервері, де хоститься близько 25 сайтів на Wordpress, почалися дикі гальма. Так як мені вдалося пережити попередні атаки (,) непоміченими, то я не відразу зрозумів, в чому справа.
Коли розібрався, то з'ясувалося, що йде перебір паролів + безліч запитів до XMLRPC.
В результаті вдалося це все відсікти, хоча і не відразу. За катом три простих прийому, як цього уникнути.
Ці прийоми швидше за все всім відомі, але я наступив на пару граблів, яких не знайшов в описах - раптом це комусь заощадить час.
1. Зупиняємо перебір, плагін Limit Login Attempts - ставимо саме його, так як інші захисту сильно підвішують сервер, наприклад, при використанні плагіна Login Security Solution сервер помер через півгодини, плагін сильно вантажить базу.
У налаштуванні Обов'язково вкажіть галочку «За проксі» - інакше він буде для всіх визначати ip вашого сервера і автоматично блокувати всіх.
UPDATE, спасибі, подробиці нижче в коментах - галочку «За проксі» включаємо тільки якщо не працює визначення при включеному «Пряме підключення»
2. Відключаємо XML-RPC - плагін Disable XML-RPC (його просто активувати і все).
3. Закриваємо wp-login.php - якщо звертатися до сайту через ip, то плагін не спрацьовує і підбирачі продовжують довбати сайт. Щоб цього уникнути, в.htaccess додаємо:
Файл wp-login копіюємо, перейменовуємо в будь-дивне ім'я, наприклад poletnormalny.php і всередині файлу автозаміні міняємо всі написи wp-login.php на poletnormalny.php.
Все, тепер до адмінки можна звернутися тільки на вашу файлу.
Після цих 3 нескладних кроків сайти знову почали літати і прийшло спокій.
Ну і раптом цікаво
Один з варіантів як подивитися, що вас атакують. Це можна побачити в логах nginx (наприклад, ось шлях для Debian / var / log / nginx файл access.log).Введення в XML-RPC
У Мережі існує багато різних ресурсів, які надають користувачам певну інформацію. Маються на увазі не звичайні статичні сторінки, а, наприклад, дані, які добуваються з бази даних або архівів. Це може бути архів фінансових даних (курси валют, дані котирувань цінних паперів), дані про погоду, або ж більш об'ємна інформація - новини, статті, повідомлення з форумів. Така інформація може представлятися відвідувачеві сторінки, наприклад, через форму, як відповідь на запит, або ж кожен раз генеруватися динамічно. Але складність в тому, що часто така інформація потрібна не стільки кінцевому користувачу - людині, скільки іншим системам, програмами, які ці дані будуть використовувати для своїх розрахунків або інших потреб.
Реальний приклад: сторінка банківського сайту, на якій показуються котирування валют. Якщо ви заходите на сторінку як звичайний користувач, через браузер, ви бачите все оформлення сторінки, банери, меню і іншу інформацію, яка "обрамляє" справжню мету пошуку - котирування валют. Якщо вам треба вносити ці котирування в свій інтернет-магазин, то нічого іншого не залишиться, як тільки вручну виділити потрібні дані і через буфер обміну перенести на свій сайт. І так доведеться робити кожен день. Невже немає виходу?
Якщо вирішувати проблему "в лоб", то відразу напрошується рішення: програма (скрипт на сайті), якій треба дані, отримує сторінку від сервера як "звичайний користувач", розбирає (парсит) отриманий html-код і виділяє з нього потрібну інформацію. Це можна зробити або звичайним регулярним виразом, або за допомогою будь-якого html-парсера. Складність підходу - в його неефектівності. По-перше, для отримання невеликої порції даних (дані про валютах - це буквально десяток-другий символів) треба отримувати всю сторінку, а це не менше кількох десятків кілобайт. По-друге, при будь-якій зміні коду сторінки, наприклад, дизайн змінився або щось ще, наш алгоритм розбору доведеться переробляти. Та й ресурсів це буде відбирати порядно.
Тому розробники прийшли до рішення - треба розробити якийсь універсальний механізм, який би дозволив прозоро (на рівні протоколу і середовища передачі) і легко обмінюватися даними між програмами, які можуть перебувати де завгодно, бути написаними на будь-якій мові і працювати під управлінням будь-якої операційної системи і на будь-якій апаратній платформі. Такий механізм називають зараз гучними термінами "Веб-сервіси" (web-service), "SOAP", "архітектура, орієнтована на сервіси" (service-oriented architecture). Для обміну даними використовуються відкриті і перевірені часом стандарти - для передачі повідомлень протокол HTTP (хоча можна використовувати і інші протоколи - SMTP наприклад). Самі дані (в нашому прикладі - курси валют) передаються упакованими в крос-платформний формат - у вигляді XML-документів. Для цього придуманий спеціальний стандарт - SOAP.
Так, зараз веб-сервіси, SOAP і XML у всіх на слуху, їх починають активно впроваджувати і великі корпорації на кшталт IBM і Microsoft випускають нові продукти, покликані допомогти тотального впровадження веб-сервісів.
Але! Для нашого прикладу з курсами валют, які повинні передаватися з сайту банку в движок інтернет-магазину таке рішення буде дуже складним. Адже тільки опис стандарту SOAP займає непристойні півтори тисячі сторінок, і це ще не все. Для практичного використання доведеться вивчити ще роботу зі сторонніми бібліотеками і розширеннями (тільки починаючи з PHP 5.0 в нього входить бібліотека для роботи з SOAP), написати сотні і тисячі рядків свого коду. І все це для отримання декількох букв і цифр - явно дуже ваговито і нераціонально.
Тому існує ще один, з натяжкою можна сказати альтернативний стандарт на обмін інформацією - XML-RPC. Він був розроблений за участю Microsoft компанією UserLand Software Inc і призначений для уніфікованої передачі даних між додатками через Інтернет. Він може замінити SOAP при побудові простих сервісів, де не треба все "корпоративні" можливості справжніх веб-сервісів.
Що ж означає абревіатура XML-RPC? RPC розшифровується як Remote Procedure Call - віддалений виклик процедур. Це означає, що додаток (неважливо, скрипт на сервері або звичайна програма на клієнтському комп'ютері) може прозоро використовувати метод, який фізично реалізований і виповнюється на іншому комп'ютері. XML тут застосовується для забезпечення універсального формату опису переданих даних. Як транспорт, для передачі повідомлень застосовується протокол HTTP, що дозволяє безперешкодно обмінюватися даними через будь-які мережеві пристрої - маршрутизатори, фаєрволи, проксі-сервера.
І так, для використання треба мати: сервер 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 не може залишатися порожнім, але може містити довільне значення.
Далі йде звичайний заголовок XML-документа. Кореневий елемент запиту -
рядок
Далі задаються передані параметри. Для цього служить секція
Після опису всіх параметрів слідують закривають теги. Запит і відповідь в XML-RPC це звичайні документи XML, тому всі теги обов'язково повинні бути закриті. А ось одиночних тегів в XML-RPC немає, хоча в стандарті XML вони присутні.
Tеперь розберемо відповідь сервера. Тема HTTP відповіді звичайний, якщо запит успішно оброблений, то сервер повертає відповідь HTTP / 1.1 200 OK. Також як в запиті, слід коректно вказати MIME-тип, довжину повідомлення та дату формування відповіді.
Саме тіло відповіді наступне:
Тепер замість кореневого тега
Якщо при обробці вашого запиту сталася помилка, то замість У відповіді буде елемент
А тепер розглянемо коротко типи даних в XML-RPC. Всього типів даних є 9 - сім простих типів і 2 складних. Кожен тип описується своїм тегом або ключовими словами (для складних типів).
Прості типи:
Цілі числа - тег
логічний тип - тег
ASCII-рядок - описується тегом
Числа з плаваючою точкою - тег
дата і час - описується тегом
Останнім простим типом є рядок, закодована в base64, Яка описується тегом
Складні типи представлені структурами і масивами. Структура визначається кореневим елементом
Масиви не мають назв і описуються тегом
Звичайно, хтось скаже, що такий перелік типів даних дуже бідний і "не дозволяє розвернутися". Так, якщо треба передавати складні об'єкти, або великі обсяги даних, то краще використовувати SOAP. А для невеликих, невимогливих додатків цілком підходить і XML-RPC, більш того, дуже часто навіть його можливостей виявляється занадто багато! Якщо врахувати легкість розгортання, дуже велика кількість бібліотек для майже будь-яких мов і платформ, широку підтримку в PHP, то XML-RPC часто просто не має конкурентів. Хоча відразу радити його в якості універсального рішення не можна - в кожному конкретному випадку треба вирішувати по обставинах.
Прошивка для htc one sv з флешки
Чому гріється ноутбук і що з цим робити?
Скидання до заводських налаштувань смартфонів Samsung