Автоматическая безопасность входа в систему с PHP, как и почему

Question

Я знаю, что этот вопрос задан много раз, но у меня немного другое отношение к нему. Это вопрос из двух частей.

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

Во-вторых, я не понимаю, как хакер использовал информацию, которую они украли, чтобы скомпрометировать систему.

---

Первая часть, вот мой рабочий процесс, какие части уязвимы. Вот несколько вещей, которые могут или не могут быть полезными, я использую PHP 5.6.21. Я буду использовать их новый хэш-API, который использует новейшую технологию хэширования и автоматически солит ее. Я использую архитектуру MVC, поэтому почти все, кроме моего фронтального контроллера и личных активов, находится за пределами корня веб-сервера.

1. журналы член в и выбирает авто Логин CheckBox

2. печенье с хэш-значением, которое соответствует хэш-значения в таблице членов, записывается в их браузере. Файл cookie доступен только из каталога участников на сервере, который находится за пределами корневого каталога. Также устанавливается атрибут httpOnly.

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

4. Если они найдены, войдите в систему. Если файл cookie установлен, но соответствующая запись не найдена, тогда возможно, что cookie был подделан. В этом случае создайте новый автоматический логин входа в базу данных и удалите файл cookie в браузере участников. Затем заставьте их войти в систему вручную. Если они снова выбирают автоматический логин, он возвращается к шагу 1, на этот раз используя новый хеш.

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

---

Вторая часть моего вопроса является более общей. Предположим, что хакер каким-то образом компрометирует автоматический файл cookie для входа и получает код. Что они могут с этим сделать? Как они могут использовать это для компрометации моей системы?

В случае SQL Injection я понимаю, что дамп данных может быть возможен, и хакер может получить представление только для вашей базы данных. В этом случае необходимо иметь хэшированные и соленые пароли! Они могут запускать эти хэши через свои злые машины и, возможно, получить ваши учетные данные.

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

Спасибо за ваше время!

Answer 1

Есть две части к этому:

1. Making, что ваши сеансы являются безопасными. Read this для руководства по безопасности сеанса с примерами конфигурации. Спойлер: HTTPS является обязательным, убедитесь, что вы используете CSPRNG для идентификаторов сеансов, и вы восстанавливаете идентификаторы сеанса во время повышения привилегий (и/или регулярно).
2. Безопасное внедрение маркера аутентификации на основе файлов cookie, которые будут прозрачно повторно аутентифицировать пользователя при доступе к вашему веб-сайту с допустимым файлом cookie, но без активного сеанса. Я ранее писал широко оскорбительно side-channel-resistant persistent user authentication.

Вторая часть интереснее, потому что многие люди останавливаются на «генерации случайного токена, хранящемся в файле cookie, а затем просматривают его в базе данных».

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

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

• Первая часть (называемая селектором) хранится/индексируется в вашей таблице базы данных.
• Вторая часть (называемая верификатором) хранится в открытом тексте в cookie вашего пользователя, но хешируется (например, SHA256) в базе данных.

После получения маркеров, основываясь на селекторе, сравнить хэш верификатора, предоставленный пользователем с сохраненным хэшем, используя hash_equals().

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

Это безопасно только при использовании HTTPS с HSTS, и ваши файлы cookie устанавливаются только на HTTPS! (Это означает, что secure и httpOnly оба устанавливаются в true.)

Вы можете увидеть пример этой системы в действии here и here.

Answer 2

Когда пользователю необходимо вводить имя пользователя и пароль каждый раз, когда он хочет войти в систему, единственной информацией, сохраненной на стороне клиента, является файл cookie, содержащий session id.Теперь это связано с session hijacking, который работает по принципу, что на стороне клиента пользователь полностью контролирует идентификатор сеанса, отправленный на сервер и в незащищенную среду, это передается через HTTP (без какого-либо шифрования) , Если вредоносному пользователю удалось получить идентификатор сеанса другого пользователя, он может «захватить» сеанс пользователя.

Есть способы предотвратить или сорвать захват сеанса. Один из методов - это белый список IP-адреса и/или информации обозревателя в сеансе. Если сеанс конфликтует с «белой» информацией, сеанс был скомпрометирован.

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

На данный момент ваша хэш-строка, независимо от того, насколько силен алгоритм ее генерации, является просто новым «именем пользователя/паролем».

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

Answer 3

Вот идея, чтобы защитить ситуацию от второго вопроса: сохранить хэш в другом месте, кроме базы данных. У нас есть приложение, в котором хранятся токены аутентификации в Memcached - хранилище ключей для хранения на стороне сервера в ОЗУ. https://memcached.org/

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

У Memcached есть дополнительное преимущество, позволяющее установить тайм-аут на то, как долго действует токен, что позволяет вам легко реализовать что-то, что вы выходите через 30 минут.

Answer 4

Предполагая, что весь транспорт безопасен (через HTTPS), единственным надежным вектором для злоумышленника будет кража файла cookie из браузера пользователя либо физически, либо с помощью какого-либо эксплойта браузера.

Некоторые дополнительные шаги в отношении к автоматической авторизации куки могут быть приняты, такие как:

• Занесение IP и блокировки, автоматического логина маркер конкретного IP или диапазона вокруг этого IP, все остальное может быть считается подозрительным, и вы можете закрыть ключ автозапуска
• Хранение пользовательского агента и, если он значительно отличается (например, другой браузер), то это также может быть несанкционированный доступ, а токен автозапуска должен быть отменен

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