Одной из основных проблем для любого программиста при разработке веб-приложения является проверка корректности вводимых пользователем данных. Практически все программы в сети на 80-90% (будь то сайт-визитка, или сложный корпоративный портал) функционируют на основе параметров, получаемых от пользователя. В данном утверждении не имеются ввиду, только данные, непосредственно вводимые посетителями в html-формы. Хотя этот момент особенный и требует значительного внимания, он не единственен и, при создании проектов, разработчику следует также анализировать get-параметры строки адреса, значения, получаемые сайтом из cookies пользователя и данные, являющиеся на формах скрытыми.

Программисту всегда и везде следует руководствоваться одним четким правилом «Не доверяй пользовательскому вводу данных». Это значит, что любой параметр, получаемый скриптом от пользователя, должен быть всегда проверяем на корректность. Особое внимание следует уделять значениям переменных, отвечающих за выборку информации из базы данных. Об этом во всевозможной литературе говорится очень часто, однако, количество сайтов, взламываемых SQL-инъекциями от этого не уменьшается.

Итак, в данной статье, рассмотрим html-формы и все проблемы, связанные с фильтрацией вводимых в них данных. Уровней фильтрации может быть два: клиентский, с использованием JavaScript и серверный, с использованием серверного языка программирования, как правило – это php или perl. У каждого из них есть свои достоинства и недостатки:

1. JavaScript. Так как данные фильтруются на клиентской стороне, проверка происходит очень быстро и не загружает сервер. Однако тут есть существенный недостаток – абсолютная незащищенность от намеренного взлома. Обходится такая проверка очень просто – сохранением html-страницы на локальный ПК и правкой или полным удалением в ней JavaScript-кода. После незначительной корректировки параметра «action» у html-формы локальной страницы можно добиться того, что данные будут отправляться тому же скрипту, которому отправляются со страницы, размещенной на сервере, однако в данном случае, уже без фильтрации.

2. Серверный язык программирования. Неоспоримым плюсом подхода является полная защищенность принципов проверки от корректировок со стороны хакера. Минусом – необходимость затрачивать ресурсы сервера на проверку. Некорректные данные могут вводить не только хакеры, гораздо чаще это делают обычные пользователи по причине невнимательности – ввод буквенных символов в поле «телефон» или кириллицы в «адрес электронной почты», некорректное указание даты рождения, например 14-ого месяца – обычная практика. Зачастую бывает, что одна форма может пересылаться между пользователем и сервером несколько раз, переписав корректно одно поле, пользователь делает ошибку в другом, сервер опять проверяет данные и возвращает ему форму на перезаполнение. Когда проект не слишком популярен и заполняется одна форма в день, разработчик может позволить себе затрачивать ресурсы сервера на такие проверки. Однако, когда посетителей много, и форм отправляется по нескольку штук в минуту, дело принимает совсем другой оборот – большое количество ресурсов тратится практически впустую.

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

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