Как сохранить и управлять идентификатором сессии и идентификатором пользователя в PHP и MySql

Question

Мне нужно уточнить сомнения, которые у меня есть о PHP сеансах .

Я создаю Android app, в некоторых действиях мне нужно делать запросы для извлечения пользовательских данных.

На данный момент для этого я отправляю пользователя id в файл PHP через скрытый EditText из Android app.

В Android app пользователь id не сохраняется в shared preferences, но я получаю его по запросу Комплект учетной записи Facebook (для аутентификации используйте Комплект учетной записи Facebook ).

Поэтому, когда мне нужен пользователь id, я запрашиваю его из Kit Account Account Kit , я получаю его и через скрытое поле отправляю его в файл PHP, который я буду использовать позже в WHERE предложении Query.

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

Мой друг сказал мне, что если хакер получает id из session, в котором сохранен пользователь id, может случиться так, что он истек и что он ничего не сможет получить.

Проблема в том, что я не понимаю, как сохранить session ID и user ID и как управлять ими на уровне database архитектуры таблицы.

Мне нужно сохранить session ID в database, я создаю таблицу с именем "Sessions" с 3 полями:

• Session_ID,
• ID_User
• Data_access.

Чтобы вставить пользователя ID в database, я всегда должен передавать его из приложения в файл PHP, и поэтому, если хакер сможет обнаружить пользователя id, я думаю, он вполне может получить информация о sessions с предложением WHERE ID_user = ID_user.

Совершенно верно?

Если я прав, то что безопаснее, чем то, что я делаю?

Тогда, если ID из Session меняется при каждом доступе, чтобы изменить его в таблице Sessions в базе данных MySql, мне следует снова переключиться с Android app на PHP на пользователя id и через запрос Update я должен изменить сессию id и дату доступа с помощью ID_User = ID_User в предложении WHERE.

Целый

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

Если я ничего не понял о том, как работают сессии, то извините меня за то, что я украл у вас.

В любом случае, спасибо.

Answer 1

PHP-сессии основаны на Cookies.Когда пользователь открывает веб-страницу, PHP в ответ устанавливает cookie.Браузер автоматически гарантирует, что в последующем запросе этот cookie также отправляется в запросах, следовательно, переменные $ _SESSION работают.По моему мнению, они не обеспечивают большую часть безопасности.Вместо идентификатора пользователя теперь злоумышленник должен получить куки-файлы. Всегда используйте HTTPS для защиты запросов.

С приложением для Android вы будете делать пользовательский запрос, поэтому вам придется явно устанавливать cookie, как только он будет получен с самого первогоcall (вам придется сохранить его на стороне клиента; не очень хороший подход).

Обычный способ работы сессии следующий:

1. Когда $ _SESSIONиспользуется для установки значения в первый раз, PHP устанавливает файл cookie сеанса, который по сути является случайной строкой.
2. За сценой (в Backend) PHP поддерживает Object (пара ключ-значение)против этого строкового значения.(SessionKey1 = { key: value, key2: value2 }; это может быть файловая система диска или слой кэша (например, Redis), в зависимости от конфигурации вашего сервера)
3. Когда вы устанавливаете / обновляете / удаляете ключ в сеансе, SessionKey1 - этомодифицирована.

Теперь вы можете создать подобное поведение для себя.Когда идентификатор пользователя найден на стороне приложения Android, отправьте его бэкэнду, создайте строку в таблице сеансов (идентификатор сеанса в качестве случайной строки и идентификатор пользователя в качестве пользовательского идентификатора).При каждом запросе отправляйте этот SessionId вместе с запросом (в теле или заголовках) на бэкэнд-проверку, получил ли sessionId выход из таблицы Sessions.Если да, получите идентификатор пользователя и обработайте.

Вот альтернативный подход (возможно, немного более безопасный)

Когда обнаружен токен доступа после проверки набора учетных записей

• отправить его бэкэнду
• проверить токен из API Facebook ( ссылка )
• API проверки также вернет информацию о пользователе, сопоставит ее с данными вашего пользователя (из структуры вашей БД).

(Это гарантирует, что токен всегда действителен, пользователь не сможет поставить случайный токен для атаки, поскольку это не выполнит проверку с помощью API Facebook).

Генерация UUID, создание строки с

• UUID в качестве sessionId,
• Ваш userId
• Доступ к данным
• Создано в (когдастрока создана)
• Срок действия (текущее время + X дней)

отправьте этот UUID в ответ.

Теперь на стороне Android сохраните этот UUID где-нибудь.Создайте запрос Intercepter, для всех запросов установите этот UUID в пользовательском заголовке (например, X-<application_name>-Auth).На стороне сервера для каждого запроса зайдите в этот заголовок, проверьте, не истек ли он, получите идентификатор пользователя из таблицы сеансов и продолжайте.

Я думаю, он вполне мог бы получить информацию о сеансах с предложением WHERE ID_user = ID_user.

Совершенно верно?

Вы абсолютно правы.Но защита уровня БД должна быть отдельной задачей от разработки приложений.Как вы думаете, хакер сможет выполнять запросы в первую очередь?Если кто-то найдет способ выполнить необработанные запросы к БД, он может нанести гораздо больший ущерб, чем просто извлечение данных.

Если я прав, то что безопаснее, чем то, что я делаю?

Нет правильного ответа, вам просто нужно приложить все усилия, чтобы обезопасить приложение.Убедитесь, что ваше приложение соблюдает лучшие правила безопасности.Например - использовать HTTPS, предотвращая SQL Injection.s (поиск OWASP Vulnerabilities)