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

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

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

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

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

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

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

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

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

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

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

Любой param или cookie (в терминах модуля CGI.pm) НУЖНО проверить или отфильтровать. Исключение – это данные, которые не будут фрагментом SQL-запроса, регулярного выражения, вываливаться в HTML, выполняться на сервере или сохраняться для последующей передачи клиенту.