Систематична вразливість сайтів, створених на CMS 1С-Бітрікс

Написати про систематичні вразливості сайтів, створених на комерційних CMS, підштовхнув посада, в якому були описані ризики злому «захищених» CMS.

У цій статті основну увагу приділяється компрометації ресурсів внаслідок «людського фактора», а тема експлуатації вразливостей сайтів і веб-атак була обійдена припущенням існування «невразливих» CMS. Припущення про існування «невразливих» CMS, можливо, має право на існування, як приклад, безпека готового інтернет-магазину «з коробки» на CMS 1C-Бітрікс дуже висока, і знайти більш-менш серйозні уразливості коду «коробкової версії» навряд чи вдасться.

Інша справа безпеку кінцевого продукту, створеного на такий CMS, і найголовніше, систематика прояви вразливостей високого рівня загроз у цих сайтів. Виходячи з нашої практики по забезпеченню безпеки сайтів (компанія InSafety), а також статистики, яку ми збираємо за вразливостей платформ (CMS), не менше п'ятдесяти відсотків сайтів, створених на платформі 1С-Бітрікс c особистими кабінетами користувачів, існує можливість експлуатації збережених XSS-атак.

Платформа: CMS 1C-Бітрікс 15.0 і вище
Загроза безпеки: збережена XSS-атака
Систематика: не менше 50% сайтів з особистими кабінетами користувачів
Уразливість коду, що дозволяє експлуатацію XSS атаки, полягає в недостатній фільтрації даних полів реєстраційної форми інформації особистого кабінету користувача ресурсу, які передаються в БД.

Приклад

Розробник зберігає дані, наприклад, ім'я користувача з $_REQUEST, через API Битрикса, то вони не фільтруються повністю, і теги зберігаються. Наприклад, передаємо рядок в поле форми «ім'я» ЛК користувача сайту:

test"><a href='#'><img src='http://insafety.org/img/xss2.jpg'/></a><p

image
Дані передаються через звичайний input $_POST['name'] і далі в $USER->Update, наприклад, так:

$USER->Update($USER->GetID(),array(
'NAME' => $_POST['name'],
));

HTML-код не буде сановані і буде запомнен імені користувача «як є». Скріншот адмінки сайту:

image
Результат:

image

Цей приклад наочно демонструє наявність загрози безпеки

У запропонованій демонстрації існування загрози, було показано впровадження HTML коду, а не JS, що передбачає типова XSS-атаки. Це обумовлено тим, що у більшості сайтів, розроблених на CMS 1C-Бітрікс, спробу впровадження JS-коду заблокує фільтр проактивного захисту.

Впровадження більшості синтаксичних тегів HTML коду, проактивним захистом CMS 1C-Бітрікс не фільтрується. Така демонстрація виявлення уразливості коду абсолютно безпечна і наочна. У разі, коли фільтр проактивного захисту 1С-Бітрікс з якоїсь причини відключений, вищеописана вразливість коду дозволяє експлуатувати збережені XSS-атаки в «класичної» реалізації.

Рівень загрози безпеки для сайту від впровадження будь-кого (будь то JS або HTML) несанкціонованого коду, як і його виведення без належної фільтрації, вкрай високий.

Зі зрозумілих причин, в цій статті не пропонуються варіанти реальної експлуатації атаки, як з включеним, так і з відключеним фільтром проактивного захисту.

Захист від XSS-атаки
Захистити свій сайт від можливості експлуатації XSS атаки досить просто. Для цього слід фільтрувати вхідні і вихідні дані шляхом екранування символів і перетворення спецсимволов в HTML-сутності. В php це можна зробити за допомогою функцій htmlspecialchars(), htmlentities(), strip_tags().

Приклад:

$name = strip_tags($_POST['name']);
$name = htmlentities($_POST['name'], ENT_QUOTES, "UTF-8");
$name = htmlspecialchars($_POST['name'], ENT_QUOTES);

Крім цього слід явно вказувати кодування сторінок сайту:

Header("Content-Type: text/html; charset=utf-8");

Способів захисту від XSS атак безліч, наприклад, існують варіанти заборони на передачу лапки і дужки (фільтрація даних по чорному списку) на рівні конфігурації веб-сервера.

Приклад для NGINX: запис в конфігураційний файл

location / {
if ($args ~* '^.*(<|>|").*'){
return 403; 
}
if ($args ~* '^.*(%3C|%3E|%22).*'){
return 403;
}
}

Для веб-сервера Apache це буде запис в файл .htaccess:

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} (<|>|"|%3C|%3E|%22) [NC,OR]
RewriteRule ^{правило} 

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

Висновок
Зазначена вище загроза безпеці на веб-додатки, що є найбільш популярною і відомою атакою. Про XSS атаки і захист від них, написано тисячі статей і публікацій.

У практиці нашої компанії вразливість до XSS атак особистих кабінетів користувачів була виявлена восени 2015 року. Навесні 2016 року наша статистика уразливих сайтів на CMS 1С-Бітрікс явно вказувала на наявність можливості експлуатації атаки у понад 50% відсотків досліджуваних сайтів. У квітні 2016 року, розуміючи, що уразливість коду у цьому розділі носить системний характер, ми передали всю інформацію про загрозу безпеці в компанію Бітрікс. Співробітники компанії Бітрікс взяли інформацію, повідомивши зворотного зв'язку, що прийняли заходи, виправивши документацію до системи. Незважаючи на вжиті заходи, вищезгадана загроза безпеки для сайтів на 1С-Бітрікс залишається вкрай актуальною на сьогоднішній день.

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

Потрібно розуміти, що експерименти з безпекою чужих сайтів, не кажучи про експлуатації атаки в кримінальних цілях, може спричинити кримінальну відповідальність. Вся інформація за загрозу безпеці сайтів, в цьому пості, надана з метою підвищення загального рівня ІБ кінцевих продуктів на платформі 1C-Бітрікс.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.