Интеграция сеансов - безопасен ли этот подход?

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

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

Затем я использую это в laravel, чтобы увидеть, есть ли активный сеанс для этого id, и если это так, я возвращаю true, поэтому пользователь может войти в систему в классическом asp.

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

Я бы также вызвал публичный url для получения переменных сеанса и добавления переменных сеанса с использованием laravel, поскольку все это зашифровано и использование классического asp для этого было бы трудным.

Единственный риск, который я вижу, - это сеанс высокой загрузки, но я не думаю, что это более высокий риск, чем обычно.

Важно ли блокировать URL-адрес laravel, который я вызываю, чтобы проверить, действительно ли он работает?

Я пропустил здесь отверстие безопасности?

Ответ 1

Безопасен ли этот метод?

Из того, что вы сказали, вы, вероятно, не открыли никаких дыр в безопасности. Файл cookie сеанса сам по себе не зашифрован на компьютере пользователя, но вы убедитесь, что он зашифрован между их машинами и вашим, а также между каждой вашей машиной. Вы должны убедиться, что вы установили Secure Flag, чтобы предотвратить случайное отправление файла cookie по традиционному незашифрованному транспорту (HTTP), но, как указано, это не влияет на сохранение самого файла cookie.

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

Есть ли лучший способ сделать это?

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

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

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

OAuth 2.0 широко используется стандартно (Facebook, Twitter, Google) и был специально разработан, чтобы быть простым в использовании. RFC сложный, но есть журнал хороший руководства там не беспокойтесь.

Одна небольшая нижняя сторона (если вы можете ее назвать) для OAuth 2, заключается в том, что она ДОЛЖНА произойти по зашифрованному соединению. Если ваш прецедент не может гарантировать шифрование через SSL или (желательно) TLS, то вы должны использовать OAuth 1.0 (WITH версия A).

Это связано с тем, что OAuth 2.0 предоставляет этот "секретный" токен в запросах, где OAuth 1.0 только использует его для предоставления хэша подписи. Если вы возьмете этот маршрут, желательно использовать другую библиотеку, поскольку хеш очень специфичен.

Дальнейшее улучшение

(Примечание: этот раздел добавлен после принятия ответа)

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

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

Ответ 2

Я не эксперт по безопасности, но я не вижу проблемы с этим. Упакованный обработчик сеанса базы данных Laravel работает одинаково. Файл cookie содержит хэш, который ссылается на запись в базе данных. Данные сеанса кодируются base64, но ни здесь, ни там. Я думаю, вы могли бы вообще не сворачивать свои собственные и просто использовать Laravel DatabaseSessionHandler.

Illuminate/Session/DatabaseSessionHandler

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

Как я уже сказал выше, данные кодируются только base64, поэтому я считаю, что вы сможете анализировать, читать и писать это в своем сердце в рамках asp.

Edit

Хорошо... Я думаю, что это последнее редактирование. Данные основаны на php, а затем закодированы base64. Этот question выглядит так, как будто это может помочь вам в этом. Если это не так, и конечная точка API является единственным способом, найдите способ заблокировать доступ конечного пользователя.

Ответ 3

Помимо захвата сеанса, нет. Это стандартный способ взаимодействия приложений на внутренней основе. Конечно, может быть лучший способ получить данные, если вы выбираете другой тип хранилища сеансов, отличный от вашей базы данных, например Memcached.

Ответ 4

Есть несколько вещей, которые можно сделать.

Сделать канал HTTPS. Это сделает почти невозможным обнюхивание вашего транспортного слоя.
Вместо того, чтобы взаимодействовать с вашим файлом cookie, вы можете использовать JWT, чтобы выполнить эту задачу. Это поможет вам использовать существующие функции в вашей системе при подключении к системе ASP. Вы можете написать небольшую веб-службу REST, которая позволяет ASP подключаться. Вы можете использовать эту lib. Вы можете ссылаться на эту статью, которая даст вам представление о том, как это сделать.

Пожалуйста, дайте мне знать, если вам нужна дополнительная информация.