Защита веб-приложений на Perl - страница 7
Рассмотрите варианты, как можно организовать отладочный режим:
• Приложение отлаживается на сервере, недоступном снаружи (самый безопасный вариант).
• Недокументированная настройка – переключение в отладочный режим.
• Доступ к отладочной информации имеют пользователи либо по IP, либо только определённые учетные записи.
Итак, что же я понимаю под отладочной информацией.
• Время выполнения всего скрипта или его части (функции или куска кода).
• Количество SQL-запросов, их текст, время их выполнения.
• Нагрузка на процессор скриптом, базой, расход памяти.
• Сообщения об ошибках и предупреждения интерпретатора в браузер, а не в лог.
• Дампы выполнения вспомогательных команд, вызывавшихся во время исполнения скрипта.
• Трассировка стека.
• Дамп переменных окружения, HTTP-запроса.
• На страницы вместе с информацией из базы выводятся внутренние идентификаторы (например, id пользователей, сессий, новостей, статей, событий, да, в принципе, любые идентификаторы данных, которые порой очень облегчают разбор происходящего без лишних подглядываний в базу).
Пара слов о реализации. Я предпочитаю заводить переменную вроде $DEBUG. В разработке она = 1, иначе это релиз. И теперь можно писать либо так:
Так можно подсчитывать количество запросов к БД, замерять длительность их выполнения, сообщать о повторяющийся запросах.
Либо так:
Например, в отладке в списках можно к тексту элемента дописывать его ID в базе. Или добиться, чтобы в отладке проект не выдавал предупреждений на JavaScript при выходе или удалении информации, так как вам это скоро надоест, а данные тестовые – их не жалко в случае чего (да и бэкапы вы всё равно делаете, не так ли?).
Internal Server Error – знакомо? Пусть в релизе так и остаётся. Так как уж очень интересные вещи порой Perl может поведать взломщику. Максимум, что тут можно сделать, так это назначить в apache
>ErrorDocument 500 /500.html
и написать там по-русски об ошибке с учетом того, какое у вас приложение. А технические детали вы в логах почитаете.
Вроде красиво, вроде безопасно… но так неудобно отлаживать – приходится все время читать хвост error_log. Есть способы выводить многие ошибки в браузер. Почему не все? Дело в том, что ошибка может возникнуть ещё до выполнению приведенных ниже трюков, и они просто не успеют отработать.
Итак, направить ошибки в браузер в режиме отладки можно либо по-старому:
либо с использованием более легкого, чем CGI.pm модуля Котерова:
Необходимо четко следить, чтобы доступ к базе производился только приложением со всеми должными проверками и фильтрациями. Надо отфаерволлить базу от любых подключений, кроме локального (если база и приложение на одном сервере), либо кроме локального и только того, на котором находится приложение. Это избавит вас от необходимости проверять данные при чтении из базы (потому что они попали в нее гарантированно только от вашего приложения и проверены/профильтрованы им), кроме того, эффективнее проверять один раз при добавлении/изменении, а не каждый раз при чтении.
Доступ к приложению всем либо конкретным пользователям можно дать только с определённых IP или подсетей.
Можно устроить блокировку доступа к веб-приложению по выходным, в отпуске либо по определённым дням, в течении которых доступ к приложению совершенно точно никому не нужен. Если приложение полностью не доступно, то и сломать его не получится. Это лучше, чем оно могло бы быть поломано всегда. Правило применимо только к специфическим приложениям, которые крутятся, скажем, на предприятиях, работающих с понедельника по пятницу, а в выходные не работающих. Причём для исключения человеческого фактора (типа, забыли погасить сервер) можно назначить в кроне задание выключиться в пятницу вечером, а в BIOS Setup – включиться в понедельник утром. Ведь ни для кого не секрет, что лучше всего сервер защищён только выключенным состоянием :) Естественно, идея выключенного сервера годна лишь для такого сервера, где кроме защищаемого веб-приложения ничего не крутится (в первую очередь в голову приходит пример с официальным сайтом, который должен работать круглосуточно. Если у вас именно так, то укладывать веб-приложение вместе с сайтом нельзя и надо решать иначе, например временным пятничным выпиливанием VirtualHost приложения из конфига apache и его же понедельничным возвращением назад).