Какую проверку должна включать форма? Лучшие практики

Question

Я пытаюсь составить контрольный список вещей, которые необходимо учитывать при создании форм.Я знаю, что мне нужно отфильтровать входной контент.Я уже фильтрую ошибочные html и сценарии, экранирую mysql и ограничиваюсь типами данных (номера телефонов состоят из 10 и более цифр с обучающими дополнительными цифрами, электронная почта должна быть электронной почтой, строки не могут содержать html или код и т. Д.) И словомограничения на количество символов (имена не более 4 слов, разделенных пробелами и т. д.).Но что еще мне следует делать и как их можно использовать?

Эта проверка будет проходить на сервере, но я ищу лучшие практики для разных платформ.Данные будут поступать с использованием POST, поэтому мне не нужно слишком беспокоиться о том, чтобы перебирать URL.Также обрабатывается представление формы, с подсказками, js-маскированием ввода, и почти все на стороне клиента находится на месте.

Answer 1

Валидация до самого простого термина: принимает только то, что вы хотите .

Например, если ваше телефонное поле должно содержать только цифры (без определенного формата телефонных номеров) и не более 20 номеров, вы можете проверить его по регулярному выражению, чтобы убедиться, что это то, что вы хотите принять, т.е. ([0-9]{7,20})

Другой пример, Twitter. Он принимает только имя пользователя длиной до 15 символов, буквенно-цифровой и состоящий из подчеркивания. Таким образом, регулярное выражение проверки может что-то быть: ([a-zA-Z0-9]{1})([a-zA-Z0-9\_]{0,14})

Проверка формы также может быть в форме проверки безопасности. Это может быть горшок с медом, срок действия формы и т. Д.

Форма Медовый горшок : предотвращение автоматического / спам-отправления вашей формы
Срок действия формы: проверьте время загрузки формы и время отправки формы. Если оно слишком короткое, форма может быть отправлена ​​ботом. Если это займет слишком много времени, данные могут быть устаревшими и устаревшими.
CAPTCHA : еще один уровень защиты от ботов / валидация только для человека.

Answer 2

Вы можете проверить OWASP http://www.owasp.org/index.php/OWASP:About. Особенно, если вы планируете работать с кредитными картами.

Answer 3

Вещи, которые имеют смысл в контексте, это хорошо, вещи, которые не имеют смысла, это плохо.

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

Остерегайтесь чрезмерной проверки.<не обязательно плохо, есть разные причины, по которым люди будут использовать <,> и особенно &.

Аналогично, в то время как Роберт ');DROP TABLE Учащиеся; - не тот, кого вы хотите записать в своей школе, если ваше предотвращение означает, что О'Брайен, О'Тирни, О'Донован и О'Фланаган не могут зарегистрироваться,раз О'Доннелу отказали, он подумает, что это антиирландский расизм и подаст в суд на вас!(Более реалистично, я знаю людей здесь, в Ирландии, которые ищут конкурента, когда сценарий предотвращения SQL-инъекций блокирует или искажает их фамилию - хотя чаще они просто находят еще один сайт, который не предотвращение инъекций, так как любой из них в некотором роде потерпит неудачу).

Валидация , в отличие от проверки безопасности, заключается в том, чтобы убедиться, что что-то правдоподобно отражает реальность.На самом деле личные имена имеют «в них», а названия компаний и городов всегда имеют «&» в них, и «валидация» блокирует превращение действительных данных в недействительные.На самом деле номера кредитных карт имеют длину 16 цифр (некоторые дебетовые карты - 19 цифр) и проходят лунную проверку, адреса электронной почты имеют информационную часть пользователя, @ и имя хоста с записью MX.Имена людей никогда не бывают нулевыми.Это проверка.Отклонять (а не бежать) можно только в том случае, если оно действительно недействительно.

Answer 4

Комментатор С. Лотт прав: отступление должно автоматически выполняться каркасом. Если вы не работаете с явным фреймворком, то, по крайней мере, функции утилит, которые вы используете для доступа к базе данных и отображения данных на странице, должны быть скрыты для SQL и HTML соответственно. Если вам нужно побеспокоиться о том, чтобы уйти от кода проверки, рано или поздно вы совершите ошибку, и какой-нибудь 12-летний сценарист заменит содержимое вашего веб-сайта на порнуху.

Answer 5

У всегда отличного журнала Smashing есть несколько замечательных советов: http://www.smashingmagazine.com/2009/07/07/web-form-validation-best-practices-and-tutorials/

Но если бы я мог предложить свой собственный:

1. Сделайте его безопасным, но пригодным для использования.
2. Используйте проверку на стороне клиента вместе с проверкой на стороне сервера
3. Если вы отправляете сообщения с ошибками, убедитесь, что информация пользователей по-прежнему заполнена в форме
4. Ограничьте размер поля в формах HTML.

Конечно, все это предполагает, что вы используете веб-формы.