Какие нападения могут быть направлены на регистрационной странице
Я думаю, что Вы хотите сделать, это:
<asp:DropDownList ID="DropDownList1" runat="server" AppendDataBoundItems="true">
<asp:ListItem Text="--Select One--" Value="" />
</asp:DropDownList>
Удостоверяются, что 'AppendDataBoundItems' установлен на верный , или иначе Вы очиститесь '-Выбор Один -' элемент списка при привязке данных.
, Если у Вас есть свойство 'AutoPostBack' набора выпадающего списка к верный , необходимо будет также установить свойство 'CausesValidation' на верный , затем используют 'RequiredFieldValidator' для проверки '-Выбор Один -' опция не вызывает обратную передачу.
<asp:RequiredFieldValidator ID="RequiredFieldValidator1" runat="server" ControlToValidate="DropDownList1"></asp:RequiredFieldValidator>
8 ответов
Используйте HTTPS, т. Е. Комбинацию HTTP и SSL для обеспечения шифрования и безопасной идентификации сервера при отправке конфиденциальных данных, таких как пароль. Основная идея HTTPS - создать безопасный канал в незащищенной сети. Это обеспечивает разумную защиту от перехватчиков и атак типа «злоумышленник в середине» при условии, что используются соответствующие комплекты шифров, а сертификат сервера проверен и надежен.
Используйте recaptcha или asirra , чтобы избежать автоматической отправки. Это должно остановить ботов и скрипачей.
Чтобы орды людей не рассылали спам (через механический турк или что-то в этом роде), регистрируйте каждую попытку в memcached, и как только вы достигнете максимального количества отправлений с одного IP-адреса в В заданный период времени заблокируйте этот IP-адрес на несколько минут (или часов, дней и т. д.).
Вам следует использовать подтверждение адреса электронной почты
и дополнение к ответу Коуши: если вы позволите именам пользователей включать такие символы "# &? /" и создать страницы пользователей, такие как site.com/user?me&you/, это может стать серьезной проблемой в браузерах. Пожалуйста, подумайте, что это в адресной строке URL-адресов браузеров.
Думаю, вам следует использовать соль при хешировании паролей.
Используйте Captcha, чтобы бот не мог автоматически создавать несколько учетных записей
Если маршруты на вашем веб-сайте настроены особым образом (т. Е. По имени пользователя, а не по его идентификатору), то наличие имени пользователя, такого как «admin», может вызвать проблемы. Вам, вероятно, следует иметь список исключения возможных имен пользователей.
Это вызывало проблемы в прошлом с MySpace и людьми, имеющими такие имена пользователей, как логин, а затем украшающие свои страницы фишинговой формой.
Изменить:
Как и ранее было упомянуто в комментариях AviD и Питера Боутона , это также способ ввести пользователей в заблуждение. Допустим, у пользователя есть имя пользователя admin. Затем на своей странице с информацией о пользователях (при условии, что каждый из них получает одну, доступную для всех, например, SO), у них есть ссылка в разделе «О нас», которая гласит, например,
Для получения дополнительной информации посетите наш разработчик блог на mysite.cn/loginpage
Кто-то, возможно, видит "mysite" в URL-адресе, но на самом деле не смотрит на TLD, которым будет Китай (извините, Китай!), а не на домен .com, которым является ваш сайт размещено на. Таким образом, они переходят по ссылке, если все в порядке (в конце концов, они пришли со страницы администратора), и этот сайт выглядит идентично вашему, но имеет страницу входа. Таким образом, вы повторно вводите свои данные, но ничего не происходит. Или он перенаправляет вас в другое место.
Часто это тактика банковских мошенников, которые хотят нацеливаться на клиентов, приглашая их перейти на свой веб-сайт, чтобы «повторно ввести банковский пароль».
Это просто еще одна форма тип защиты, известный как « Социальная инженерия ».
Фильтрация удаления данных пользователя '<', '>' - просто теги html. Если кто-то может просматривать профиль пользователя, возможны XSS-атаки через данные.
- Использовать HTTPS
- Использовать Captcha.
- Ограничить допустимые символы для имени пользователя на стороне сервера. например, алфавит и цифры, тире (-) и точка (.).
PS. Шифрование на стороне клиента не является безопасным способом. но если вы не можете использовать HTTP, шифрование на стороне клиента лучше, чем ничего.
Ограничение количества символов, это простой способ защитить ваше программное обеспечение от инъекций (SQL / XSS).