Регистрация, логин, сеанс и публикация мер безопасности

Это будет первый раз, когда я задаю вопрос кому-либо в отношении веб-разработки. Причина, по которой я решил задать этот вопрос, несмотря на многие подобные вопросы, заданные ранее другими, объясняется тем, что ответы, полученные другими в прошлом, приходили в большом количестве и субъективности, поэтому я смутился и сомневался в том, как подойти к нему.

Я понимаю, что есть разные способы приблизиться к этому, поэтому мой вопрос может вызвать некоторое обсуждение, но я бы хотел, чтобы все помнили специфику моего вопроса, если возникнет какая-либо дискуссия: я не прошу, безопасный подход, но является ли мой подход безопасным вообще или нет; Я нацелен на уровень безопасности популярных форумов, а не крупных веб-сайтов компании, таких как Amazon или Paypal, где происходят денежные транзакции.

Что я использую:

  • PHP 5.5 для password_hash
  • PDO с подготовленными заявлениями

ПОСТАНОВКА НА УЧЕТ

Все входы очищаются следующим образом:

  • отделка
  • stripslashes
  • htmlspecialchars

и они должны пройти через preg_match.

Пользователь должен выбрать имя учетной записи и псевдоним. Имя учетной записи используется для входа в систему, тогда как псевдоним используется для общения с другими участниками форума. Эти два имени не могут быть идентичными друг другу, и они не могут уже существовать в базе данных.

Пользователю задают случайный вопрос, чтобы проверить, является ли он человеком или нет.

АВТОРИЗОВАТЬСЯ

Все входы очищаются следующим образом:

  • отделка
  • stripslashes
  • htmlspecialchars

и они должны пройти через preg_match.

IP-адрес может пытаться войти в систему только один раз в минуту, в общей сложности 3 раза в час, прежде чем пользователю придется ждать 24 часа, чтобы попытаться снова войти в систему.

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

При успешном входе в систему вызывается функция, которая создает случайную строку длиной 32 символа, используя символы в диапазоне от «0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ $ -_.» . Затем эта функция будет зациклировать эту строку на все пользовательские строки в базе данных, пока она больше не сможет найти идентичную строку, затем передать строку и поместить ее в имя учетной записи (под SID1), прежде чем одна и та же функция будет вызвана снова, а другая Строка длиной 32 символа помещается (под SID2).

Всякий раз, когда пользователь входит в систему, создается новый набор строк.

СЕССИЯ

$ _SESSION (session_start) не используется. $ _COOKIE (для «помни меня»). Поэтому я извиняюсь, если я использую неправильную терминологию, ссылаясь на нее как на сеанс или как на SID.

Две 32-символьные длинные строки, которые были помещены в базу данных, объединены и помещены в файл cookie под тем же именем. Эта длинная строка длиной 64 символа с этого момента является единственной мерой идентификации пользователя. Всякий раз, когда пользователю требуется разрешение на выполнение чего-либо, например, просмотр конкретного форума или редактирование его настроек учетной записи, эти два 32 символьных уникальных идентификатора (взорваться) используются для вызова базы данных и возврата ранга пользователя. Другими словами, идентификатор пользователя и имя учетной записи никогда не используются для вызова базы данных, но только уникальные идентификаторы в cookie пользователя. Прежде чем эти строки используются для идентификации пользователя, однако, он должен пройти через preg_match, на всякий случай, если есть какой-то непредвиденный способ вмешательства со входом из файла cookie (я не знаю, есть или нет, и именно поэтому Я решил принять меры предосторожности).

Файл cookie будет уничтожен через 4 недели, если пользователь не установит «запомнить меня» при входе в систему.

Всякий раз, когда пользователь выходит из системы, cookie уничтожается, устанавливая его на -1 год.

POSTING

Пользователям разрешено размещать любой символ UTF-8, который они хотят, и этот вход должен проходить только через htmlentities до того, как он будет сохранен в базе данных. Передача скриптов не работает таким образом. Они могут писать <script>alert('hello');<script> и он появится таким образом в сообщении, но сценарий не будет запущен. Но если я попытаюсь очистить вывод, вместо ввода, сценарий будет работать. Хотя, возможно, я не знаю всех способов передачи сценариев. Итак, просветите меня, если вы можете думать о любом, или, может быть, мне просто нужно будет найти трудный путь.

Я сделал так, чтобы, если пользователь пишет URL-адрес в своем сообщении, URL-адрес автоматически помещается в «href». Аналогично, изображения помещаются в «img», а видеоролики YouTube помещаются в «iframe». Следующий шаг – разрешить только одно изображение и одно видео на YouTube, но я думаю, что мне нужно будет выяснить, как работает кеширование, потому что время отклика моего сайта сократилось с 0,25 секунды до более 3 секунд, как только сообщения содержали внешние изображения /видео. Мне, вероятно, придется проверять внешние изображения, действительно ли они являются изображениями или нет, чтобы избежать враждебного кода, скрытого в изображении, но я пока не уверен, как это работает; возможно, лучший способ узнать, является ли URL-адрес изображением или нет, – проверить, является ли это образ, поэтому мне, вероятно, придется переписать его все.

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

Пожалуйста, дайте мне знать, если я что-то пропустил.