Як створити власну сторінку реєстрації WordPress Multisite. Використання бібліотеки TGM Plugin Activation у темах WordPress Міркування activate php

Сьогодні ми розглянемо експлуатацію критичної 1day-уразливості у популярній CMS Joomla, яка прогриміла на просторах інтернету наприкінці жовтня. Йтиметься про вразливості з номерами CVE-2016-8869, CVE-2016-8870і CVE-2016-9081. Усі три походять з одного шматочка коду, який п'ять довгих років нудився в надрах фреймворку в очікуванні свого часу, щоб потім вирватися на волю і принести з собою хаос, зламані сайти та сльози ні в чому не винних користувачів цієї Joomla. Лише найдоблесніші і сміливіші розробники, чиї очі червоні від світла моніторів, а клавіатури завалені хлібними крихтами, змогли кинути виклик нечисті, що розбушувалася, і покласти її голову на вівтар фіксів.

WARNING

З чого все почалося

6 жовтня 2016 Деміс Пальма (Demis Palma) створив топік на Stack Exchange , в якому поцікавився: а чому, власне, в Joomla версії 3.6 існують два методи реєстрації користувачів з однаковою назвою register() ? Перший знаходиться в контролері UsersControllerRegistration, а другий - у UsersControllerUser. Деміс хотів дізнатися, чи використовується десь метод UsersControllerUser::register() , або це лише еволюційний анахронізм, що залишився від старої логіки. Його турбував той факт, що навіть якщо цей метод не використовується жодним уявленням, він може бути викликаний за допомогою сформованого запиту. На що отримав відповідь від девелопера під ніком itoctopus, який підтвердив: проблема справді існує. І направив звіт розробникам Joomla.

Далі події розвивалися найшвидшим чином. 18 жовтня розробники Joomla приймають репорт Деміса, який на той час накидав PoC, що дозволяє реєструвати користувача. Він опублікував замітку на своєму сайті, де загалом розповів про знайдену проблему та думки з цього приводу. Цього ж дня виходить Нова версія Joomla 3.6.3, яка все ще містить вразливий код.

Після цього Давид Тампелліні (Davide Tampellini) розкручує баг до стану реєстрації не простого користувача, а адміністратора. І вже 21 жовтня команді безпеки Joomla прилітає новий кейс. У ньому вже йдеться про підвищення привілеїв. У цей же день на сайті Joomla з'являється анонс про те, що у вівторок, 25 жовтня, буде випущено чергову версію з порядковим номером 3.6.3, яка виправляє критичну вразливість в ядрі системи.

25 жовтня Joomla Security Strike Team знаходить останню проблему, яку створює виявлений Деміс шматок коду. Потім у головну гілку офіційного репозиторію Joomla пушиться коміт від 21 жовтня з непримітною назвою Prepare 3.6.4 Stable Release, який фіксує злощасний баг.

Після цього камін-ауту до міжсобойчика розробників підключаються численні зацікавлені особи - починають розкручувати вразливість і готувати сплоїти.

27 жовтня дослідник Гаррі Робертс (Harry Roberts) викладає в репозиторій Xiphos Research готовий експлоїт, який може завантажувати PHP-файл на сервер із вразливою CMS.

Деталі

Що ж, з передісторією покінчено, переходимо до найцікавішого – розбору вразливості. Як піддослідна версія я встановив Joomla 3.6.3, тому всі номери рядків будуть актуальні саме для цієї версії. А всі шляхи до файлів, які ти побачиш далі, вказуватимуться щодо кореня встановленої CMS.

Завдяки знахідці Деміса Пальми ми знаємо, що є два методи, які виконують реєстрацію користувача у системі. Перший використовується CMS і знаходиться у файлі /components/com_users/controllers/registration.php:108. Другий (той, що нам і потрібно буде викликати), живе в /components/com_users/controllers/user.php:293. Подивимося на нього ближче.

