Hello Christopher,
2015-10-29 16:13 GMT+01:00 Christopher Schultz <ch...@christopherschultz.net >: > Roel, > > On 10/29/15 6:32 AM, Roel Storms wrote: > > On Oct 28, 2015 21:01, "Christopher Schultz" < > ch...@christopherschultz.net> > > wrote: > >> On 10/28/15 12:34 PM, Mark Thomas wrote: > >>> On 28/10/2015 13:01, Roel Storms wrote: > >>>> Hello, > >>>> > >>>> > >>>> I was looking into session management on Tomcat 8.0.29 and found this > >>>> comment: > >>>> > >>>> In apache.catalina.connector.Request method doGetSession(bool) line > >> 2886: > >>>> > >>>> * // Attempt to reuse session id if one was submitted in a > >> cookie* > >>>> *// Do not reuse the session id if it is from a URL, to > prevent > >>>> possible* > >>>> * // phishing attacks* > >>>> // Use the SSL session ID if one is present. > >>>> > >>>> Why do you put more trust in a session id from a *cookie* then from a > >> *URL*? > >>>> Is there an (invalid) assumption that cookies are hard to manipulate? > >>> > >>> It is based on the fact that cookies require more effort from an > >>> attacker to control. > >> > >> Just to clarify, the "attacker" in this case isn't the user of the web > >> application. Yes, any client can send any header (cookie) they want. But > >> an attacker trying to trick someone else into sending a cookie is going > >> to have a harder time than trying to get them to click on a link that > >> has an embedded session identifier. > >> > >>> Creating the session with the client provided ID is required for some > >>> features to operate correctly. > >>> > >>>> Additionally I was hoping to find some* design documentation on the > >> session > >>>> mechanism*. Has anyone constructed any diagram or created some other > >> form > >>>> of documentation useful for figuring out how sessions are created and > >>>> maintained? > >>> > >>> Not that I am aware of. The relevant source code isn't that long. > >>> Reading it is probably the quickest way. > >> > >> Roel, what are you looking for specifically? The servlet spec lays-out > >> when sessions are created/destroyed, etc. Do you think Tomcat needs > >> documentation in addition to that? > >> > >> -chris > >> > >> > > I understand the difference. But still, isn't it possible to not allow it > > for cookies. You mention some web applications depend on it. In what way? > > There are some web applications that will break if you disable cookies > on the browser. There are other applications that will break if cookies > are not used on the server as the means of communicating the session id > from the client to the server. This usually happens when programmers > don't realize that every URL emitted back to the client needs to go > through HttpServletResponse.encodeURL or > HttpServletResponse.encodeRedirectURL. If you don't do these things, > cookie-based session-tracking will be required. > I don't mean to disable cookies. This comment just made me wonder why you would generate a new session ID in case of a URL rewrite supported session and would not do it for cookies. > > > I am still looking into it but a.t.m. I am drawing my own UML diagrams to > > figure out how an incoming Http packet results in a Catalina.Request > being > > generated and where I can intercept in order for me to use a different > > session management mechanism. > > Do you just want to change from cookie-based session-tracking to > URL-based session-tracking? Because you can do that using web.xml and > don't have to write any code. > > If you want to completely change the way Tomcat deals with sessions, you > can write your own Manager implementation and wire it in using context.xml: > > http://tomcat.apache.org/tomcat-8.0-doc/config/manager.html > > Note that session-id management and session-storage are separated in > Tomcat. I don't think you'll be able to meddle in the session-id > management of Tomcat without significant work. On the other hand, if you > want to put session data into memcached instead of in the JVM's heap, > you can write your own Manager to do that and allow Tomcat to continue > to manage the session-id management with the client. > > > Someone pointed out that I might be able to achieve what I want using > > interceptors. Let's see what we can find. > > It's still not clear to me what you actually want to do, so I can't > offer any advice. > > -chris > > > I am looking to implement SecSess in tomcat. SecSess: https://lirias.kuleuven.be/bitstream/123456789/503824/1/p2171-de_ryck.pdf Yesterday I stumbled upon filters that intercept HttpRequests and Responses. This is probably going to be ideal for my purposes. Indeed maybe the Manager should change but I can simply inherit from it and implement my own. The same goes for StandardSession. Eventually persistency will be required but for now a simple in memory solution will suffice. It's more a proof of concept than anything else. Thanks for your advice. Rgds, Roel
