рискованные символы для блокировки в формах asp.net?

Question

Я собираюсь запустить сайт авторизации форм, который будет включать формы, которые могут использовать как международные, так и американские пользователи, чтобы обновлять информацию своего профиля и отправлять запросы на информацию о продуктах (но без реальной электронной торговли). Я использую элементы проверки asp.net для ввода текста, и я довольно тщательно отфильтровал их для символов с помощью обнаружения регулярных выражений. Получив некоторый отпор от маркетинга, чтобы открыть это (много), поэтому я искал несколько советов о том, какие символы имеют наивысший приоритет для фильтрации страницы формы asp.net с позиции безопасности?

Спасибо за любые советы по этому поводу!

Answer 1

Когда вы говорите, что отправляете запросы на информацию о продуктах, я представляю поле с произвольным текстом, где пользователь может вводить все, что он хочет, верно? В этом случае вы не должны ничего фильтровать. Если он будет таким же напряженным, как я думаю, то, держу пари, этот самый ответ будет считаться плохим, что расстроит ваших пользователей. =) * * Тысяча одна

Недавно мы столкнулись с чем-то похожим, когда сотрудники службы безопасности хотели заблокировать целую кучу специальных символов. Оказывается, пользователи не могут использовать точки, апострофы, дефисы или косые черты в своих комментариях - woops! Также оказывается, что это не требовалось, потому что используемый ORM уже генерировал параметризованные операторы SQL, которые можно было безопасно выполнять в БД.

Если вы используете современный ORM или вручную выполняете параметризованные запросы к вашей базе данных, я бы не стал сильно беспокоиться о применении ограничений специальных символов для полей профиля.

Answer 2

Главное, чтобы убедиться, что вы не подвергаете себя SQL-инъекции. Самый простой (?) Способ справиться с этим в .net / MSSQL - убедиться, что вы используете хранимые процедуры или параметризованные запросы.

В зависимости от того, как содержимое, вводимое в эти формы, будет впоследствии отображаться, вы также можете проверить наличие уязвимостей на стороне клиента (например, людей, пытающихся ввести разметку iframe или javascript)