Горбушка
Ищу её...
- Регистрация
- 2 Май 2008
- Сообщения
- 3.444
- Реакции
- 2.524
- Автор темы
- #1
Собственно, ни для кого не секрет, что я разрабатываю собственную CMS с нуля. Никаких фреймворков и т.д. В общем, хардкор.
В общем, каждый из нас понимает, что для отработки некорректного/корректного поведения скрипта используется дополнительный код - дебаг. Видов полно - от инклуда файла или кода внутри кода, до сторонних библиотек, которые наоборот подключают файлы CMS.
Т.к. я выбрал хардкор, писать дебаг решил сам. Он представляет из себя как инклуд файла, так и код внутри кода. Но суть не в этом.
Одна из функций дебага - предоставлять все данные, которые поступают в скрипт (как есть), их же после обработки, и их же после отработки файла. Так же выводится список SQL-запросов, подключённых шаблонов ну и прочая дребедень.
Так вот, при написании дебага я как-то мао уделил ему времени и внимания, а зря. Как выяснилось, именно он представляет опасность для сайта.
Сегодня сидели, анализировали вместе с Для просмотра ссылки Войдиили Зарегистрируйся код, дорабатывали некоторые функции API и решили проверить криптозащиту и защиту от XSS. Всё отработало как надо, весьма предсказуемо. После чего решили включить дебаг.
Собственно сам дебаг включался банальным ?debag=1&gebugfile=file (т.е. передаём, что дебаг включён и имя файла, дебаг которого меня интересует). Когда в очередной раз был вызван дебаг, неожиданно не сработала защита от XSS и на вторичном сервере оказались мои куки. Как это получилось?
Естественно первое подозрение пало на защиту от XSS. Данный файл был перечитан от и до, оттестирован, перечитан ещё раз - защита работала 100%. Решили оттестировать сам скрипт CMS - всё отработало штатно, уязвимостей нет. Перекопали шаблоны, сам шаблонизатор, перерыли всё, связанное с БД. Даже отправку почты проверили - всё чисто.
Проблема оказалась именно в дебаге.
1) Дебаг не контролировал кто его включает. Т.е. включить его мог любой пользователь.
2) Дебаг не защищался от XSS, т.е. выводил данные на экран как есть.
3) Дебаг имел прямой доступ к файлам CMS, БД, почте и т.д.
4) Дебаг выводил значение системных переменных (которые содержат весьма опасные данные - ключи криптозащиты, ключи API, ключи декодирования БД и т.д.)
5) Дебаг имел право на evel()
6) В выводимых SQL-запросах и ответах на них выводились пароли, ключи сессий и прочая информация
На выходе дебаг был полностью удалён. Новый писать не планирую.
Зачем я делюсь этой проблемой?
Ну конечно, чтобы Вы поржали... Я, параноик по безопасности, делающий проверку каждой строки, своими руками написал шелл, XSS, SQL-инъекцию и кучу других приятных вещей
Ну а во вторых, чтобы Вы не повторяли моих ошибок. Помните, что уязвимости в 90% случаев бывают именно там, где их не ждёшь. К примеру, Joomla имеет систему показа имён шаблонов - /?tp=1. WordPress имеет плагин дебага. Уверен, что и Вы когда-либо писали дебаги к своим скриптам.
Так вот - защищайте их! Проверяйте, тестируйте, делайте доступными только по специальной куке (к примеру в админке включаете дебаг - вам прописалась кука - выходите с сайта, кука осталась - дебаг работает), либо по паролю, либо ещё как-то.
P.s. К счастью, дебаг был установлен только на локальном зеркале сайта, поэтому реальной угрозы не было. Но всё равно были перелопачены логи за последний месяц по дебагу - к счастью, обращения были только от меня и Для просмотра ссылки Войдиили Зарегистрируйся. В целях профилактики на всех сайтах (даже не на CMS Aima) были сменены ключи защиты, пароли администраторов и пароли к БД.
Вот так вот, ребята...
В общем, каждый из нас понимает, что для отработки некорректного/корректного поведения скрипта используется дополнительный код - дебаг. Видов полно - от инклуда файла или кода внутри кода, до сторонних библиотек, которые наоборот подключают файлы CMS.
Т.к. я выбрал хардкор, писать дебаг решил сам. Он представляет из себя как инклуд файла, так и код внутри кода. Но суть не в этом.
Одна из функций дебага - предоставлять все данные, которые поступают в скрипт (как есть), их же после обработки, и их же после отработки файла. Так же выводится список SQL-запросов, подключённых шаблонов ну и прочая дребедень.
Так вот, при написании дебага я как-то мао уделил ему времени и внимания, а зря. Как выяснилось, именно он представляет опасность для сайта.
Сегодня сидели, анализировали вместе с Для просмотра ссылки Войди
Собственно сам дебаг включался банальным ?debag=1&gebugfile=file (т.е. передаём, что дебаг включён и имя файла, дебаг которого меня интересует). Когда в очередной раз был вызван дебаг, неожиданно не сработала защита от XSS и на вторичном сервере оказались мои куки. Как это получилось?
Естественно первое подозрение пало на защиту от XSS. Данный файл был перечитан от и до, оттестирован, перечитан ещё раз - защита работала 100%. Решили оттестировать сам скрипт CMS - всё отработало штатно, уязвимостей нет. Перекопали шаблоны, сам шаблонизатор, перерыли всё, связанное с БД. Даже отправку почты проверили - всё чисто.
Проблема оказалась именно в дебаге.
1) Дебаг не контролировал кто его включает. Т.е. включить его мог любой пользователь.
2) Дебаг не защищался от XSS, т.е. выводил данные на экран как есть.
3) Дебаг имел прямой доступ к файлам CMS, БД, почте и т.д.
4) Дебаг выводил значение системных переменных (которые содержат весьма опасные данные - ключи криптозащиты, ключи API, ключи декодирования БД и т.д.)
5) Дебаг имел право на evel()
6) В выводимых SQL-запросах и ответах на них выводились пароли, ключи сессий и прочая информация
На выходе дебаг был полностью удалён. Новый писать не планирую.
Зачем я делюсь этой проблемой?
Ну конечно, чтобы Вы поржали... Я, параноик по безопасности, делающий проверку каждой строки, своими руками написал шелл, XSS, SQL-инъекцию и кучу других приятных вещей
Ну а во вторых, чтобы Вы не повторяли моих ошибок. Помните, что уязвимости в 90% случаев бывают именно там, где их не ждёшь. К примеру, Joomla имеет систему показа имён шаблонов - /?tp=1. WordPress имеет плагин дебага. Уверен, что и Вы когда-либо писали дебаги к своим скриптам.
Так вот - защищайте их! Проверяйте, тестируйте, делайте доступными только по специальной куке (к примеру в админке включаете дебаг - вам прописалась кука - выходите с сайта, кука осталась - дебаг работает), либо по паролю, либо ещё как-то.
P.s. К счастью, дебаг был установлен только на локальном зеркале сайта, поэтому реальной угрозы не было. Но всё равно были перелопачены логи за последний месяц по дебагу - к счастью, обращения были только от меня и Для просмотра ссылки Войди
Вот так вот, ребята...