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

0

Мне нужно уточнить мои сомнения по поводу сессий PHP.

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

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

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

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

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

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

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

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

  • Идентификатор сессии,
  • ID_User,
  • Доступ к данным.

Чтобы вставить 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.

Exact?

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

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

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

Теги:
session
session-variables

1 ответ

0

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

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

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

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

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

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

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

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

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

Сгенерируйте UUID, создайте строку с

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

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

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

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

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

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

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

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню