Лучший способ проверки сеанса в iframe другого домена - PullRequest
Новая
       39

Лучший способ проверки сеанса в iframe другого домена

3 голосов
/ 06 марта 2012

У меня есть сайт A, который встраивает модули в iframe B. Модули могут быть в другом домене. У пользователя есть аутентифицированный сеанс в A, и я хочу, чтобы B отказался загружать, если у пользователя нет действительного сеанса в A. B не нужно ничего знать, кроме того факта, что у пользователя есть аутентифицированный сеанс с A. Нет данных сеанса. нужен.

На данный момент ни HT, ни B не стоят за HTTPS, но я хочу изменить это, когда смогу убедить людей наверху купить SSL-сертификат.

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

Вариант 1

  1. A добавляет ?session=SESSION_ID к URL-адресу B
  2. Серверный сценарий в B извлекает идентификатор сеанса и выполняет GET A/verify?session=SESSION_ID
  3. A отвечает 200 OK или 403 Forbidden
  4. Если ответ от A был 200, то пользователь считается аутентифицированным, разрешен доступ к B

расквитаться

  • Простота реализации
  • Нет необходимости в общей конфигурации (кроме URL-адреса A, который B уже знает)

Downsides

  • B должен связаться с A, что увеличивает время загрузки
  • Идентификаторы сессий должны быть секретными - не должны передаваться
  • Подвержен повторным атакам (до тех пор, пока сеанс действителен)

Вариант 2

  1. A шифрует блок данных, содержащий метку времени, URL-адрес A, URL-адрес B и соль с ключом, общим для A и B, и добавляет его к URL-адресу B
  2. Серверный скрипт в B дешифрует блок данных, проверяет URL-адреса и проверяет, что отметка времени не слишком старая
  3. Если все проверено, пользователь считается аутентифицированным и ему разрешен доступ к B

расквитаться

  • Нет связи сервер-сервер
  • Идентификатор сеанса никогда не передается на B
  • Не подвержен атакам воспроизведения (за пределами времени, разрешенного для отметки времени)

Downsides

  • Более сложный для реализации
  • A и B должны быть несколько синхронизированы по времени
  • А и В нужно поделиться ключом

1 Ответ

2 голосов
/ 06 марта 2012

Опция 3

A генерирует случайный хэш и сохраняет его в таблице базы данных вместе с идентификатором сеанса (два поля).A передает хэш каждому URL-адресу для B, например `B /? Hash = x '

A, проверяет, соответствует ли хеш-код в таблице базы данных, а также проверяет, является ли идентификатор сеанса все ещеАутентифицированный (возможно, вышел из системы или истек срок действия), а затем сообщает B, хорошо это или нет.Например, A/verify?hash=x.

Как вы говорите, B не нужно знать ничего, кроме как аутентифицировано или нет.

Таким образом, идентификатор URL-адреса сеанса не передается в URL.что опять же, как вы говорите, не идеально.

...