Что разрешить в полях формы HTML?

Question

У меня есть несколько HTML-форм, и я реализую фильтрацию этих полей на стороне сервера (используя Java-сервлеты), и мне было интересно, что мне следует разрешить или, возможно, запретить.Для адресов электронной почты я удаляю все, что соответствует этому:

[^A-Za-z0-9._%-@]

Какие аналогичные правила я могу применить к полям имени, сообщения и номера телефона.

Я предполагаю, что <и> следует экранировать как <и>, что еще я должен заменить?

Вдоль этих строк есть ли какие-либо рекомендации по максимальной длине, допустимой для таких полей?

Answer 1

Вы должны разрешить что-либо для имен. Рассмотрим «О'Мэлли» или «Хадсон-Уокер». Некоторые языки (например, Salish) включают числа, поэтому вы можете иметь «Sqwxwu7mish». Затем есть акцентированные символы: иврит, кириллица, греческий, китайский, корейский и даже музыкант, ранее известный как принц.

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

Номера телефонов также должны быть близки к свободной форме. Североамериканские форматы отличаются от европейских, некоторые люди любят говорить «(555) 555-5555», а другие любят «555-555-5555», некоторые телефонные номера имеют добавочные номера, а некоторые - нет.

Единственная кодировка, о которой вам следует беспокоиться при вводе, это то, что все находится в UTF-8 (включая вашу базу данных). И, когда вы разговариваете с вашей базой данных, не пытайтесь ничего кодировать самостоятельно, используйте механизм цитирования драйвера базы данных и заполнители.

Длина обычно должна быть намного больше, чем вы думаете, что она должна удваивать (по крайней мере) вашу первую догадку на разумном максимуме. Разница в памяти между 20 символами для имени и 100 не будет важной для большинства приложений, поэтому будьте щедрыми.

Вам не нужно беспокоиться о кодировке HTML до вывода, а затем вы должны использовать любые инструменты кодирования HTML и URL, которые поддерживает ваша среда, не пытайтесь создавать свои собственные.

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

Answer 2

Сначала нужно выбрать & до &, затем < до <. Вопреки распространенному мнению, не обязательно , чтобы сбежать > в >. Нет необходимости защищать скобку, которая закрывает тег HTML, если нет способа открыть один.

Ваш запрос о том, должен ли он быть экранирован перед записью в базу данных, или вам следует делать это, когда он каждый раз считывается из базы данных. Делать это на стороне ввода будет быстрее; выполнение этого на стороне вывода будет более безопасным, а также упростит обмен данными с другими приложениями, если вам не нужно всегда unescape что-либо перед отправкой в ​​другое приложение. Я лично заплатил бы цену исполнения и убегал на стороне выхода. Кэширование может помочь.

Остальная часть проверки, которую вы хотите выполнить, зависит от типа данных. Для адреса электронной почты убедитесь, что он имеет @ и хотя бы один . после этого, а затем, если вас волнует, действителен ли он или нет, отправьте адрес тестового электронного письма. Почти невозможно полностью проверить адрес электронной почты намного дальше этого, и даже если адрес синтаксически действителен, это еще не означает, что он может быть доставлен. Аналогично, разрешите почти все в качестве URL-адреса, а затем попытайтесь получить его , чтобы убедиться, что он действителен. Для адреса выставления счета / доставки используйте веб-службу USPS для проверки и получения данных в лучшем формате (для адресов США).

Answer 3

Максимальная длина: я всегда применяю максимальную длину к своим полям на стороне клиента и на стороне сервера. Значения соответствуют максимальным значениям, установленным в базе данных.

Я согласен с экранированием <,> и & gt, & lt.

Я думаю, это хорошая привычка иметь очень хорошую проверку. Если бы я работал с полями имени, сообщения и номера телефона, я бы сделал следующее.

Для каждого текстового поля сделайте так, чтобы текстовое поле вообще не принимало недопустимых значений.
Имя: aA-zZ
Сообщение: 'aA-zZ' '0-9' '.' ',' ';' и т. д.
Номер телефона: '0-9' Не допускайте пробелов, но разрешите '-', вы всегда можете разобрать строку на стороне сервера.