Какой тип информации должен быть сохранен в Cookie (PHP)

Question

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

Краткий пример, я уверен, что вы, ребята, можете понять суть ...

function login($email, $password, $remember){
  // Check the database for email/password combo
  if(/*user exists*/){ // if the user exists
    $_SESSION = /*User data*/ // save the users data in a session
    if($remember){
      setcookie('user_id', /*User id*/); // save the user id in a cookie
    }
    header("location: index.php");// redirect
  }
}

function Check_Cookie(){
  if(isset($_COOKIE['user_id'])){
    return $this->Log_In_ID($_COOKIE['user_id']);
  }else{
    return false
  }
}

function Log_In_ID($id){
  //Check the database if the user id exists
  if(/*user exists*/){ // if the user exists
    $_SESSION = /*User data*/ // save the users data in a session
    header("location: index.php");// redirect
  }else{
    return false;
  }
}

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

Answer 1

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

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

Когда пользователь входит в систему, вы создаете новый GUID и сохраняете его вместе с пользователем:

UserID        TokenID                                        Expires
1274          {3F2504E0-4F89-11D3-9A0C-0305E82C3301}         9/25/2009 12:00:00

Когда пользователь возвращается, найдите его идентификатор пользователя по токену, убедитесь, что токен не истек, и войдите в него. Затем измените его токен. Это защищает вас от следующего:

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

Answer 2

Вы не должны доверять данным cookie. Что произойдет, если я отредактирую свой файл cookie и задаю для своего идентификатора «1» (который, вероятно, будет администратором)?

По сути, не делайте этого.

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

Answer 3

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

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

Другая тактика - хранить длинный уникальный идентификатор сеанса и использовать его для входа пользователя.