IAA, Redirector та XSS уразливості в WordPress
23:56 26.04.2012Окрім згаданих мною в 2007 році двох редиректорів (які окрім Redirector, також уразливі до XSS), є багато інших редиректорів. І один зі знайдених мною 13.02.2012 редиректорів (хоча захистився від нього я ще на початку 2007 року) я оприлюдню зараз, а з часом й інші редиректори.
Ще з WP 2.0 є Insufficient Anti-automation, Redirector і Cross-Site Scripting уразливості в wp-comments-post.php. З IAA я стикнувся одразу, як почав використовувати WP в 2006 році. Якщо розробники виправили попередні два редиректори (і уразливості в них) в WP 2.3, то ці уразливості не виправлені навіть в WP 3.3.1.
Раніше я вже писав про DoS та SQL Injection уразливості в WordPress.
Insufficient Anti-automation:
Відсутність капчі в формі коментарів дозволяє проводити автоматизовані атаки. Розробники досі не встановили капчу в форму коментарів WP (з першої версії движка), що окрім IAA атак, також дозволяє проводити Redirector і XSS атаки.
По замовчуванню в WordPress включена премодерація, а також існує вбудований анти-спам фільтр. Якщо 10 років тому премодерації вистачило б, то вже давно цей механізм не може вважатися достатнім захистом від спаму, а анти-спам фільтр має ефективність менше 1% - лише деякі зі спам повідомлень він помічає як спам. А також ці механізми не захищають від нижченаведених атак. Також з WP постачається плагін Akismet, що захищає від спаму “без капчі”. Але по замовчуванню він відключений та порівняно з капчею вважається менш надійним і також не захищає від нижченаведених атак.
Redirector (URL Redirector Abuse):
XSS:
XSS атака можлива на різні браузери, але її провести важче ніж у випадку попередніх двох редиректорів (через data URI). На веб серверах IIS редирект відбувається через заголовок Refresh, а на інших веб серверах - через заголовок Location.
В зв’язку з особливостями роботи даного скрипта (фільтрація важливих символів та додавання якорю), для виконання JS коду потрібно використовувати хитрі обхідні методи. При цьому, якщо редирект відбувається через заголовок Location, код спрацьовує в Opera 10.62 і він повинен працювати в Firefox, IE6 і Chrome, але різні версії Firefox (та IE6 і Chrome) упорно ігнорують даний заголовок (виводячи лише пусту сторінку) - при тому, що окремо заголовок Location з даним кодом спрацьовує в Firefox і в інших браузерах, але не в рамках WordPress. З комбінованим варіантом javascript URI + data URI та сама ситуація.
Для цих атак непотрібно мати акаунт на сайті й немає значення чи увімкнена премодерація або плагін Akismet. Єдине що може захистити від цих атак - це капча в формі коментарів, причому надійна (або повне виключення коментарів, але з капчею можна продовжити використовувати цей функціонал). Таким чином капча захищає як від IAA, так і від Redirector та XSS уразливостей.
Уразливі WordPress 2.0 - 3.3.1.
Четвер, 23:11 10.05.2012
Что касается “розробники досі не встановили капчу в форму коментарів WP”, то, я думаю, они делают это сознательно. Потому что капча далеко не всем подходит, многие блогеры не готовы жертвовать удобством своих читателей, заставляя их напрягаться над капчей.
Четвер, 23:14 10.05.2012
Кстати, актуальная на данный момент версия оперы - 11.62. Почему в статье делается упор именно на версию 10.62? Или это опечатка?
П'ятниця, 21:11 11.05.2012
Добрий день.
А ви могли б розповісти докладніше про такий вид атаки як “HTTP Verb Tampering”?
Дуже мало російськомовних і вже тим більше україномовних статей на цю тему. Та й ті що є, більше розраховані на підготовлених фахівців.
Було б добре, якби ви написали статтю на цю тему, з прикладами.
Вибачте що коментар не по темі.
Вівторок, 19:38 15.05.2012
ss, звичайно я можу про це написати. І звичайно варто писати коментарі по темі
.
В мене є багато планів стосовно статей (потрібно лише час для них знаходити), але я додам цю тему по мого переліку запланованих статей. Раз є такий запит від читачів.
Атака HTTP Verb Tampering не є поширеною, тому що уразливості (некоректні налаштування), які до неї призводять, дуже рідкі. Наприклад, мені вони ні разу не траплялися. Тому й не було потреби про них писати, зате я писав про інші уразливості/атаки, в тому числі й рідкі, які мені траплялися під час аудитів і пентестів.
Неділя, 23:59 03.06.2012
сисадмин
Так и есть. С одной стороны им лень (они сами до сих пор с 2005 года не сделали капчу, под WordPress разработаны лишь капчи сторонних разработчиков), с другой стороны - они дыроделы и любят создавать уязвимости, том числе и за счёт отсутствия капчи во всех тех функционалах где она могла бы быть использована для защиты (а таких дыр много, о чём я не раз писал). А с третьей стороны они думает и об юзабилити, поэтому не решаются устанавливать капчу (в том числе учитывая первые два аспекта, они пытаются свою лень и нежелание следить за безопасностью “аргументировать” заботой об юзабилити).
При этом в тех местах где капчу для защиты они не ставят, они и других защитных механизмом не делают - или вообще игнорируют, или через многие годы, после многочисленных напоминаний со стороны секюрити исследователей, могут начать что-то исправлять. Так что, без сомнения, они делают это сознательно
(и забота о пользователях в ущерб безопасности лишь третья причина подобных действий). В некоторых случаях эти дыры могут исправить пользователи - установкой капчи - но у них те же проблемы, что и у разработчиков WP (поэтому мало кто ставит капчу). Так что традиционно юзабилити более приоритетная, чем безопасность.
Так званое удобство для читателей не должно быть в ущерб безопасности. И естественно многие уязвимости, которые можно исправить или “минимизировать” с помощью капчи, также можно решить другими методами. Главное, это делать, а ни забивать, как это типично для разработчиков WP и многих других движков.
Касательно Opera, то вопросы стоит задавать в комментариях к соответствующей записи. Это я тестировал в версии 10.62, поэтому и указана эта версия.