286: /** 287: * Method to register a user. 288: * 289: * @return boolean 290: * 291: * @since 1.6 292: */ 293: public function register() 294: ( 295: JSession::checkToken("post") or jexit(JText::_ ("JINVALID_TOKEN"));... 300: // Get the form data.301: $data = $this->input->post->get("user", array(), "array"); .. 315: $return = $model->validate($form, $data); 316: 317: // Check for errors. / Finish the registration 346: $return = $model->register($data);

Тут я залишив лише цікаві рядки. Повну версію вразливого методу можна переглянути у репозиторії Joomla.

Розберемося, що відбувається при звичайній реєстрації користувача: які дані надсилаються та як вони обробляються. Якщо реєстрація користувачів включена в налаштуваннях, форму можна знайти за адресою http://joomla.local/index.php/component/users/?view=registration .

Легітимний запит на реєстрацію користувача виглядає як наступний скріншот.

За роботу з користувачами відповідає компонент com_users. Зверніть увагу на параметр task у запиті. Він має формат $controller.$method. Погляньмо на структуру файлів.

Імена скриптів у папці controllersвідповідають назвам контролерів, що викликаються. Так як у нашому запиті зараз $controller = "registration", то викличеться файл registration.phpта її метод register() .

Увага, питання: як передати обробку реєстрації вразливе місце в коді? Ти, напевно, вже здогадався. Імена вразливого і реального способів збігаються (register), тому нам досить змінити назву викликаного контролера. А де в нас знаходиться вразливий контролер? Правильно, у файлі user.php. Виходить $controller = "user". Збираємо всі разом і отримуємо task=user.register. Тепер запит на реєстрацію опрацьовується потрібним нам методом.

Друге, що нам потрібно зробити, - це надіслати дані у правильному форматі. Тут усе просто. Легітимний register() чекає від нас масив під назвою jform, в якому ми передаємо дані для реєстрації - ім'я, логін, пароль, пошту (див. скріншот із запитом).

• /components/com_users/controllers/registration.php: 124: // Get the user data. 125: $requestData = $this->input->post->get("jform", array(), "array");

Наш підопічний отримує ці дані з масиву з ім'ям user.

• /components/com_users/controllers/user.php: 301: // Get the form data. 302: $data = $this->input->post->get("user", array(), "array");

Тому змінюємо у запиті імена всіх параметрів із jfrom на user.

Третій наш крок - це знаходження валідного токена CSRF, тому що без нього жодної реєстрації не буде.

• /components/com_users/controllers/user.php: 296: JSession::checkToken("post") або jexit(JText::_("JINVALID_TOKEN"));

Він виглядає як хеш MD5, а взяти його можна, наприклад, із форми авторизації на сайті /index.php/component/users/?view=login.

Тепер можна створювати користувачів через потрібний метод. Якщо все вийшло, то вітаю - ти щойно проексплуатував уразливість CVE-2016-8870"відсутня перевірка дозволів на реєстрацію нових користувачів".

Ось як вона виглядає в робочому методі register() з контролера UsersControllerRegistration:

• /components/com_users/controllers/registration.php: 113: // If registration is disabled - Redirect to login page. 114: if (JComponentHelper::getParams("com_users")->get("allowUserRegistration") == 0) 115: ( 116: $this->setRedirect(JRoute::_("index.php?option=com_users&view= login", false)); 117: 118: return false; 119: )

А так у вразливому:

• /components/com_users/controllers/user.php:

Ага, ніяк.

Щоб зрозуміти другу, набагато серйознішу проблему, відправимо сформований нами запит і простежимо, як він виконується на різних ділянках коду. Ось шматок, який відповідає за перевірку надісланих користувачем даних у робочому методі:

Продовження доступне лише учасникам

Варіант 1. Приєднайтесь до спільноти «сайт», щоб читати всі матеріали на сайті

Членство у спільноті протягом зазначеного терміну відкриє тобі доступ до ВСІХ матеріалів «Хакера», збільшить особисту накопичувальну знижку та дозволить накопичувати професійний рейтинг Xakep Score!

Створюємо власну сторінку реєстрації для мультисайту замість стандартної wp-signup.php.

У звичайному встановленні WordPress сторінку реєстрації (авторизації, скидання пароля) виводить файл wp-login.php .

• /wp-login.php - авторизація
• /wp-login.php?action=register - реєстрація
• /wp-login.php?action=lostpassword - скидання пароля

Для мультисайту у wp-login.php є окремі умови. Так, при переході за посиланням /wp-login.php?action=register на мультисайті WordPress зробить редирект на сторінку /wp-signup.php . У багатьох темах сторінка виглядає не дуже привабливо, тому ми зробимо власну.

Основний сайт мережі

За промовчанням WordPress відкриває сторінку реєстрації (wp-signup.php) на основному домені (сайті) мережі. Проте, можна зробити окрему сторінку реєстрації для кожного сайту мережі, навіть якщо вони мають різні теми. Ми розглядатимемо випадок, коли на всіх сайтах мережі є своя власна сторінка реєстрації, але використовується однакова тема і сайти відрізняються лише мовою. Якщо використовуються різні теми, потрібно написати більше коду.

functions.php?

Ні. Ім'я цього файлу, здається, згадується у будь-якій статті про WordPress. У нашому випадку, з урахуванням того, що функціонал реєстрації розрахований на кілька сайтів, є сенс винести його в MU-плагіни, які завантажуються при відкритті будь-якого сайту.

Ліричний відступ

Варто зазначити, що MU-плагіни завантажуються раніше за звичайні плагіни і до повного завантаження ядра WordPress, тому виклик деяких функцій може призвести до фатальних помилок у PHP. Подібне «раннє» завантаження має свої плюси. Скажімо, всередині будь-якої теми не можна чіплятися до деяких екшенів, які спрацьовують ще до завантаження файлу functions.php з теми. Прикладом цього можуть бути екшени з плагіну Jetpack виду jetpack_module_loaded_related-posts (related-posts - назва модуля) за допомогою яких можна відстежувати активність модулів в Jetpack. До цього екшену неможливо "причепитися" з файлу теми, тому що екшен вже спрацював до завантаження теми - плагіни завантажуються раніше. Подивитися на загальну картинку порядку завантаження WordPress можна на сторінці Action Reference у кодексі.

Порядок у файлах

MU-плагіни можуть містити будь-яку кількість файлів та будь-яку структуру, яка здасться вам логічною. Я дотримуюсь приблизно такої ієрархії:

|-mu-plugins |-|-load.php |-|-|-selena-network |-|-|-|-signup |-|-|-|-|-plugin.php |-|-|-| -|-... |-|-|-|-jetpack |-|-|-|-|-plugin.php

У файлі load.php підключаються всі необхідні плагіни для нашої мережі:

// Load Traslates for all addons load_muplugin_textdomain ("selena_network", "/selena-network/languages/"); // Network Signup require WPMU_PLUGIN_DIR . "/selena-network/signup/plugin.php"; // Інші plugins // require WPMU_PLUGIN_DIR ...

Усередині папки selena-network зберігаються папки плагінів, у кожній є свій plugin.php , які ми підключаємо в load.php . Це дає гнучкість та можливість швидко відключати та включати деякі речі.

Адреса сторінки реєстрації

Щоб вказати адресу сторінки реєстрації, використовується фільтр wp_signup_location . Його можна знайти всередині файлу wp-login.php і саме він відповідає за редирект на wp-signup.php.

Case "register" : if (is_multisite()) ( wp_redirect(apply_filters("wp_signup_location", network_site_url("wp-signup.php"))));

Додамо свою функцію до mu-plugins/selena-network/signup/plugin.php , яка буде віддавати адресу сторінки реєстрації на поточному сайті:

Function selena_network_signup_page ($url) ( return home_url () . "/signup/"; ) add_filter ("wp_signup_location", "selena_network_signup_page", 99);

selena_network - префікс, який я використовую в іменах всіх функцій усередині MU-плагінів на своєму сайті для запобігання колізії, його слід замінити на свій власний унікальний префікс. Пріоритет додавання фільтра 99, тому що деякі плагіни, наприклад bbPress і BuddyPress можуть перезаписати цю адресу на свою власну (MU-плагіни завантажуються раніше, ніж звичайні плагіни, див вище). Зверніть увагу, що використовується home_url() замість network_site_url() , щоб залишити відвідувача на тому ж домені. Як адресу можна використовувати будь-яку URL-адресу.

Створення сторінки

Тепер створимо сторінку з адресою site.com/signup/ через звичайний інтерфейс, а у папці дочірньої теми шаблон для нашої нової сторінки- page-signup.php. Замість слова signup можна використовувати унікальний ID.

Всередині нового шаблону необхідно виконати функцію selena_network_signup_main() , яка виводитиме форму реєстрації.

Варто зауважити, що весь процес із шаблонами не є обов'язковим і замість цього можна створити свій шорткод, який також викликатиме функцію selena_network_signup_main() .

wp-signup.php та wp-activate.php

Тепер займемося створенням функції, яка виводитиме форму реєстрації. Для цього скопіюємо файли wp-signup.php та wp-activate.php з кореня WordPress у mu-plugings/selena-network/signup/ (і не забуваємо їх підключити всередині mu-plugins/selena-network/signup/plugin.php) . Подальші маніпуляції з файлами дуже складно і довго описувати, тому доведеться зробити їх самостійно. Я лише опишу, що саме треба зробити і опублікую вихідні файли свого проекту:

1. На початку файлу видалити всі require , виклик функцій та інший код поза функціями.
2. Перейменувати всі функції, додавши унікальні префікси до імен.
3. Нижню частину коду wp-signup.php обернути в функцію selena_network_signup_main і на початку написати global $active_signup; .
4. Замінити верстку на власну в потрібних місцях.

Всередині wp-activate.php необхідно зробити приблизно те саме:

1. Видалити весь код поза функціями, обернути верстку на окрему функцію.
2. Змінити верстку у місцях, де це необхідно.

Файл wp-activate.php відповідає за сторінку активації облікового запису. Як і зі сторінкою реєстрації, для неї необхідно створити окремий шаблон, усередині якого викликати функцію з файлу wp-activate.php .

Надсилаємо листи активації

Сторінка реєстрації надсилає відвідувачу листа з посиланням на активацію облікового запису. За замовчуванням цим займається функція wpmu_signup_user_notification() із файлу ms-functions.php . Її функціонал можна запозичувати для своєї функції. Причина, через яку необхідно відмовитися від використання цієї функції - вона відправляє посилання активації облікового запису з wp-activate.php . "Вимкнути" ж цю функцію можна за допомогою фільтра wpmu_signup_user_notification віддаючи по ньому false (якщо цього не зробити, лист активації буде відправлятися двічі, окей, насправді два різні листи).

Function armyofselenagomez_wpmu_signup_user_notification($user, $user_email, $key, $meta = array()) ( // ... // Код з функції wpmu_signup_user_notification() wp_mail($user_email, wp_specialchars_decode($subject), ; return false; ) add_filter("wpmu_signup_user_notification", "armyofselenagomez_wpmu_signup_user_notification", 10, 4);

В результаті сторінка реєстрації в темі Селена стала виглядати набагато чистіше та акуратніше.

Висновок

В інтернеті безліч інших не дуже правильних способів того, як зробити те саме - редиректи Apache, AJAX-форми, які не працюватимуть без Java Scriptі т. п. Все це мені не дуже сподобалося, тому я постарався зробити це максимально правильно на власному сайті.

Зауважу, що правити файли слід обережно і намагатися не сильно відходити від вихідних, щоб у подальшому, якщо WordPress змінить файли wp-signup.php і wp-activate.php, їх простіше було порівнювати між собою для пошуку змін.

Не забувайте дивитися в вихідний кодвсіх описаних вище функцій повністю розібратися з тим, що і як відбувається всередині коду.

Бонус. Захист від спамерів

Навіть найменші сайти на WordPress часто зазнають нальоту спам-реєстрацій. Можна писати нескінченні умови для фільтрації ботів, які часто більше схожі на спробу створити штучний інтелект🙂 У разі мультисайту мені дуже допоміг звичайний редирект в Apache, за допомогою якого при відкритті /wp-signup.php та /wp-acitvate.php я попросив видавати 404 (я не експерт з налаштування Apache, тому мої правила можуть бути не дуже правильними ).

RewriteEngine On RewriteBase / RewriteRule ^wp-signup\.php - RewriteRule ^wp-activate\.php - # BEGIN WordPress # Правила від WordPress за замовчуванням не чіпаємо:) # ... # END WordPress

PS Я намагаюся максимально детально описувати деякі сторонні речі, тому що коли починав я, часом не було кому підказати і пояснити багато речей. Також я вважаю, що подібні невеликі наведення на інші матеріали когось підштовхнуть до вивчення чогось нового та розширення своєї галузі знань. У записах RewriteRule використовуються Регулярні вирази, вони зовсім не складні, наприклад, символ означає початок рядка.

Одноразові посилання можна використовувати в різних ситуаціях: для того, щоб надати тимчасовий доступ до файлу або сторінки, або для підтвердження реєстрації. У цьому уроці ми покажемо, як згенерувати та впровадити одноразові URL-адреси.

Створення URL

Припустимо, що у нас на сайті є система автентифікації користувачів. Після реєстрації ми просимо користувача пройти процедуру верифікації електронної пошти. Для створення подібних посилань можемо скористатися спеціальним параметром token. Приклад такого посилання:

Http://example.com/activate?token=ee97780...

Без бази даних тут нам не обійтися, тому давайте подивимося на таблицю, з якою працюватимемо.

CREATE TABLE pending_users (token CHAR(40) NOT NULL, username VARCHAR(45) NOT NULL, tstamp INTEGER UNSIGNED NOT NULL, PRIMARY KEY(token));

У таблиці зберігатимемо 3 поля: токен, ім'я користувача та час. Для генерації токена ми скористаємося функцією sha1(), яка видає рядок із 40 символів. Поле tstamp буде зберігати час генерації токена для того, щоб ми могли відстежити посилання з терміном, що минув.

Існує безліч способів генерації токена, однак у цьому уроці ми скористаємося функціями uniqid() та sha1(). Незалежно від способу генерації токена, переконайтеся, що значення, що генеруються, будуть різними і ймовірність появи дублікатів мінімальна.

$token = sha1(uniqid($username, true));

Як параметр функція uniqid() приймає рядок, а на виході дає унікальний ідентифікатор, що базується на переданому аргументі та поточному часі. Також, як другий аргумент, дана функція набуває булевого значення, яке дасть сигнал uniqid додати кілька додаткових символів для збільшення ймовірності унікальності значення. Функція sha1 приймає унікальний ідентифікатор та створює хеш.

Після роботи цих двох функцій, ми матимемо унікальний токен, який можемо використовувати для генерації url адрес. Тепер нам потрібно занести його до бази:

$query = $db->prepare("INSERT INTO pending_users (username, token, tstamp) VALUES (?, ?, ?)"); $query->execute(array($username, $token, $_SERVER["REQUEST_TIME"])));

Щоб ми знали, якого користувача слід активувати, в таблицю записуватимемо і логін користувача. У прикладі, більш адаптованому для реального сайту, можете скористатися ID користувача.

Тепер, коли ми маємо всю необхідну інформацію, можемо створити тимчасову url адресу:

$url = "http://example.com/activate.php?token=$token";

$message =<<

Перевірка

Тепер нам потрібен скрипт, завдяки якому ми здійснюватимемо перевірку. Все, що нам потрібно зробити, це порівняти токен з url адреси і токен з бази. Якщо така є, і час її життя не минув, то все ОК.

// отримуємо токен if (isset($_GET["token"]) && preg_match("/^(40)$/i", $_GET["token"])) ( $token = $_GET["token"] ; ) else ( throw new Exception("токен не валідний."); ) // перевіряємо токен $query = $db->prepare("SELECT username, tstamp FROM pending_users WHERE token = ?"); $query->execute(array($token)); $row = $query->fetch(PDO::FETCH_ASSOC); $query->closeCursor(); if ($row) ( extract($row); ) else ( throw new Exception("токен не валідний."); ) // активуємо акаунт користувача // ... // видаляємо токен з бази $query = $db- >prepare("DELETE FROM pending_users WHERE username = ? AND token = ? AND tstamp = ?",); $query->execute(array($username, $token, $tstamp));

Також нам потрібно передбачити перевірку токенів, час життя яких минув.

// 1 день на секундах = 60 секунд * 60 хвилин * 24 години $delta = 86400; // перевірка if ($_SERVER["REQUEST_TIME"] - $tstamp > $delta) ( throw new Exception("час життя токена минув."); ) // активуємо обліковий запис користувача // ...

Таким чином, у нас будуть здійснюватись дві перевірки: одна на валідність токена, інша на час його існування.

Підсумок

Цей метод можна застосувати не тільки для активації облікових записівкористувачів, а й у інших потребах: наприклад, надання одноразового чи тимчасового доступу до якогось ресурсу чи послузі.

До того ж, ви можете створити скрипт, який видалятиме токени, якими жодного разу не користувалися. Даний скрипт можна запускати самим іноді або застосувати для цього cron.