Какие атаки можно направить на страницу регистрации

Question

У меня есть страница регистрации на сайте, и я пытаюсь составить список того, что мне нужно сделать, чтобы защитить ее. Если вы знаете о нападении, пожалуйста, назовите его и кратко опишите его, желательно с кратким описанием его решения. Все полезные ответы / комментарии получают голосование.

Вот что я имею в виду на данный момент: (и добавление того, что предлагают другие. Фу, добавление других входных данных оказалось большой работой, но, пожалуйста, продолжайте их добавлять, я продолжу добавлять здесь)

• SQL-инъекции: с даты ввода пользователя. Решение: подготовленные заявления.

• [AviD] "Хранимые процедуры также предоставляют дополнительные преимущества (выше подготовленных операторов), такие как возможность наименьших привилегий для БД"

  • Хороший вопрос, пожалуйста, объясните. Я думал, что хранимые процедуры были такими же, как подготовленные заявления. То, что я имею в виду в этих утверждениях, было связыванием переменных. Они разные?

• Не хешировать пароль перед входом в БД. Решение: хэш-пароли.

• [AviD] 're Хэширование, паролю требуется соль (случайное значение, добавленное к паролю перед хэшированием), чтобы предотвратить атаки Rainbow Table и атаки по тому же паролю. "
• "используемая соль должна быть разной для каждого пользователя."
  • Хорошо, у меня есть вопрос по этому поводу: я знаю, что соль должна быть случайной, но также и уникальной. Как нам создать уникальную деталь для противодействия атаке с использованием одного и того же пароля? Я читал об этом, но пока не получил четкого ответа.
• [Inshallah] "если вы используете длинную соль, например 16 символов для SHA-256 ($ 5 $), вам не нужно проверять ее уникальность"

• [Inshallah] "На самом деле, я думаю, что на самом деле не имеет значения, есть ли какие-то конфликты. Соль предназначена только для предотвращения поиска в таблице, поэтому даже соль с двумя символами будет (маленькой) выиграть, даже если есть конфликты. Мы не говорим о криптографическом одноразовом слове, который здесь не должен повторяться. Но я не криптоаналитик "

  • Хороший вопрос, но есть ли у кого отказ от ответственности по этому вопросу?

• Дос атакует ?! (Полагаю, это относится и к регистрационным формам)

• [Pascal Thivent] «Использовать HTTP при отправке важных данных, таких как пароль». «для атак« человек посередине »при условии использования адекватных наборов шифров»

  • Что за «адекватные наборы шифров» упоминаются здесь?

• [Koosha] «Используйте HTTP или шифруйте пароли перед отправкой с MD5 и Javascript на стороне клиента».

  • Я не согласен с MD5 и не люблю шифрование на стороне клиента, для меня это не имеет никакого смысла. но другие входные данные приветствуются.

• [Дэн Аткинсон] Исключить определенные имена пользователей, чтобы предотвратить столкновение с существующими страницами с таким же именем (полный ответ и объяснение см. В оригинальном сообщении)

• [Koosha] "ограничить допустимые символы для имени пользователя. Например, алфавит и цифры, тире (-) и точка (.)"
  • Пожалуйста, объясните, почему?
• [Stu42] «Используйте капчу, чтобы бот не мог автоматически создавать несколько учетных записей»
• [AviD] «Существуют лучшие решения, чем капча, но для малоценных сайтов это может быть достаточно хорошим».
  • @ AviD, приведите пример?

• [rasputin] "использовать проверку по электронной почте"

• [Эндрю и эпохальный волк] xss атаки

  • Хотя я не согласен с Эндрю и epochwolf просто фильтровать <и> или конвертировать <в & tl; и> к>. Большинство мнений предлагают такую ​​библиотеку, как HTMLpurifier. Любой вклад по этому поводу?

Answer 1

Используйте HTTPS, то есть комбинацию HTTP и SSL, чтобы обеспечить шифрование и надежную идентификацию сервера при отправке конфиденциальных данных, таких как пароль. Основная идея HTTPS заключается в создании безопасного канала через незащищенную сеть. Это обеспечивает разумную защиту от перехватчиков и атак типа «злоумышленник в середине» при условии, что используются адекватные комплекты шифров и сертификат сервера проверен и надежен.

Answer 2

Используйте recaptcha или asirra , чтобы избежать автоматической отправки. Это должно остановить ботов и скриптовых детишек.

Чтобы запретить многим людям отправлять спам (с помощью механического турка или чего-либо подобного), регистрируйте каждую попытку в memcached и, как только вы достигнете максимального количества отправлений с одного и того же IP-адреса в данный период времени, заблокируйте этот IP-адрес для несколько минут (или часов, дней, что угодно ...).

Answer 3

Вы должны использовать подтверждение по электронной почте

и дополнение к ответу Коши: если вы разрешите имена пользователей, включая такие символы, "# &? /" и создадите пользовательские страницы, подобные этому site.com/user?me&you/, это может стать серьезной проблемой в браузерах Пожалуйста, подумайте об этом в адресной строке браузера.

Answer 4

Если маршруты на вашем веб-сайте заданы особым образом (т. Е. По имени пользователя, а не по его идентификатору), то наличие имени пользователя, такого как «admin», может вызвать проблемы. Вероятно, у вас должен быть список исключенных имен пользователей.

В прошлом это вызывало проблемы с MySpace, и люди, имеющие такие имена пользователей, как логин, а затем украшали свою страницу фишинговой формой.

Edit:

Как уже упоминалось в комментариях AviD и Питер Боутон , это также способ ввести пользователей в заблуждение. Допустим, у пользователя есть имя пользователя «admin». Затем, на своей странице информации о пользователях (при условии, что каждый из них получает тот, который доступен всем, например, SO), у них есть некоторая ссылка в разделе о них, которая выглядит как

Для получения дополнительной информации посетите наш разработчик блог на mysite.cn/loginpage

Кто-то, возможно, видит в своем URL «mysite», но на самом деле не смотрит на TLD, которым будет Китай (извините, Китай!), А не на домен .com, на котором размещен ваш сайт. Таким образом, они нажимают, предполагая, что все в порядке (они все-таки пришли со страницы администратора), и этот сайт выглядит так же, как ваш, но имеет страницу входа. Таким образом, вы повторно вводите свои данные, но ничего не происходит. Или перенаправляет вас в другое место.

Это часто тактика банковских мошенников, которые хотят нацеливаться на клиентов, предлагая им перейти на свой веб-сайт для «повторного ввода банковского пароля».

Это еще одна форма безопасности, известная как Социальная инженерия .

Answer 5

Используйте капчу, чтобы бот не мог автоматически создать несколько учетных записей

Answer 6

Полагаю, вы должны использовать соль при хешировании паролей.

Answer 7

1. Использовать HTTPS
2. Использовать капчу.
3. Ограничить допустимые символы для имени пользователя на стороне сервера. например, алфавит и цифры, тире (-) и точка (.).

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

Ограничение символов. Это простой способ защитить программное обеспечение от инъекций (SQL / XSS).

Answer 8

Фильтруйте данные пользователя, удаляя '<', '>' - просто HTML-теги. Если кто-то может просмотреть профиль пользователя, то возможны XSS-атаки через данные.