Безопасность CMS сайта на примере сайта Связного
Поговорим о безопасности сайтов. А точнее о тех проколах разработчиков, которые предоставляют посетителям лишнюю информацию, которая может оказать помощь для взлома сайта.
Лазил недавно по сайту Связного, наткнулся на несуществующую страницу, в которой мне их движок сайта вывалил весь бектрейс вызовов своих процедур. Прямо с путями в файловой системе! Офигенный прокол с точки зрения безопасности. Немного поэкспериментировал с GET-параметром action и выяснил что на какие параметры он выдает такой же дамп, а на какие-то - нет.
Скриншот выдаваемого листинга (кликни чтобы посмортеть в оригинальном размере)
Если в качестве параметра ввести любую абракадабру, то движок выдает пустую страницу (хотя по логике должна быть страница с 404 ошибкой - page not found). Например, вот такая страница c параметром action=DABlank8 содержит в себе информацию о компании. Если поиграться с последней цифрой в параметре, изменить ее с 8 на 6, к примеру, то получим бектрейс вызовов движка сайта. А если вообще уберем последнюю цифру, то получим пустую страницу.
Еще немного полазив по сайту, замечаем, что параметр action имеет свою структуру. Начало этого параметра, а именно, подстрока-префикс DA присутсвует во многих страницах. Что это означает - не совсем понятно. За ним идет как бы корень раздела или группы страниц - Blank для обычных контентовых страниц, News - для лент новостей, Product - для продуктов и т.д. Что означает последний номер - не совсем понятно, ясно что идентификатор какой-то, но он не всегда срабатывает. Чтобы понять надо дальше лазить и разбираться.
И все это сопровождается полными трейсами вызовов функций и полными путями от корня к соответствующим файлам. А это дает неплохой набор начальных данных для обратного инжинеринга (читай - для хакинга) CMS сайта. Если движок у них не самописный, а какой-то коммерческий, то по именам файлов и функций его можно попытаться опознать. А далее идет проверка на известные дырки в этом движке в предыдущих версиях (вдруг они не обновились?). Плюс уже известны все нужные пути в файловой системе, если у них где-то на сайте “гуляют” пути к файлам в параметрах, то можно попробовать поиграться с этим.
Именно поэтому на серьезных продакшн-сайтах открытых в интернет, всегда выключают выдачу в браузер всех ерроров и warning'ов, потому что это дает потенциональному злоумышленнику лишнюю информацию. А уж выдавать бектрейс вызовов - это уже совсем моветон. Ну, а мелочь вроде пустой белой страницы вместо положенной по правилам хорошего тона страницы с 404 ошибкой - это совсем не так страшно с точки зрения безопасности, но не совсем правильно.
Да, а еще в нормальных движках скрывают GET-параметры. Кстати, при этом часто используют в апаче и nginx'е такой модуль Rewrite. Он умеет преобразовывать по шаблону переданный ему URL требуемой страницы. То есть пути из index.php?action=news&news_id=666 превращаются в /news/666. Еще может оказаться логичней внести сюда дату новости, например, /news/2008/01/11/666. Такой трюк убивает (в хорошем смысле слова) трех полезных зайцев:
- скрывает от пользователя GET-параметры, теперь уже не понятно что - полный путь, а что - параметры, с какими можно играться и пытаться подсунуть им на вход что-то плохое.
- делает структуру сайта похожей на структуру папок, то есть более логичной
- упрощает поисковую оптимизацию сайта, поскольку не все поисковики уважают и не всегда правильно “понимают” страницы с GET-запросами
Ну хватит. Кому надо будет (у кого свободного времени много) - тот дальше нароет.
Кстати, сайт Связному делала некая студия под названием netPro. Будем надеяться до них дойдет эта статья и они все ошибочки подправят.
В любом случае - спасибо за материал для статьи. Статья не претендует на профессиональный анализ безопасности сайта, а лишь знакомит читателя с некими фактами и содержит в себе мысли и вывода автора, отражающие лишь уровень знаний оного.
ЗЫ Спасибо коментаторам - судя по GET параметрам на сайте самой студии стоит такой же движок. Самописка.
