Система входа в систему (PHP) Файлы cookie и сессии

Question

Я хочу создать систему входа в систему с использованием файлов cookie / сессий, но я не уверен, что такое безопасность с ними.

В сеансах, если для "login" установлено значение "yes", могу ли я этому доверять? Могут ли пользователи изменить то, что он возвращает? Стоит ли просто хранить зашифрованный пароль и проверять его на каждой странице?

Должен ли я проверять наличие таких файлов, как инъекции mysql, с помощью файлов cookie?

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

Answer 1

Если вы установите переменную сеанса, пользователь не сможет напрямую изменить ее, если он не перехватит другой файл cookie сеанса.

То, на что вам в основном нужно обращать внимание, это на виртуальном хостинге, ваши данные сеанса не защищены (обычно это могут видеть другие сайты).

Стоит также отметить, что данные cookie также не защищены. Не следует полагаться так же, как нельзя полагаться на данные формы (независимо от того, что говорит проверка клиента).

Ваши лучшие практики с паролями:

1. Сохраните пароль в базе данных в хешированном виде, предпочтительно SHA1 (первый выбор) или MD5 (второй выбор);
2. Получив пароль пользователя, зашифруйте его и сравните с тем, что хранится в базе данных;
3. Установить имя пользователя, вошедшего в систему в сеансе пользователя;
4. Срок действия файла cookie истекает через некоторый период (даже если его дни), вместо того, чтобы он длился вечно; и
5. Используйте безопасное соединение (HTTPS, а не HTTP), где это возможно. SSL-сертификаты дешевы.

Answer 2

Как утверждают несколько человек, никогда не доверяйте пользовательскому вводу. Обеззараживая ввод, особенно поля имени пользователя и пароля, вы помогаете отразить атаки SQL-инъекций.

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

Вот пара статей, которые вы должны прочитать о сессиях, безопасности и хэшировании - просто хэширования ваших паролей к SHA1 или MD5 недостаточно, заточите их, чтобы они стали еще более надежными. Нет такой вещи, как непробиваемая безопасность - даже если вы делаете ВСЕ правильно, кто-то может взломать ее - это неизбежно. Ваша задача состоит в том, чтобы сделать вещи настолько сложными, насколько это возможно, сломать / использовать.

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

Эта статья содержит полезную информацию о создании уникальных отпечатков пальцев для ваших посетителей, помогает усложнить перехват сеансов - Руководство по безопасности PHP: Сеансы

В этой статье рассматриваются основные методы хеширования паролей и подсчета - Хеширование паролей

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

Answer 3

Практическое правило: не доверяйте пользовательскому вводу. Cookie-файлы - это пользовательский ввод, идентификаторы сессий, которые хранятся в cookie-файлах, - это пользовательский ввод, http-заголовки - это пользовательский ввод - эти вещи должны быть проверены трижды для каждой возможной вещи. Данные сеанса, с другой стороны, хранятся на вашем сервере, поэтому они более или менее безопасны, если не хранятся в /tmp.

.

Одна из самых популярных установок для авторизации сеанса такова: идентификатор сессии хранится в cookie, а все остальное, включая пароль, сохраняется в сессии. После запуска сеанса на основе идентификатора из файла cookie вы должны получить идентификатор пользователя из данных сеанса и затем проверить, действителен ли сохраненный там пароль.

Answer 4

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

Пример: данные cookie могут быть: logged_in = true; user = 'admin'; sessionid = [случайно сгенерированный идентификатор (я обычно просто md5 случайно сгенерированное слово, которое я создаю)]

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

Вот быстрый пример, который я украл из проекта CI, над которым я работал пару недель назад:

    function logged(){
$logged_in = $this->session->userdata('logged_in');
if($logged_in){
  $userid = $this->session->userdata('userid');
  $sessionhash = $this->session->userdata('hash');

  $this->db->where('id', $userid);
  $this->db->where('hash', $sessionhash);
  $query = $this->db->get('members');

  if($query->num_rows == 1){
    return TRUE;
  }else{
    return FALSE;
  }
}
}

Answer 5

Эта система входа - отличная возможность для изучения.

Answer 6

Любой пользовательский ввод должен тщательно проверяться и дезинфицироваться, будь то данные GET и POST, данные cookie.

Чтобы ответить на ваш вопрос, если сохранение состояния входа в сеанс var безопасно, ответ - да. Просто не забывайте очищать все, что отправляет вам пользователь, независимо от того, насколько безопасным оно должно быть.