Дебаг, баг или фича?

Тема в разделе "Мегафлуд", создана пользователем Горбушка, 9 июл 2013.

  1. Горбушка

    Горбушка Ищу её...

    Регистр.:
    2 май 2008
    Сообщения:
    3.035
    Симпатии:
    2.034
    Собственно, ни для кого не секрет, что я разрабатываю собственную 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-инъекцию и кучу других приятных вещей :D

    Ну а во вторых, чтобы Вы не повторяли моих ошибок. Помните, что уязвимости в 90% случаев бывают именно там, где их не ждёшь. К примеру, Joomla имеет систему показа имён шаблонов - /?tp=1. WordPress имеет плагин дебага. Уверен, что и Вы когда-либо писали дебаги к своим скриптам.

    Так вот - защищайте их! Проверяйте, тестируйте, делайте доступными только по специальной куке (к примеру в админке включаете дебаг - вам прописалась кука - выходите с сайта, кука осталась - дебаг работает), либо по паролю, либо ещё как-то.

    P.s. К счастью, дебаг был установлен только на локальном зеркале сайта, поэтому реальной угрозы не было. Но всё равно были перелопачены логи за последний месяц по дебагу - к счастью, обращения были только от меня и Твоя. В целях профилактики на всех сайтах (даже не на CMS Aima) были сменены ключи защиты, пароли администраторов и пароли к БД.

    Вот так вот, ребята...
     
    latteo и Шумадан нравится это.
  2. stealthdebuger

    stealthdebuger Механик

    Administrator
    Регистр.:
    25 авг 2008
    Сообщения:
    624
    Симпатии:
    1.379
    поржал, спасибо :D
     
    latteo, Горбушка и Шумадан нравится это.
  3. BIZON

    BIZON Перезагрузка...

    Moderator
    • Супермодератор
    Регистр.:
    31 окт 2006
    Сообщения:
    562
    Симпатии:
    1.527
    я понял, что я ни хрена не понял, но в любом случае молодец :ay::D
     
    Горбушка и Шумадан нравится это.
  4. Шумадан

    Шумадан Хабарра!!11

    Регистр.:
    6 фев 2008
    Сообщения:
    1.722
    Симпатии:
    2.097
    больше хардкора примеров :p всем в топике лаффки и симпки :friends:
     
    Горбушка нравится это.
  5. Горбушка

    Горбушка Ищу её...

    Регистр.:
    2 май 2008
    Сообщения:
    3.035
    Симпатии:
    2.034
    Пример?
    gorbushka.name/index.php?debag=1&debagf=index.php&name=evel($db->q("DROP TABLE `user`"))
    И нет у меня таблицы с юзерами :D

    P.s. сейчас уже отрабатывает корректно, посылая на *** и на index.html :p
     
    Шумадан нравится это.
  6. o_nix

    o_nix

    Регистр.:
    7 ноя 2007
    Сообщения:
    1.073
    Симпатии:
    1.037
    Горбушка
    всё дело в изначально не правильном подходе
    не нужно устараивать себе лишний геморой, не нужно связываться с костылями ))
    изначально отделяй мух от котлет :D

    дебаг в принципе не должен быть частью системы, он вообще от неё должен быть максимально отделён
    это инструментарий исключительно для разработчика, а не для админа и пользователей

    в идеале если уж ты параноик после того как всё будет настроено и отлажено просто закомментить инклуд дебага через файлменеджер + переименовать директорию + отключить вывод ерроров и нотисов.
    считаю дурным тоном оставлять возможность включения дебага через админку сайта

    p.s. evel бесит )))
     
    Шумадан нравится это.
  7. Горбушка

    Горбушка Ищу её...

    Регистр.:
    2 май 2008
    Сообщения:
    3.035
    Симпатии:
    2.034
    o_nix, естественно eval... Опечатка...

    Что касается дебага - использовался именно потому, что CMS на стадии разработки. Конечно, после релиза он не нужен и должен быть удалён. Да и использовался он только на закрытом зеркале, на работающих сайтах его не было.

    Я написал это не с целью написать, вот Вы лохи, могли меня ломануть ещё вчера, а с целью предостеречь и научить на моих ошибках. Ведь это мы с тобой понимаем, что отладочная информация не должна быть на работающем сайте вообще, как и правка исходного кода. Всё это должно делаться только на локальных зеркалах, а потом переноситься уже протестированным. А есть люди, кто оставляет и отладочную информацию, и код правит на рабочем сайте, и дебаги не выключает/удаляет.

    P.s. в выключении через админку дебага не вижу ничего плохого. Пошла большая нагрузка - включил, сразу видно откуда ноги растут и какие страницы/модули жрут ресурсы. Другие дело, он не должен быть доступен рядовому пользователю нигде и ни при каких условиях.
     
  8. o_nix

    o_nix

    Регистр.:
    7 ноя 2007
    Сообщения:
    1.073
    Симпатии:
    1.037
    включение через админку это зло

    получили любым методом твои логин пасс - просто и тупо сбрутили например
    зашли в админку
    включили дебаг
    правильно залили шелл
    и усё )) ты под колпаком
    и потом на лечение и выявление придётся убить хз сколько времени

    не часто так бывает что отладочная система === той на которой будет в дальнейшем всё работать

    проблема палева ошибок в момент заливки на рабочий хост и отлова багов легко решается выводом не в браузер, а в локальные текстовые log файлы

    так и вёрстка отладочной инфой не косячится и в log выводится любая нужная инфа, даже непечатная кракозябра - любого объёма.