Всем привет.
В данной статье расскажу, как можно проверить плагины к сайтам, таким как Wordpress, XenForo и т.д.
Данная статья родилась, когда я решил проверить установленные плагины для XenForo на уязвимости XSS и SQL inject и к удивлению нашел парочку недочетов.
Тем не менее статья не будет написана к конкретному движку, а советы как проверить, будут универсальными и будет приведен пример XSS уязвимости в чате XenForo.
Итак изначально небольшая теория, какие могут-быть атаки на ваш сайт и зачем:
1)XSS (англ. Cross Site Scripting — «межсайтовый скриптинг») — Смысл данной атаки в исполнении кода на стороне жертвы.
Атака заключается в исполнении кода на стороне браузера, смысл такой, если сайт позволяет вставлять сообщения пользователям, например регистрация пользователей, вставка сообщений и т.д.
То если эти сообщения не будут фильтроваться, можно подготовить специальный HTML – код, который выполнится на стороне жертвы, вплоть до замены сайта нужным вам содержимым (дефейс)…)))
XSS я разделяю на два типа:
1 - Пассивные XSS – Для атаки нужно подготовить ссылку и дать эту ссылку жертве, после перехода по ней, будет исполнение нужного кода.
Пример: http://example.com/search.php?q=<script>alert("I am XSS")</script>
Если сайт уязвим, то при переходе, будет такое окошко:
2 - Активный XSS (Пример этой уязвимости мы разберем, на боевом моем сайте):
Ну для активной XSS не нужно готовить никакой ссылки, вредоносный код будет исполняться на стороне пользователя автоматически, достаточно лишь подготовить специальный HTML код и вставить его в форму ввода, помню по молодости дефейсили так сайты и форумы.)))
Очень опасная уязвимость, так-как таким образом можно полностью подменить сайт, или его части, например форму ввода кредитных карт, помню именно так кардеры воруют данные кредиток у уязвимых магазинах.)
2) CSRF (англ. Сross Site Request Forgery — «Межсайтовая подделка запроса», также известен как XSRF).
Смысл заключается в том, что бы от имени пользователя совершать какие-либо действия...
Например, если здесь на форуме будет найдена XSS, можно через эту XSS от имени жертвы создавать темы, переписки и т.д.
Ещё пример:
Пользователь Алиса может просматривать форум, где другой пользователь, Мэллори, разместил сообщение.
Пусть Мэллори создал тег <img>, в котором в качестве источника картинки указан URL, при переходе по которому выполняется действие на уязвимом сайте банка.
Если банк Алисы хранит ее информацию об аутентификации в куки и если куки еще не истекли, при попытке загрузить картинку браузер Алисы отправит запрос на перевод денег на счет Мэллори и подтвердит аутентификацию при помощи куки.
Таким образом, транзакция будет успешно завершена, хотя ее подтверждение произойдет без ведома Алисы.
3)Sql inject - Это выполнение произвольного запроса SQL, например через форму ввода, или через специальную подготовленную ссылку.
Проверяется кстати очень легко, достаточно в форму ввода, или в GET/POST запрос вставить управляющий символ «'», если параметры запроса например в mysql_query; передаются не экранированные, или не как параметры, то будет исполнение кода.
В случае передачи «'» будет ошибка SQL, а это значить что мы можем исполнить SQL.)
И выкачать базу например.)
4)Php inject – Это исполнение произвольного PHP кода, при вставке специального кода в форму ввода, или при формировании GET/POST запроса.
Часто такие уязвимости делают специально, на памяти есть уязвимость в плагинах от Esthetic для XenForo, где автор специально встроил бекдор и можно-было исполнять произвольный код на сайте, вот полный разбор (Не реклама): https://ru-sfera.org/threads/lomaem-xenforo-cherez-addony-ot-esthetic.2438/
В качестве примера, вот еще хитрая атака: https://ru-sfera.org/resources/vzlom-pri-pomoschi-roskomnadzora.39/
5)Сбор статистики о ваших пользователях - Это не совсем уязвимость, но может-быть для кого-то неприятно.
Это всевозможные снифферы, которые посетители могут вставить в качестве картинки, например картинка загружается со сервера сниффера, вы заходите на форум и если картинка автоматически не скачивается на сервер форума, то сниффер уже будет иметь статистику о айпи адресах пользователей, браузерах и т.д.
Также можно парсить посетителей, по полю "Пользователи онлайн", например запостить ссылку на форуме, при переходе парсить поле "Посетители онлайн" и если пользователь там есть, мы также получим айпи, браузера и время прочтения, а также никнейм.)))
Ну это не уязвимость, защитится можно например отключением видимости активности в настройках приватности. Для защиты от сниферов, закачивать автоматически картинки на форум.)
Практическая часть:
Да знаю, тут не любят теорию, но что-то без теории у меня не получается.))
Практическая часть будет состоять из двух частей:
1.Как найти представленные выше уязвимости.
2.Разбор примера поиска.
Часть первая.Поиск уязвимостей и закладок в плагинах/скриптах.
1.Ну во первых я просматриваю код, так мельком и смотрю как передаются данные в функции запроса к базе данных.
Они должны передаваться как параметры, либо экранироваться, вот функции экранирования:
Далее нужно проанализировать, на сколько безопасен этот вызов в контексте программы.
3.Если в коде присутствуют какие-то зашифрованные части, сто раз нужно подумать, устанавливать-ли.)
4.Проверяю отправляет-ли скрипт какие-то данные на сторонние ресурсы, это можно узнать при помощи поиска «http» и «https».
5.Проверяю формы ввода, вставляю следующий код:
«'»
<script>alert("I am XSS")</script>
Если сайт уязвим, то будет ошибка сервера SQL или сообщение «I am XSS» соответственно…)
6.Также не нужно забывать подписываться на обновления скриптов, часто авторы фиксят свои продукты, а хакеры не ищут уязвимости, а используют уже известные…)
В принципе для первичного анализа этого хватит и какими-то супер знаниями в области не нужно обладать, очень рекомендую не ленится, а анализировать так скрипты.
Еще не забывайте читать отзывы о скриптах и авторах, также может защитить от уязвимостей.)))
Часть вторая. XSS в чате от Siropu для XenForo.
Тут ничего сложно, у себя на сайте решил проверить, все-бы хорошо, но в чате есть опция обновления статуса посетителя.
Смысл этой опции, что посетители могут создать в чате свой статус, например «Я занят» или «Всем Привет», который будет отображаться на главной странице, как оказалось если в это поле вставить <script>alert("I am XSS")</script> то получится такая шляпа:
Т.к. чат на моем сайте на главной странице, то получили еще и активную XSS, которая будет выполняться при переходе на главную страницу.)))
Защита, это отключить обновление статусов в чате, но я его вообще снес.
Т.к. береженного кастет бережет !)))
Также при такой проверки получил еще и ошибку SQL, при форме ввода в плагине поиска по перепискам от Andy, но не разбирал уязвимость-ли это, некогда, а просто снес также плагин.)))
Выводы:
Да это первичный осмотр, но уже он может помочь найти уязвимости, причем сделать такой осмотр может любой администратор и даже не разработчик кода.
Да только этого осмотра может и нехватить, но тем не менее очень рекомендую проверять так свои скрипты.)))
В данной статье расскажу, как можно проверить плагины к сайтам, таким как Wordpress, XenForo и т.д.
Данная статья родилась, когда я решил проверить установленные плагины для XenForo на уязвимости XSS и SQL inject и к удивлению нашел парочку недочетов.
Тем не менее статья не будет написана к конкретному движку, а советы как проверить, будут универсальными и будет приведен пример XSS уязвимости в чате XenForo.
Итак изначально небольшая теория, какие могут-быть атаки на ваш сайт и зачем:
1)XSS (англ. Cross Site Scripting — «межсайтовый скриптинг») — Смысл данной атаки в исполнении кода на стороне жертвы.
Атака заключается в исполнении кода на стороне браузера, смысл такой, если сайт позволяет вставлять сообщения пользователям, например регистрация пользователей, вставка сообщений и т.д.
То если эти сообщения не будут фильтроваться, можно подготовить специальный HTML – код, который выполнится на стороне жертвы, вплоть до замены сайта нужным вам содержимым (дефейс)…)))
XSS я разделяю на два типа:
1 - Пассивные XSS – Для атаки нужно подготовить ссылку и дать эту ссылку жертве, после перехода по ней, будет исполнение нужного кода.
Пример: http://example.com/search.php?q=<script>alert("I am XSS")</script>
Если сайт уязвим, то при переходе, будет такое окошко:
2 - Активный XSS (Пример этой уязвимости мы разберем, на боевом моем сайте):
Ну для активной XSS не нужно готовить никакой ссылки, вредоносный код будет исполняться на стороне пользователя автоматически, достаточно лишь подготовить специальный HTML код и вставить его в форму ввода, помню по молодости дефейсили так сайты и форумы.)))
Очень опасная уязвимость, так-как таким образом можно полностью подменить сайт, или его части, например форму ввода кредитных карт, помню именно так кардеры воруют данные кредиток у уязвимых магазинах.)
2) CSRF (англ. Сross Site Request Forgery — «Межсайтовая подделка запроса», также известен как XSRF).
Смысл заключается в том, что бы от имени пользователя совершать какие-либо действия...
Например, если здесь на форуме будет найдена XSS, можно через эту XSS от имени жертвы создавать темы, переписки и т.д.
Ещё пример:
Пользователь Алиса может просматривать форум, где другой пользователь, Мэллори, разместил сообщение.
Код:
Мэллори: Привет, Алиса! Посмотри, какой милый котик: <img src="http://bank.example.com/withdraw?account=Alice&amount=1000000&for=Mallory">Пусть Мэллори создал тег <img>, в котором в качестве источника картинки указан URL, при переходе по которому выполняется действие на уязвимом сайте банка.
Если банк Алисы хранит ее информацию об аутентификации в куки и если куки еще не истекли, при попытке загрузить картинку браузер Алисы отправит запрос на перевод денег на счет Мэллори и подтвердит аутентификацию при помощи куки.
Таким образом, транзакция будет успешно завершена, хотя ее подтверждение произойдет без ведома Алисы.
3)Sql inject - Это выполнение произвольного запроса SQL, например через форму ввода, или через специальную подготовленную ссылку.
Проверяется кстати очень легко, достаточно в форму ввода, или в GET/POST запрос вставить управляющий символ «'», если параметры запроса например в mysql_query; передаются не экранированные, или не как параметры, то будет исполнение кода.
В случае передачи «'» будет ошибка SQL, а это значить что мы можем исполнить SQL.)
И выкачать базу например.)
4)Php inject – Это исполнение произвольного PHP кода, при вставке специального кода в форму ввода, или при формировании GET/POST запроса.
Часто такие уязвимости делают специально, на памяти есть уязвимость в плагинах от Esthetic для XenForo, где автор специально встроил бекдор и можно-было исполнять произвольный код на сайте, вот полный разбор (Не реклама): https://ru-sfera.org/threads/lomaem-xenforo-cherez-addony-ot-esthetic.2438/
В качестве примера, вот еще хитрая атака: https://ru-sfera.org/resources/vzlom-pri-pomoschi-roskomnadzora.39/
5)Сбор статистики о ваших пользователях - Это не совсем уязвимость, но может-быть для кого-то неприятно.
Это всевозможные снифферы, которые посетители могут вставить в качестве картинки, например картинка загружается со сервера сниффера, вы заходите на форум и если картинка автоматически не скачивается на сервер форума, то сниффер уже будет иметь статистику о айпи адресах пользователей, браузерах и т.д.
Также можно парсить посетителей, по полю "Пользователи онлайн", например запостить ссылку на форуме, при переходе парсить поле "Посетители онлайн" и если пользователь там есть, мы также получим айпи, браузера и время прочтения, а также никнейм.)))
Ну это не уязвимость, защитится можно например отключением видимости активности в настройках приватности. Для защиты от сниферов, закачивать автоматически картинки на форум.)
Практическая часть:
Да знаю, тут не любят теорию, но что-то без теории у меня не получается.))
Практическая часть будет состоять из двух частей:
1.Как найти представленные выше уязвимости.
2.Разбор примера поиска.
Часть первая.Поиск уязвимостей и закладок в плагинах/скриптах.
1.Ну во первых я просматриваю код, так мельком и смотрю как передаются данные в функции запроса к базе данных.
Они должны передаваться как параметры, либо экранироваться, вот функции экранирования:
- mysql_escape_string — экранирует строку для использования в mysql_query;
- addslashes — экранирует спецсимволы в строке;
- htmlspecialchars — преобразует специальные символы в HTML сущности;
- mysql_real_escape_string — экранирует специальные символы в unescaped_string;
- intval — функция приведения типа.
Код:
eval;
assert;
preg_replace;
create_function;
include;
include_once;
require;
require_once
ob_start
array_diff_uassoc
array_diff_ukey
array_filter
array_intersect_uassoc
array_intersect_ukey
array_map
array_reduce
array_udiff_assoc
array_udiff_uassoc
array_udiff
array_uintersect_assoc
array_uintersect_uassoc
array_uintersect
array_walk_recursive
array_walk
assert_options
uasort
uksort
usort
preg_replace_callback
spl_autoload_register
iterator_apply
call_user_func
call_user_func_array
register_shutdown_function
register_tick_function
set_error_handler
set_exception_handler
session_set_save_handler
sqlite_create_aggregate
sqlite_create_functionДалее нужно проанализировать, на сколько безопасен этот вызов в контексте программы.
3.Если в коде присутствуют какие-то зашифрованные части, сто раз нужно подумать, устанавливать-ли.)
4.Проверяю отправляет-ли скрипт какие-то данные на сторонние ресурсы, это можно узнать при помощи поиска «http» и «https».
5.Проверяю формы ввода, вставляю следующий код:
«'»
<script>alert("I am XSS")</script>
Если сайт уязвим, то будет ошибка сервера SQL или сообщение «I am XSS» соответственно…)
6.Также не нужно забывать подписываться на обновления скриптов, часто авторы фиксят свои продукты, а хакеры не ищут уязвимости, а используют уже известные…)
В принципе для первичного анализа этого хватит и какими-то супер знаниями в области не нужно обладать, очень рекомендую не ленится, а анализировать так скрипты.
Еще не забывайте читать отзывы о скриптах и авторах, также может защитить от уязвимостей.)))
Часть вторая. XSS в чате от Siropu для XenForo.
Тут ничего сложно, у себя на сайте решил проверить, все-бы хорошо, но в чате есть опция обновления статуса посетителя.
Смысл этой опции, что посетители могут создать в чате свой статус, например «Я занят» или «Всем Привет», который будет отображаться на главной странице, как оказалось если в это поле вставить <script>alert("I am XSS")</script> то получится такая шляпа:
Т.к. чат на моем сайте на главной странице, то получили еще и активную XSS, которая будет выполняться при переходе на главную страницу.)))
Защита, это отключить обновление статусов в чате, но я его вообще снес.
Т.к. береженного кастет бережет !)))
Также при такой проверки получил еще и ошибку SQL, при форме ввода в плагине поиска по перепискам от Andy, но не разбирал уязвимость-ли это, некогда, а просто снес также плагин.)))
Выводы:
Да это первичный осмотр, но уже он может помочь найти уязвимости, причем сделать такой осмотр может любой администратор и даже не разработчик кода.
Да только этого осмотра может и нехватить, но тем не менее очень рекомендую проверять так свои скрипты.)))
Последнее редактирование:
ах ты старый.
