Страшный "держать меня в системе" и проверку сессии

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

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

Проверка сеанса

Итак, прежде всего, вот диаграмма (к моему пониманию до сих пор), как проверить, что пользователь может получить доступ только к содержимому "только члены". (этот код находится в верхней части страницы для проверки и установки переменных, таких как $loggedin = true;)

В своем роде, мой $_SESSION['loggedin'] - это просто имя пользователя. По моему мнению, сеансы могут быть сфальсифицированы или захвачены из одного домена, поэтому я знаю, что это очень неуверенно (например, злоумышленник может каким-то образом сделать сеанс, содержащий другое имя пользователя и voilà - мгновенный доступ к этим материалам пользователей). Но я не знаю, как я должен проверять сеанс. Единственный способ, который я могу себе представить, - это подключиться к базе данных каждый раз, когда загружается страница, и проверить хэш-код MD5 или что-то из базы данных (и обновить его), но я полагаю, что это создаст много ненужного трафика сервера и я "Почти наверняка есть лучший способ сделать это".

Вход в систему

Вот диаграмма того, что происходит, когда пользователь входит в систему (И должен ли отображаться приветствие или окно входа в систему.)

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

Итак, мои вопросы:

Как проверить мои сеансы не поддельные?
Как я могу проверить, что мои файлы cookie не поддельные?
Может ли мой метод регистрации быть достаточно безопасным после проверки на месте?
Есть ли что-то важное, что я забыл?

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

Ответ 1

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

Если вы хотите, чтобы человек находился в средней атаке, вы должны использовать HTTPS.

Использование HTTPS гарантирует, что:

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

Основными недостатками HTTPS являются:

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

Ответ 2

Очень красиво иллюстрированный вопрос!

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

Теперь файлы cookie могут быть захвачены (см. Firesheep, например), "человек в средних атаках". Нападавший просто копирует cookie другого человека (которые отправляются вместе с каждым запросом) и добавляет их в свой браузер. И поскольку сеансы идентифицируются с помощью файлов cookie, вы можете захватить сеанс таким образом (злоумышленник просто будет использовать сайт с тем же самым сеансом, что и пользователь). Или вы можете захватить cookie "помните меня" для последующего использования.

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

В противном случае у вас есть правильная идея о том, как сопоставить cookie с постоянным именем пользователя (т.е. хэш в файле cookie должен соответствовать таковому в базе данных). Для проверки сеанса вам не требуется хеширование, так как данные сеанса никогда не покидают сервер. Таким образом, вы можете просто установить $_SESSION['logged_in_user_id'] в UID - или в false/null, если они не вошли в систему. То есть, если cookie проверяет или проверяет имя пользователя/пароль, тогда установите идентификатор пользователя в сеанс как простой int.

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

Незначительные моменты:
Для алгоритма хэширования я бы пошел с sha1, а не старше md5. А для имени пользователя/пароля в базе данных никогда не рекомендуется хранить пароль в виде открытого текста в базе данных. Если ваша база данных будет нарушена, злоумышленники могут просто читать все, независимо от того, насколько безопасно ваш сервер взаимодействует с вашими пользователями.

Вы, наверное, все это знаете, но на всякий случай: для таблицы пользователей сохраните имя пользователя как текстовое, но также создайте соль (скажем, хеш текущее время плюс произвольную, но константную!) строку, которую вы определяете, и хеш его несколько раз). Храните соль в базе данных и используйте ее при хешировании пароля. И снова, хэш это неоднократно много раз. Наконец, сохраните хешированный пароль в БД. Вы не сможете отправлять людям свои пароли, потому что вы тоже не знаете (вы просто знаете хэш), но вы можете реализовать опцию "reset password", которая генерирует новую соль и случайную строку, который вы тогда используете как любой другой пароль. Просто не забудьте сохранить новый не-хешированный пароль достаточно долго, чтобы отправить его пользователю. Причина, по которой вы хотите хешировать ее несколько раз, заключается в том, что она делает невозможным использование таблицы радуги для "реверсирования" хэширования, даже если вы знаете соль (и). Если вы только что хэшировали пароль один раз, с md5 и без соли, было бы тривиально искать хэш и посмотреть, что такое unhashed password (если только ваши пользователи не достаточно умны, чтобы использовать очень длинные случайные пароли, которые не являются найденные в любых таблицах радуги).

Короче говоря: сеанс, файлы cookie и имя пользователя/пароль уязвимы для того же типа атаки. Наиболее практичной защитой от него является использование SSL (поскольку, как вы заметили, IP-адреса меняются).

Также см. другие ответы. Чем больше информации, тем лучше:)

Ответ 3

Как проверить мои сеансы не поддельные?

Установив переменную при создании.

session_start();
if(empty($_SESSION) || !isset($_SESSION['notfake']){
   $_SESSION = array();
   session_regenerate_id();
   $_SESSION['notfake']=1;
}

Как я могу проверить, что мои файлы cookie не поддельные?

Проверяя их в базе данных. Иметь достаточно длинный идентификатор. Не намного больше вы можете сделать, помимо блокировки IP-адресов, которые в течение короткого времени имеют "много" недействительных файлов.

мог ли мой метод регистрации быть достаточно безопасным после проверки на месте?

Зависит, вы используете HTTPS для всего? Кроме того, установите cookie сеанса только в https.

Есть ли что-то важное, что я забыл?

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