несколько iframes с сохранением состояния на странице будут перезаписывать JSESSIONID?

Question

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

Настройка

1. Предположим, у вас есть две страницы, для которых требуется корректное функционирование состояния HttpSession (сходство сеанса) - развернуто в http://www.foo.com/page1 и http://www.foo.com/page2
2. предположим, что www.foo.com - это единственный хост, на котором запущен Tomcat (6.0.20, fwiw), который использует JSESSIONID для идентификаторов сеансов.
3. предположим, что эти страницы перевернутыв два виджета iframe для встраивания на сторонние сайты: http://www.site.com/page1" /> (и / page2 соответственно)
4. предположим, что существует сторонний сайт, который хочет разместить оба виджета на одной странице на http://www.bar.com/foowidgets.html

Может ли произойти следующее состояние гонки?

1. новый посетитель переходит на http://www.bar.com/foowidgets.html
2. браузер начинает загружать URL-адреса в foowidgets.html, включая два URL-адреса iframe 'src
3. , поскольку браузеры открывают несколько одновременных подключений к одному и тому же хосту (например, до 6 в случае chrome / ff), браузер одновременно выдает запросы на http://www.foo.com/page1 и http://www.foo.com/page2
4. tomcat @ foo.com получает оба запроса примерно в одно и то же время, впервые вызывает getSession () (в двух разных потоках) и лениво создает две HttpSessions и, следовательно, два JSESSIONID со значениями $ Page1 и $ Page2.Запросы также вставляют данные в соответствующие сеансы (эти данные потребуются для обработки последующих запросов)
5. предполагают, что браузер сначала получает ответ на запрос page1.Браузер устанавливает cookie JSESSIONID = $ Page1 для HOST www.foo.com
6. следующий ответ на запрос page2 получен, и браузер перезаписывает cookie JSESSIONID для HOST www.foo.com с помощью $ Page2
7. пользователь нажимает что-то в iframe 'page1' на foowidgets.html;браузер выдает второй запрос на http://www.foo.com/page1?action=doSomethingStateful. Этот запрос содержит JSESSIONID = $ Page2 (а не $ Page1 - поскольку значение cookie было перезаписано)
8. когда foo.com получает этот запрос, он ищетнеправильный экземпляр HttpSession (потому что ключ JSESSIONID равен $ Page2, а НЕ $ Page1).Foobar!

Может ли это произойти?Я так думаю, но был бы признателен за подтверждение.

Если вышеупомянутое явно возможно, каковы некоторые решения, учитывая, что мы хотели бы поддерживать несколько фреймов на страницу?Нам не нужно, чтобы iframes использовали один и тот же HttpSession, хотя это было бы неплохо.В случае, если решение все равно будет предусматривать отдельную HttpSession для каждого iframe, конечно, обязательно, чтобы iframe 1 не заканчивал ссылками на состояние httpSession для iframe 2 вместо собственного.

вне моей головыЯ могу вспомнить:

1. сопоставить страницу 1 и страницу 2 с разными доменами (издержки ops)
2. использовать перезапись URL-адреса и никогда не использовать cookie-файлы (портит аналитику)
3. что-нибудь еще?

спасибо большое, -nikita

Answer 1

TL; DR Сценарий правильный, и один сеанс перекрывает другой, и обе страницы совместно используют сеанс;но это не имеет значения.

---

В приведенном выше примере у вас есть два почти одновременных анонимных запроса без сохранения состояния.

Другими словами, в запросе нет абсолютно ничего уникального;две общие страницы будут возвращены.На обеих этих страницах будут новые JSESSIONID не из-за гонки, а из-за того, что сами запросы анонимны, и поэтому по сути просят Tomcat создать новые сеансы.

Предположим, что page2 выиграла конкурс скорости JSESSIONID, и браузер теперь имеетcookie page2.Затем пользователь нажимает на действие на странице 1.Я думаю, что вы правы, что запрос будет отмечен файлом cookie page2.

Ну и что?

Страница1 не может содержать никакой информации, относящейся к сеансу, и, следовательно, никакой информации, специфичной для пользователя.Поэтому его действия не могут иметь состояния, связанного с сеансом (состояние было только что создано).Если нет определенного состояния, относящегося к сеансу, то нет проблемы с ним, связанного с «неправильным» JSESSIONID.

Если посмотреть по-другому: если запрос на страницу2 был полностью обработан до запросадля page1, чем будет отличаться page1?Я не вижу различий.Если нет никаких различий в возвращаемом HTML в двух сценариях, тогда не имеет значения, что его JSESSIONID поменялся местами.

OTOH, если пользователь уже посетил bar.com, то запросы как page1, так и page2 будут связаны с одним и тем же JSESSIONID, возвращаемые страницы верны и все хорошо в мире foo.com.

Одна проблема: Если у вас включена защита CSRF .Библиотеки CSRF изменяют все URL на возвращаемой странице, чтобы включить дополнительный параметр.Библиотека защиты CSRF проверяет все входящие запросы, чтобы их токен безопасности совпадал с JSESSIONID.Если page1 использует файл cookie для page2, защита CSRF отклонит запрос как поддельный.

Если вам нужно иметь один сеанс на каждый фрейм : используйте перезапись URL.Первоначально он был разработан для управления сеансами, когда браузер не принимает файлы cookie.Это работает хорошо, но URL выглядят противно.

Answer 2

Если page1 и page2 используют разные контексты, они будут работать через сторонние iframes, не влияя на область действия друг друга.

Существуют различные способы управления сеансами в JSP. Лучший ответ на этот вопрос может помочь вам найти правильное решение: При каких условиях создается JSESSIONID?

Answer 3

То, что вы говорите, правильно, это смысл метода HttpServletResponse.encodeURL ().

Если страница, содержащая два фрейма, находится в том же контексте, что и page1 и page2, URL-адресав iframes должны быть закодированы с помощью этого метода или получены с помощью JSTLtag.

Он добавит JSESSIONID в URL, если еще не определен файл cookie.