Защита веб-приложений на Perl

DJ-Andrey-sXe Защита веб-приложений на Perl

40 правил

Вторая версия статьи (включает 18 пунктов из первой версии), обновлена: 5 июня 2012.

Оригинал статьи: http://dj-andrey.ru/articles/perl-web-application-security

Сборник практических правил и советов с примерами и разъяснениями. Главным образом речь идет о языке Perl и сервере Apache, но многое из сказанного справедливо для других подобных средств разработки.

Приведённые примеры кода не претендуют на универсальность и законченность, однако, они все проверены и работают на свежих версиях Perl. Почти все пункты уже применялись в реальных скриптах, и я чуть ли не каждую неделю с удовольствием читаю отчеты об успешно отраженных нападениях на сервера.

1.

Не стройте свою защиту только лишь на средствах HTML. Таких как input типа hidden, задание параметров вроде readonly, disabled, maxlength и т.д. Всё это легко обходится построением запроса самостоятельно.

Есть несколько инструментов для Firefox. Например, Firebug http://www.getfirebug.com/, Tamper Data http://tamperdata.mozdev.org/, Hack Bar https://addons.mozilla.org/firefox/addon/3899. Посмотрите на них и больше никогда не доверяйте только лишь одному HTML.

В Firebug, например, скрытые элементы редактируются на ура. Аттрибуты maxlength, disabled, readonly снимаются очень просто. HTML-код, сгенерированный на JavaScript просматривается полноценно, а изменения отражаются немедленно.

Кстати, Firebug в первую очередь – прекрасное средство для отладки.

Все верно выставленные параметры и JavaScript-обработчики (не в качестве защиты) нужны для нормального пользователя, чтобы он понял, сколько он может вводить, где нельзя нажать и т.п. А ненормальный пользователь всё равно построит запрос руками. Собственно, остальная часть статьи во многих местах рассказывает вам, как защититься от построенного самостоятельно поддельного запроса.

2.

Не доверяйте тому, что пришло от пользователя в Cookies. Только ленивый взломщик не станет пробовать их поменять (например, в Opera http://www.opera.com/browser/, до куки можно добраться в 3 клика). Представьте, что там вполне могут оказаться кавычки, апострофы, вообще любая текстовая каша, длинная строка (которая обязательно не влезет в поле базы), огромное число, 0, отрицательное число, или просто пустота. Всегда приравнивайте опасность, исходящую от подделки Cookies к опасности от подделки параметров GET, POST и прочих HTTP-запросов.

3.

В первую очередь надо написать проверку на стороне сервера, а уже только потом на клиенте. В случае нехватки времени, клиентскую проверку можно отложить до следующей версии, но вас уже не сломают. Не надейтесь на OnSubmit, OnKeyPress и прочий JavaScript. Он отключается. Отладка не просто доступна, она кое-где даже удобна. JavaScript – только как средство защиты от ошибок нормальных пользователей и чтобы не мучить сервер обработкой заведомо неверно заполненных форм.

4.

Не важно, насколько крут ваш любимый обфускатор http://ru.wikipedia.org/wiki/Обфускация, JavaScript вам от исследования не оградить. Загляните сюда http://www.howtocreate.co.uk/tutorials/jsexamples/JSTidy.html и перестаньте надеяться на защиту обфускатором. Если вы считаете, что цепочка кодирований и шифрований спасет вас, то я напомню вам, что рано или поздно код должен быть выполнен браузером в нормальном виде, и когда-нибудь таковым он все-таки попадает в eval (параметр eval – строка интерпретируется и выполняется как код JavaScript). Я ради прикола иногда не отказываю себе в удовольствии распотрошить очередной вирус на JS, так вот даже их создатели ничего не могут поделать с сокрытием алгоритма.

5.

Если форма отправляется, к примеру, методом POST, сервер должен отказаться принимать любой другой метод. Исключением из правил может стать лишь скачивание файла: там нужен как GET, так и HEAD.

Как вам перспектива массовой накрутки счетчика злоумышленником, либо добавление записей флудером при помощи метода HEAD? Копеечный трафик, а какой эффект!

6.