Интеграция сессий, является ли этот подход безопасным?
Пользователь входит в систему, используя аутентификацию Laravel по умолчанию, которая помещает зашифрованный cookie в браузер и сохраняет сеанс в базе данных.
Пользователь переходит на классическую страницу asp, где я проверяю значение cookie, получаю хэш и вызываю приложение laravel, передавая хэш идентификатора сеанса.
Затем я использую это в laravel, чтобы увидеть, есть ли активный сеанс для этого идентификатора, и если да, я возвращаю true, чтобы пользователь мог войти в систему, в классическом asp.
При каждом запросе страницы в классическом приложении я проверяю last_updated_time в БД и обновляю его на каждой странице. Все входы и выходы выполняются в laravel, и classic использует базу данных для определения активности сеанса.
Я бы также назвал публичный URL, чтобы получить переменные сеансов и добавить переменные сеансов, используя laravel, поскольку все это зашифровано, и для этого было бы сложно использовать классический asp.
Единственный риск, который я вижу, это хай-джекджинг сессий, но я не думаю, что это более высокий риск, чем обычно.
Важно ли заблокировать URL-адрес laravel, который я вызываю, чтобы проверить, является ли это действительным сеансом?
Я пропустил дыру в безопасности здесь?
Решение
Безопасен ли этот метод?
Из того, что вы заявили вам наверное не открыли никаких дыр в безопасности. Файл cookie сеанса сам по себе не зашифрован на компьютере пользователя, но вы убедитесь, что он зашифрован между их компьютерами и вашим, а также между каждым из ваших компьютеров. Вы должны убедиться, что вы установили Безопасный флаг чтобы предотвратить случайную отправку cookie-файлов через традиционный незашифрованный транспорт (HTTP), но, как уже говорилось, это не влияет на сохранение самого cookie-файла.
Тем не менее, вы, по сути, угоняете свои собственные сессии пользователей. Пока дыра может быть не вводите сейчас, вы потенциально ослабляете всю систему, что может привести к дыре в будущем.
Есть ли лучший способ сделать это?
Это может быть глупый вопрос, но вы уверены, что вам нужен сеанс? Если вы манипулируете учетными данными между серверами, это больше похоже на то, что вы хотите использовать Жетоны доступа и отказаться от сессии.
Использование токенов доступа аналогично использованию сессий, но вам нужно отключить состояние ваших служб. Это означает, что вы больше не храните информацию о зарегистрированном пользователе на какой-либо конкретной машине, поэтому вам нужно будет извлекать все, что вам нужно, из базы данных каждый раз, когда они попадают на сервер, требующий эту информацию.
В долгосрочной перспективе это хорошо, так как гораздо проще масштабировать свои сервисы, когда вам не нужно сильно беспокоиться о том, где находится сессия и что внутри нее.
OAuth 2.0 широко используется стандарт (facebook, щебет, Google), и был специально разработан, чтобы быть простым в использовании. RFC сложен, но есть журнал хорошо направляющие там не волнуйтесь.
Единственный недостаток OAuth 2 (если это можно так назвать) заключается в том, что оно ДОЛЖНО происходить через зашифрованное соединение. Если ваш вариант использования не может гарантировать шифрование по SSL или (предпочтительно) TLS, то вам следует использовать OAuth 1.0 (С редакция А) вместо
Это связано с тем, что OAuth 2.0 выставляет свой «секретный» токен в запросах, тогда как OAuth 1.0 использует его только для обеспечения хэша подписи. Если вы выберете этот путь, желательно использовать чужую библиотеку, поскольку хеш очень специфичен.
Дальнейшее улучшение
(Примечание: этот раздел добавлен после того, как ответ принят)
Одна система, которую я недавно изучал, Json Web Tokens. Они хранят информацию о пользователе, чтобы сохранить каждую машину, повторно просматривая ее в базе данных. Поскольку токен хешируется с секретом, вы можете быть уверены, что, пока ваш секрет не раскрыт, действительный токен представляет собой успешно вошедшего в систему пользователя, без необходимости прикасаться к базе данных.
Вы должны избегать помещения чего-либо слишком личного в токены, если это возможно. Если вам необходимо хранить личную или секретную информацию в токене, вы можете зашифровать ее или использовать обратный кеширующий прокси-сервер для замены JWT на традиционный токен безопасности. Может показаться, что вначале это противоречит цели, но это означает, что некоторым вашим службам может вообще не понадобиться доступ к базе данных.
Другие решения
Я не эксперт по безопасности, но я не вижу проблем с этим. Упакованный обработчик сеанса базы данных Laravel работает так же. Файл cookie содержит хэш, который ссылается на запись в базе данных. Данные сеанса кодируются в base64, но это ни здесь, ни там. Я думаю, что вы могли бы на самом деле избежать скручивания своего собственного и просто использовать Laravel DatabaseSessionHandler.
Осветить / Session / DatabaseSessionHandler
… Я просто немного углубился в ваш вопрос и заметил часть об общедоступном URL для установки и получения данных сеанса. Я думаю, что это действительно плохая идея. Главным образом потому, что это обеспечит открыть дверь конечному пользователю, позволяя ему читать и записывать данные сеанса. Это может плохо кончиться.
Как я уже говорил выше, данные только закодировано в base64, так что я верю, что вы сможете анализировать, читать и записывать это в свое сердце в asp.
редактировать
Хорошо … Я думаю, что это последнее редактирование. Данные сериализуются в php, а затем кодируются в base64. это вопрос Похоже, это может помочь вам в этом. Если это не так и конечная точка API является единственным способом, найдите способ заблокировать доступ конечного пользователя к нему.
Кроме перехвата сеансов, нет. Это стандартный способ взаимодействия приложений на внутренней основе. Конечно, может быть лучший способ получить данные, если вы выберете другой тип хранилища сеансов, кроме вашей базы данных, например Memcached.
Есть пара вещей, которые можно сделать.
- Сделай канал HTTPS. Это сделает почти невозможным нюхать ваш транспортный слой.
- Вместо того, чтобы взаимодействовать с вашим файлом cookie, вы можете использовать JWT чтобы выполнить эту задачу. Что поможет вам использовать существующие функции в вашей системе при подключении к системе ASP. Вы можете написать небольшой веб-сервис REST, который позволяет ASP подключаться. Вы могли бы использовать это Lib. Вы можете сослаться Эта статья который даст вам представление, как это должно быть сделано.
Пожалуйста, дайте мне знать, если вам нужна дополнительная информация.