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

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

7.

Данные от пользователя без фильтрации нельзя использовать в регулярных выражениях.

Пример неправильного кода:

Чтобы избежать обработки ”регулярных“ метасимволов, нужно писать переменные между \Q и \E:

Есть функция под названием quotemeta. Она подготавливает строку символов к безопасному помещению в регулярное выражение. Все не алфавитно-цифровые символы будут проэкранированы обратным слэшэм.

8.

Не позволяйте действиям, создающим уникальные по определению данные, выполняться более одного раза. Это собьет с толку нормального пользователя и позволит злоумышленнику намусорить в базе. Всегда останавливайте обработку и сообщайте пользователю, почему система отказала в выполнении действия. Вот несколько примеров:

• Не может быть двух пользователей с совпадающими логинами, email или одинаковыми паспортными данными.

• Не должно появиться двух пунктов меню или в списке на одном уровне с полностью совпадающим названием.

• Не может существовать двух предметов под названием «Физическая география» с разными id.

И так далее. Можно привести массу примеров, главное – вспоминать об этом принципе при проектировании всего нового. В борьбе с неуникальностью помогут уникальное индексирование или ручная проверка select-ом перед вставкой.

Последнее время стало модно проверять данные с помощью Ajax прямо во время заполнения форм.

Делая так, вы не только заблаговременно предупредите пользователя об ошибке, но и избавите его от лишних действий – ему не придётся возвращаться на предыдущую страницу кнопкой Back, Backspace или JavaScript-ссылкой, рискуя потерять введённые данные, потому как не все браузеры одинаково бережно относятся к данным форм на предыдущих страницах, либо сами избавляетесь от лишней работы по генерации в ответ на POST этой же формы, но с помеченными ошибками.

9.

Создайте альтернативные функции считывания данных cookie или param. Пользуйтесь только ими там, где наличие параметра обязательно и тип данных не меняется. Они должны работать как обычные, но если только формат данных не соответствуют ожидаемому, программа прекратит выполнение обработки запроса. Для начала любому серьёзному проекту точно понадобятся функции валидации дат, чисел, диапазонов чисел и нахождения переданной строки в заданном списке строк или поле таблицы базы данных.

Примеры таких функций:

И тому подобные.

Примеры использования:

Но этого недостаточно. Всегда дотошно представляйте себе ситуацию, обдумайте типичные ошибки и опечатки. В сообщении об ошибке покажите пример правильно заполненного поля. Наконец, включите логику.

Вот пара простых примеров:

• Если вы спрашиваете у пользователя, когда он создал свой сайт, не позволяйте ему указать 1634 год (тогда интернета вроде не было) или дату в будущем.

• Или вы спрашиваете возраст пользователя. Не нужно позволять ему указывать 300 лет. К сожалению, столько не живут. Правда в этом конкретном случае лучше быть оптимистом, да и деваться некуда – нужно ставить с запасом. Зато представьте себе, какая радость, когда какой-то пользователь пожалуется на ограничение в 150 лет :)

10.

В формах ввода данных в базу проставляйте параметр maxlength для текстовых полей, равный размеру поля в базе. Не ограничивайтесь этим, всегда обрезайте текст и на сервере.

HTML:

Perl:

Можно сделать обёртку:

11.

Используйте метод quote интерфейса DBI, если текст, введенный пользователем, нужно использовать в SQL-запросах. Либо биндинг параметров, что обязательно для BLOB-полей и полезно для простого текста. Этим вы будете защищены от SQL-Injection атак.

Примеры с биндингом:

Пример с quote:

Смешивать quote и биндинг нельзя!

12.

XSS может быть не менее опасен, чем дыра другого класса. Только представьте себе, что вы залогинились и просматриваете HTML, в который злоумышленник встроил зловредный JavaScript, переправляющий вас на URL, который для вашей системы, к примеру, является командой грохнуть информацию или отправить ее на сторону.

Пример. Представьте себе, что вашу форму заполнили вот так:

А если там будет что-то вроде этого. Как вам?

Защищайтесь даже от не вполне очевидных опасностей, скажем, от поля User-Agent запроса (который часто светится в логах или статистике, что, как правило, дело админское, а там XSS еще более опасен).

13.

Позволяйте вставлять HTML только там, где это действительно необходимо. Лучше дайте пользователю редактор вроде FCKeditor http://www.fckeditor.net/, TinyMCE http://tinymce.moxiecode.com/, HTMLArea http://www.dynarch.com/projects/htmlarea/, NicEdit http://nicedit.com/ и тому подобные. В остальных случаях режьте все лишнее. Отправной точкой может служить такая резалка:

Обратите внимание на готовые модули для чистки HTML: