Мне нужно уточнить мои сомнения по поводу сессий 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
пользователя в 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?
Если у кого-нибудь есть какой-нибудь совет для меня или критика того, как я справился с ситуацией, и у меня есть лучшее решение, чем у меня, я охотно выслушаю его.
Если я ничего не понял о том, как работают сессии, то извините меня за то, что я украл у вас.
Спасибо, в любом случае.
Сессии PHP основаны на Cookies. Когда пользователь открывает веб-страницу, PHP в ответ устанавливает cookie. Браузер автоматически гарантирует, что в последующем запросе этот cookie также отправляется в запросах, следовательно, переменные $ _SESSION работают. По моему мнению, они не обеспечивают большую часть безопасности. Вместо идентификатора пользователя теперь злоумышленник должен получить куки файлы. Всегда используйте HTTPS для защиты запросов.
С Android-приложением вы будете делать пользовательский запрос, поэтому вам придется явно устанавливать cookie, полученный после самого первого вызова (вам придется сохранять его на стороне клиента; не очень хороший подход),
Обычный способ работы сессии следующий:
SessionKey1 = { key: value, key2: value2 }
; это может быть в файловой системе диска или на уровне кэша (например, Redis), в зависимости от конфигурации вашего сервера)SessionKey1
изменяется.Теперь вы можете создать подобное поведение для себя. Когда идентификатор пользователя найден на стороне приложения Android, отправьте его бэкэнду, создайте строку в таблице сеансов (идентификатор сеанса в качестве случайной строки и идентификатор пользователя в качестве пользовательского идентификатора). При каждом запросе отправляйте этот SessionId вместе с запросом (в теле или заголовках) на бэкэнд-проверку, получил ли sessionId выход из таблицы Sessions. Если да, получите идентификатор пользователя и обработайте.
Вот альтернативный подход (возможно, немного более безопасный)
Когда токен доступа найден после проверки набора учетных записей
(Это гарантирует, что токен всегда действителен, пользователь не сможет поставить случайный токен для атаки, поскольку он не пройдет проверку с помощью API Facebook).
Сгенерируйте UUID, создайте строку с
отправьте этот UUID в ответ.
Теперь на стороне Android, сохраните этот UUID где-нибудь. Создайте запрос Intercepter, для всего запроса установите этот UUID в пользовательском заголовке (например, X-<application_name>-Auth
). На стороне сервера для каждого запроса, получите доступ к этому заголовку, проверьте, не истек ли он, получите идентификатор пользователя из таблицы сеансов и продолжайте.
Я думаю, что он мог бы очень хорошо получить информацию о сессиях с предложением WHERE ID_user = ID_user.
Совершенно верно?
Вы абсолютно правы. Но защита уровня БД должна быть отдельной задачей от разработки приложений. Как вы думаете, хакер сможет выполнять запросы в первую очередь? Если кто-то найдет способ выполнить необработанные запросы к БД, он может нанести гораздо больший ущерб, чем просто извлечение данных.
Если я прав, то что безопаснее, чем то, что я делаю?
Там нет правильного ответа, вы просто должны сделать все возможное, чтобы защитить приложение. Убедитесь, что ваше приложение соблюдает лучшие правила безопасности. Например - использовать HTTPS, предотвращая SQL-инъекцию (поиск OWASP Vulnerabilities
)