Я делаю сценарий входа, который я хотел бы быть как можно более безопасным. Проблема в том, что безопасность кажется бесконечной битвой. По сути, я ищу предложения и улучшения в своих идеях.
У меня есть логин, основанный исключительно на сеансах. Каждый раз, когда изменяется информация о сеансе, вызывается session_regenerate_id() чтобы избежать очевидных попыток угона.
Когда сеанс не установлен, я проверяю cookie для действительного входа в систему и при успешном обновлении сеанса.
Я пытаюсь защитить файл cookie, добавив значение хэша вместе с частью уникальной информации пользователя (например, имя пользователя или идентификатор). Этот хеш состоит из различной информации, включая имя пользователя / идентификатор, неразрешимый хэш пароля, часть IP-адреса и т. Д. Извлекая имя пользователя / id из файла cookie, я могу сделать новый хэш из действительной информации пользователя и сравнить это с хешем в cookie. Мои надежды здесь состоят в том, чтобы предотвратить подделку куки-файлов и захват файлов cookie (если они также не обманывают IP-адрес).
РЕДАКТИРОВАТЬ Предположим, что сам вход будет выполнен через HTTPS / SSL, поэтому передача (разумно) безопасна.
Я на правильном пути? Что еще можно сделать, чтобы защитить мой логин?
Спасибо за помощь!
Не существует такой вещи, как безопасный файл cookie, если он передается только через SSL. Его можно смягчить при использовании постоянного несеансового файла cookie (например, помните меня), делая именно то, что вы делаете, но не так, как вы думаете об этом.
Вы действительно можете хранить серверные переменные, такие как пользовательский агент, IP-адрес и т. Д. (И даже переменные JavaScript), но они хороши только для проверки того, что постоянные данные cookie соответствуют новому соединению клиента. IP-адрес не является хорошей идеей, кроме случаев, когда вы знаете, что клиент (как и вы) не будет меняться при каждой загрузке страницы (a la AOL).
Современные веб-браузеры и сторонние сервисы, такие как LastPass, могут хранить учетные данные для входа, которые требуют только нажатия клавиши (а иногда и даже не того) для отправки данных в форму входа. Стойкие файлы cookie подходят только тем людям, которые отказываются использовать то, что доступно в противном случае. В конце концов, постоянные, несеансные куки-файлы больше не требуются.
Прекратите то, что вы делаете. Не проверяйте user-agent или IP-адрес. Пользовательский агент является контролируемой пользователем переменной, и проверка этого значения не повышает безопасность этой системы. IP-адрес будет изменяться по законным причинам, например, если пользователь находится за балансировщиком нагрузки или TOR.
Идентификатор сеанса всегда должен быть криптографическим . В php просто вызовите session_start() а затем начните использовать супер-глобальный $_SESSION . PHP заботится обо всем этом для вас. Если вы хотите улучшить обработчик сеанса php, используйте настройки . Включите use_only_cookies , cookie_httponly и cookie_secure . Кроме того, установка entropy_file в /dev/urandom – хорошая идея, если вы находитесь в системе * nix, но если ваши под окнами, то у вас проблемы.
Например, чтобы аутентифицировать пользователя:
//In a header file session_start(); ... if(check_login($_POST['user_name'],$_POST['password'])){ //Primary key of this user $_SESSION['user_id']=get_user_id($_POST['user_name']); $_SESSION['logged_id']=True; }
И чтобы проверить, вошел ли пользователь в систему:
//in a header file session_start() ... if(!$_SESSION['logged_id']){ header("location: login.php"); die();//The script will keep executing unless you die() }
Чтобы улучшить эту систему, прочитайте OWASP A9 и используйте HTTPS на протяжении всего сеанса. Также прочитайте OWASP A5: CSRF, а также «сеанс верховой езды» и OWASP A2: XSS, потому что оба они могут использоваться для компрометации сеанса.
Я использую метод на основе cookie (используя функцию setcookie), но ….
session_start(); ... if(check_login($_POST['user_name'],$_POST['password'])){ //Primary key of this user $_SESSION['user_id']=get_user_id($_POST['user_name']); $_SESSION['logged_id']=True; }
… эти методы wrooooong !!!!
Я взламываю свой сайт с помощью атаки, основанной на файле cookie.
Поэтому, если кто-то натолкнет вас на вирус, чтобы прочитать историю файлов cookie IE или Firefox, вы с удовольствием узнаете своего пользователя-администратора и можете использовать другие.
Итак, как решить проблему? Простой: объедините cookie с сеансовым сервером или cookie сеанса с сервером сеансов или сеансом с сеансом файла или cookie с файловым сеансом …. будет безопасным, но медленным: ((((
Я сохраняю все данные входа в сеансе пользователей, таким образом, все его серверную часть хранится.
Единственное, что я мог бы хранить в клиенте cookie, это такие вещи, как «автоматический вход в систему», «идентификатор сеанса»,
СЕССИЯ более безопасна, чем cookie, и я советую создать уникальный идентификатор для текущей попытки входа в систему, например:
$id = uniqid(); $_SESSION['username'.$id] = "something ...";