Разработка безопасной стратегии входа в систему и аутентификации PHP
Я разрабатываю вход в систему и систему аутентификации для нового сайта PHP и читал на различных нападениях и уязвимостях. Однако это немного сбивает с толку, таким образом, я хочу проверить, что мой подход имеет смысл.
Я планирую то, чтобы хранить следующие данные:
На сессии: идентификатор пользователя, хешированный + посоливший
HTTP_USER_AGENTВ cookie и в базе данных: случайный маркер, хешированный + посоливший идентификатор
На каждой странице я планирую выполнение следующего:
Если сессия существует, аутентифицируйте использование это. Проверьте что
HTTP_USER_AGENTсоответствует тому на сохраненной сессии.Если никакая сессия не существует, используйте cookie для аутентификации. Проверьте, что маркер и идентификатор в cookie соответствуют тем, которые в базе данных.
Если cookie недопустим или не существует, просит, чтобы пользователь вошел в систему.
Есть ли какие-либо очевидные дефекты в этом? Пока я установил тайм-аут в cookie, я должен быть довольно в безопасности, правильно? Есть ли что-нибудь, что я пропускаю?
Заранее большое спасибо.
7 ответов
Несколько случайных мыслей:
- Что, если я украду cookie одного из ваших пользователей (используя XSS-атаку путем внедрения некоторого JS-кода на ваш сайт)? Тогда я упаду в случае 2 и, таким образом, смогу войти в систему. ИМХО, если вы хотите действительно безопасную аутентификацию, не используйте куки-файлы типа «запомнить меня» для хранения учетных данных пользователя.
- Если вы сохраняете учетные данные в файле cookie, пожалуйста, не храните пароль в открытом виде.
- Проверка
HTTP_USER_AGENT- хороший первый шаг для предотвращения перехвата сеанса, но, может быть, вы могли бы объединить его с IP-адресом? Гораздо труднее находиться на одном хосте, чем ваша цель, чем просто использовать один и тот же браузер.
Но в любом случае спасибо за то, что вы нашли время подумать о хорошей схеме аутентификации. Многие разработчики PHP этого не делают.
РЕДАКТИРОВАТЬ: для протокола, позвольте мне прояснить здесь один момент: в этом обсуждении используются два файла cookie. Один автоматически устанавливается PHP для распространения идентификатора сеанса (иногда мы видим, что веб-сайты помещают его в URL-адрес, например www.example.com/page.php?sessionId = [...]), а второй создается вами для хранения учетных данных пользователя и аутентификации его при потере сеанса. Атака XSS применяется к обоим, то есть злоумышленник может либо украсть cookie сеанса и захватить сеанс (который имеет ограниченный срок жизни), либо украсть файл cookie с учетными данными и аутентифицироваться позже.
и второй, созданный вами, чтобы хранить учетные данные пользователя и аутентифицировать его при потере сеанса. Атака XSS применяется к обоим, то есть злоумышленник может либо украсть cookie сеанса и захватить сеанс (который имеет ограниченный срок жизни), либо украсть файл cookie с учетными данными и аутентифицироваться позже. и второй, созданный вами, чтобы хранить учетные данные пользователя и аутентифицировать его при потере сеанса. Атака XSS применяется к обоим, то есть злоумышленник может либо украсть cookie сеанса и захватить сеанс (который имеет ограниченный срок жизни), либо украсть файл cookie с учетными данными и аутентифицироваться позже.не должно быть. сеанс php хранится на вашем сервере , а не у пользователя. php просто оставляет cookie сеанса, указывающий на него. если вы не пользуетесь виртуальным хостингом, сеанс даже не нужно хэшировать.
joe
Зависит от того, насколько вы хотите быть в безопасности.
Межсайтовые уязвимости: Допустим, другой сайт указывает браузеру отправить форму на ваш сайт, которая делает что-то вроде публикации спама (или того хуже), если этот пользователь уже вошел в систему, отправка формы будет работать. Вам нужно будет проверить референт и сгенерированный скрытый идентификатор формы для каждой формы, чтобы полностью защитить от этого.
Во-вторых: если у вас высокий или средний трафик, идентификаторы сеанса могут повторяться или даже угадываться, я бы проверил по второй руке сгенерированный идентификатор, который хранится в файлах cookie пользователя.
Схема кажется излишне сложной в нескольких отношениях, поскольку дополнительная сложность не дает вам ничего в функциональности или безопасности.
- Любые данные, отправляемые браузером (например, файлы cookie, User-agent) можно подделать. Проверка User-agent поможет только тогда, когда злоумышленник находится за тем же NAT, что и поддельный пользователь, и злоумышленник использует другой браузер, но не думает изменить User-agent.
- Сеансы сохраняют идентификатор сеанса на стороне клиента с использованием файлов cookie или параметра запроса URL. Если вы хотите продлить срок службы сеанса, используйте
session_set_cookie_params, чтобы сохранить cookie сеанса дольше.
Пользовательский агент не является секретными данными, поэтому хеширование не требуется.
атаки, которые не будут обнаружены с помощью cookie сеанса + проверка удаленного IP-адреса:
- злоумышленник находится за тем же NAT, что и пользователь.
- Атаки слепого внедрения, при которых злоумышленник подделывает IP-адрес пользователя. Несмотря на то, что они предназначены только для записи, они все же могут нанести некоторый ущерб.
- атаки, использующие собственный браузер пользователя, такие как подделка межсайтовых запросов (CSRF).
2) могут быть предотвращено, если вы можете разработать способ отправки запроса в браузер пользователя, на который необходимо ответить до завершения запроса, но это сложно, если вы не написали клиент. С AJAX это можно сделать. 3) (как отмечает MindStalker) можно предотвратить, проверив заголовок Referer, который работает, потому что атаки CSRF не имеют возможности воздействовать на произвольные заголовки, а XMLHttpRequest не должен позволять устанавливать заголовок Referer (согласно стандарт W3C , хотя реализации могут быть несовместимы). С помощью iframe можно обойти проверку Referer. Кроме того, заголовок Referer может быть заблокирован на стороне клиента.
Сохранение cookie в базе данных - УЖАСНАЯ идея. Это означает, что если злоумышленник имел уязвимость SQL-инъекции, он мог немедленно получить доступ без взлома хешированного пароля.
Говоря о том, что вам нужно использовать sha256 для паролей, если вы используете md5 (), вы технически уязвимы для атак, и вам может быть выдан номер CVE.
НИКОГДА не создавайте свои собственные идентификаторы сеанса, используйте session_start () и суперглобальный $ _SESSION.
Это безопасный способ перенаправления людей. Если вы не умираете после header (), остальная часть php-кода ВСЕ ЕЩЕ ВЫПОЛНЯЕТСЯ, даже если она не отображается в обычных браузерах (хакеры все еще видят это :)
header("location: index.php");
die();
Если честно, если безопасность вас смущает, не пишите безопасность системы. Люди написали более 1000 систем входа в систему только для PHP, и большинство из них уязвимы. http://code.google.com/p/michael-the-messenger/downloads/list
Большинство сайтов просто используют сеанс PHP; Данные сеанса ($ _Session) в в на ваш ваш сервер . Все, что отправлено в браузер, это идентификатор сеанса. Обязательно восстановите сеанс каждый запрос ( session_regenerate_id ). Вам не нужно отправлять два печенья или что-нибудь.
Это менее уязвимо для ухватки сеанса, поскольку каждый запрос является новым идентификатором, поэтому старый, перехваченный злоумышленником бесполезным.
Лучшее решение, очевидно, будет использовать SSL на протяжении всего сеанса.
ИМХО Также важно, чтобы информация сеанса меняется после входа в успех. Чтобы сохранить информацию о сеансе в базе данных не сохраняется из-за инъекций.