Multiple stateful frames on page will overwrite JSESSIONID?

Question

We are looking for someone who confirms or disproves my theory that deploying two frames pointing to two different pages while maintaining state on the same domain can overwrite JSESSIONID. Here is what I am looking at:

Customization

• Suppose you have two pages that require the HttpSession state (affinity session) to work correctly - deployed to http://www.foo.com/ page1 and http://www.foo.com/ page2
• Suppose that www.foo.com is the only host running Tomcat (6.0.20, fwiw) that uses JSESSIONID for session identifiers.
• Suppose these pages are turned into two iframes that will be embedded on third-party sites: http://www.site.com/page1 "/"> (and / page2)
• Suppose there is a third-party site that wants to host both widgets on the page http: // www . bar.com /foowidgets.html

Is the following race condition possible?

• a new visitor will go to http://www.bar.com/foowidgets.html
• browser loads urls in foowidgets.html including two iframe 'src' urls
• since browsers open several simultaneous connections to the same host (afaik up to 6 in the case of chrome / ff), the browser simultaneously issues requests http://www.foo.com/page1 and http://www.foo.com/page2
• Tomcat @ foo.com receives both requests at about the same time, calls getSession () for the first time (on two different threads) and lazily creates two HttpSessions and thus two JSESSIONIDs, with values ​​of $ Page1 and $ Page2. Requests also contain data in the corresponding sessions (this data will be required to process subsequent requests).
• Suppose the browser first receives a response to page 1 of the request. Browser sets cookie JSESSIONID = $ Page1 for HOST www.foo.com
• The following response to the page2 request is received and the browser overwrites the JSESSIONID cookie for HOST www.foo.com with $ Page2
• the user clicks on something in the 'page1' iframe on foowidgets.html; browser issues 2nd request http://www.foo.com/page1?action=doSomethingStateful . This request carries JSESSIONID = $ Page2 (not $ Page1) since the cookie value was overwritten)
• when foo.com receives this request, it does not look at the HttpSession Instance correctly (since the JSESSIONID key is $ Page2 and NOT $ Page1). Foobar!

Could this have happened? I think so, but I would be grateful for the confirmation.

If it is clear that this is possible, then what are some solutions, given that we would like to support multiple iframes per page? We don’t have a solid need for frames to have the same HttpSession, although this is beautiful. In case the solution is still a separate HttpSession for each iframe, it is - of course - mandatory that iframe 1 does not refer to the httpSession state for iframe 2 instead of its own.

Above my head I can think:

• map page1 and page2 for different domains (service overhead)
• Use URL rewriting and never use cookies (spoil analytics).
• anything else?

Thanks a lot, -nikita p>

Answer 1

TL DR The script is correct, and one session overrides the other, and both pages share the session; but it does not matter.

---

In the above example, you have two simultaneous anonymous anonymous requests.

In other words, the request is not unique; two shared pages will be returned. Both of these pages will have new JSESSIONIDs not because of the race, but because the requests themselves are anonymous and therefore, essentially, ask Tomcat to create new sessions.

Suppose page2 won the JSESSIONID speed contest and the browser now has page2 cookie. Then the user clicks on the action on page 1. I think you are correct that the request will be marked with cookie page2.

But so what?

Page1 cannot contain any information related to the session, and therefore does not contain information about the user. Therefore, actions from it cannot have any state associated with the session (the state has just been created). If there is no specific state associated with the session, then there is no problem with the "wrong" JSESSIONID.

Look at it differently: if the request for page2 was completely processed before the request on page 1, how will page1 be different? I do not see the differences. If there is no difference in the returned HTML between the two scripts, then it does not matter that its JSESSIONID has changed.

OTOH, if the user has already visited bar.com, requests for pages and page2 will be associated with the same JSESSIONID, the returned pages are correct, and all this is good in the world of foo.com.

One problem: If you have CSRF protection enabled. CSRF libraries modify all URLs on the returned page to include an additional parameter. The CSRF Security Library checks for all incoming requests that their security token matches JSESSIONID. If page1 uses the cookie for page 2, CSRF protection rejects the request as forged.

If you need to have one session in an iframe : use URL rewriting. It was originally intended to manage sessions when the browser does not accept cookies. It works well, but the urls look disgusting.

Answer 2

What you are saying is correct that the raison d'etre of the HttpServletResponse.encodeURL () method.

If a page containing two frames is in the same context as pages 1 and page 2, the URLs in the iframe must be encoded using this method or retrieved using the JSTL <c: url> tag.

It will add a JSESSIONID to the URL if no cookies are already defined.

Answer 3

If page1 and page2 use a different context, they will work through third-party iframes without interfering with each other.

There are various ways to manage sessions in the JSP. The answer to this question can help you find the right solution: Under what conditions is a JSESSIONID created?