DJ-Andrey-sXe
Защита веб-приложений на Perl
40 правил
Вторая версия статьи (включает 18 пунктов из первой версии), обновлена: 5 июня 2012.
Оригинал статьи: http://dj-andrey.ru/articles/perl-web-application-security
Сборник практических правил и советов с примерами и разъяснениями. Главным образом речь идет о языке Perl и сервере Apache, но многое из сказанного справедливо для других подобных средств разработки.
Приведённые примеры кода не претендуют на универсальность и законченность, однако, они все проверены и работают на свежих версиях Perl. Почти все пункты уже применялись в реальных скриптах, и я чуть ли не каждую неделю с удовольствием читаю отчеты об успешно отраженных нападениях на сервера.
Не стройте свою защиту только лишь на средствах 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-обработчики (не в качестве защиты) нужны для нормального пользователя, чтобы он понял, сколько он может вводить, где нельзя нажать и т.п. А ненормальный пользователь всё равно построит запрос руками. Собственно, остальная часть статьи во многих местах рассказывает вам, как защититься от построенного самостоятельно поддельного запроса.
Не доверяйте тому, что пришло от пользователя в Cookies. Только ленивый взломщик не станет пробовать их поменять (например, в Opera http://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, выполняться на сервере или сохраняться для последующей передачи клиенту.
Данные от пользователя без фильтрации нельзя использовать в регулярных выражениях.
Пример неправильного кода:
Чтобы избежать обработки ”регулярных“ метасимволов, нужно писать переменные между \Q и \E:
Есть функция под названием quotemeta. Она подготавливает строку символов к безопасному помещению в регулярное выражение. Все не алфавитно-цифровые символы будут проэкранированы обратным слэшэм.
Не позволяйте действиям, создающим уникальные по определению данные, выполняться более одного раза. Это собьет с толку нормального пользователя и позволит злоумышленнику намусорить в базе. Всегда останавливайте обработку и сообщайте пользователю, почему система отказала в выполнении действия. Вот несколько примеров:
• Не может быть двух пользователей с совпадающими логинами, email или одинаковыми паспортными данными.
• Не должно появиться двух пунктов меню или в списке на одном уровне с полностью совпадающим названием.
• Не может существовать двух предметов под названием «Физическая география» с разными id.
И так далее. Можно привести массу примеров, главное – вспоминать об этом принципе при проектировании всего нового. В борьбе с неуникальностью помогут уникальное индексирование или ручная проверка select-ом перед вставкой.
Последнее время стало модно проверять данные с помощью Ajax прямо во время заполнения форм.
Делая так, вы не только заблаговременно предупредите пользователя об ошибке, но и избавите его от лишних действий – ему не придётся возвращаться на предыдущую страницу кнопкой Back, Backspace или JavaScript-ссылкой, рискуя потерять введённые данные, потому как не все браузеры одинаково бережно относятся к данным форм на предыдущих страницах, либо сами избавляетесь от лишней работы по генерации в ответ на POST этой же формы, но с помеченными ошибками.
Создайте альтернативные функции считывания данных cookie или param. Пользуйтесь только ими там, где наличие параметра обязательно и тип данных не меняется. Они должны работать как обычные, но если только формат данных не соответствуют ожидаемому, программа прекратит выполнение обработки запроса. Для начала любому серьёзному проекту точно понадобятся функции валидации дат, чисел, диапазонов чисел и нахождения переданной строки в заданном списке строк или поле таблицы базы данных.
Примеры таких функций:
И тому подобные.
Примеры использования:
Но этого недостаточно. Всегда дотошно представляйте себе ситуацию, обдумайте типичные ошибки и опечатки. В сообщении об ошибке покажите пример правильно заполненного поля. Наконец, включите логику.
Вот пара простых примеров:
• Если вы спрашиваете у пользователя, когда он создал свой сайт, не позволяйте ему указать 1634 год (тогда интернета вроде не было) или дату в будущем.
• Или вы спрашиваете возраст пользователя. Не нужно позволять ему указывать 300 лет. К сожалению, столько не живут. Правда в этом конкретном случае лучше быть оптимистом, да и деваться некуда – нужно ставить с запасом. Зато представьте себе, какая радость, когда какой-то пользователь пожалуется на ограничение в 150 лет :)