Session management
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? 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? Rgds, Roel Storms
Re: Session management
Chris and Mark, On Oct 28, 2015 21:01, "Christopher Schultz" wrote: > Mark, > > 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? > > 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. > > Someone pointed out that I might be able to achieve what I want using > interceptors. Let's see what we can find. > > > Rgds, > > Roel >
Re: Session management
Hello Christopher, 2015-10-29 16:13 GMT+01:00 Christopher Schultz : > 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
HTTP Pipelining with session management
Hello, I was wondering if anything special is done with cookie based session management in order for it to deal with HTTP pipelining. https://en.wikipedia.org/wiki/HTTP_pipelining Take the following scenario: Client Request 1 Server ---> Invoke's servlet servlet calls request.getSession() a session is created with SID1 Request 2 > Invoke's servlet servlet calls request.getSession() a session is created with SID2 Reply 1 (including SESSIONID : SID1) <-- Client stores SID1 in a cookie Request 3 (including SESSIONID : SID1) > Invoke's servlet servlet calls request.getSession() the first session is used. Reply 2 (including SESSIONID : SID2) <- Request 4 (including SESSIONID : SID2) > Invoke's servlet servlet calls request.getSession() the second session is used. There are of course different scenario's that can be drawn but is there a way tomcat deals with this problem? According to wikipedia, servers can easily deal with the issue of pipelining but I believe that is not the case when sessions are involved. Is this scenario realistic? Is it possible that two sessions exist where the information in the first session will be lost? I know by default most browsers turn pipelining off because of a lot of proxies and servers not supporting it. Is this one of the reasons? Rgds, Roel Storms
Re: HTTP Pipelining with session management
2015-11-03 13:16 GMT+01:00 Mark Thomas : > On 03/11/2015 11:36, Roel Storms wrote: > > Hello, > > > > > > I was wondering if anything special is done with cookie based session > > management in order for it to deal with HTTP pipelining. > > No. > > > > > There are of course different scenario's that can be drawn but is there a > > way tomcat deals with this problem? > > No. > > > According to wikipedia, servers can > > easily deal with the issue of pipelining but I believe that is not the > case > > when sessions are involved. > > Tomcat supports pipelining but makes no assumptions about sessions. Keep > in mind that a proxy may be pipelining requests from different clients. > > > Is this scenario realistic? > > Yes. > > > Is it possible that two sessions exist where > > the information in the first session will be lost? > > Yes, one of those sessions is going to be lost. > > > I know by default most browsers turn pipelining off because of a lot of > > proxies and servers not supporting it. Is this one of the reasons? > > Supporting pipelining is a spec requirement so I'd be surprised if it > wasn't supported. > I found this for the Chrome project: https://www.chromium.org/developers/design-documents/network-stack/http-pipelining No clue if other support it or not but if chrome an IE don't support I assume there are many others as well. I found that safari has support for pipelining as does Firefox but it's not enabled by default in FF. > > Session handling is certainly one reason not to use pipelining. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
ServletRequest getParameter, getInputStream, getReader
Hello, I am working on a Valve that does some integrity checking on HTTP requests (the details aren't important) where I need this valve to have access to the HTTP request body as well. I used request.getInputStream to fetch the data. However when a web application makes use of my valve, the getParameter method does not return the parameters submitted via POST anymore. This is documented behavior according to the spec of ServletRequest ( https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getInputStream() ). I was wondering why it was designed this way, since numerous complaints have arisen from this behavior and some ugly workarounds have been devised which unfortunately stop working from Tomcat 7 (servlet 3.0): https://stackoverflow.com/questions/10210645/http-servlet-request-lose-params-from-post-body-after-read-it-once This shows how easily code like this could break. Overwriting getInputStream to return a cached version doesn't work anymore since the parameter attribute isn't populated by using getInputStream. How exactly it is populated remains a mystery to me. Any advice on how to solve this properly? Performing an integrity check without getInputStream or getReader but with getParameters, will not work if the data submitted is not in the expected format. Kind regards, Roel Storms
Request
Dear Tomcat Devs, I was wondering why Request is used all over Tomcat as a class and why we didn't abstract a Request interface and implemented a StandardRequest as is done by a lot of other components like Session->StandardSession; Manager->StandardManager; Context->StandardContext; ... Is there any reasoning behind this? Kind regards, Roel Storms
CoyoteAdapter
Hello Tomcat Devs, I am looking at CoyoteAdapter and Request classes in the trunk of Tomcat8: https://svn.apache.org/repos/asf/tomcat/tc8.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java https://svn.apache.org/repos/asf/tomcat/tc8.0.x/trunk/java/org/apache/catalina/connector/Request.java In CoyoteAdapter I notice the usage of methods like B2CConverter getURIConverter(); void addPathParameter(String name, String value) String getPathParameter(String name); However in Request these methods are marked protected. What am I missing here? Kind regards, Roel Storms
Re: Request
Dear Konstantin,
I am indeed talking about org.apache.catalina.connector.Request.
HttpServletRequest is an interface that we expose to Servlets. However
there is no interface that exposes everything necessary for Tomcat to work.
Therefor Tomcat is using the Request class as the type of the
parameter/variable/attribute. At some points attributes are even accessed
directly, not through methods. This makes it kind of tricky when
experimenting with different behavior for Requests. Therefor I was curious
if there was a reason for not using an interface but directly using the
class.
Kind regards,
Roel Storms
2016-01-31 16:28 GMT+01:00 Konstantin Kolinko :
> 2016-01-31 13:30 GMT+03:00 Roel Storms :
> > Dear Tomcat Devs,
> >
> > I was wondering why Request is used all over Tomcat as a class and why we
> > didn't abstract a Request interface and implemented a StandardRequest as
> is
> > done by a lot of other components like Session->StandardSession;
> > Manager->StandardManager; Context->StandardContext; ...
> >
> > Is there any reasoning behind this?
>
> https://en.wikipedia.org/wiki/KISS_principle
>
> Also, there is already an interface
> [[[
> package org.apache.catalina.connector;
> public class Request implements HttpServletRequest
> ]]]
>
> and
> [[[
> package javax.servlet.http;
> public interface HttpServletRequest extends ServletRequest {
> ]]]
>
>
> If we are talking about other class
> [[[
> package org.apache.coyote;
> public final class Request {
> ]]]
>
> It is final and no other implementations are allowed.
>
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
Re: CoyoteAdapter
To much C++ development, got confused about the scope of protected. In C++ this scope is the class and all sub-classes. Not the package. Thanks for refreshing my mind! 2016-01-31 16:14 GMT+01:00 Alexis Hassler : > Hi Roel, > > Both classes are in the same package. That means that they're allowed to > access public+protected+package-private members. > > Alexis > > 2016-01-31 15:34 GMT+01:00 Roel Storms : > > > Hello Tomcat Devs, > > > > I am looking at CoyoteAdapter and Request classes in the trunk of > Tomcat8: > > > > > > > https://svn.apache.org/repos/asf/tomcat/tc8.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java > > > > > https://svn.apache.org/repos/asf/tomcat/tc8.0.x/trunk/java/org/apache/catalina/connector/Request.java > > > > In CoyoteAdapter I notice the usage of methods like > > B2CConverter getURIConverter(); > > void addPathParameter(String name, String value) > > String getPathParameter(String name); > > > > However in Request these methods are marked protected. What am I missing > > here? > > > > Kind regards, > > > > Roel Storms > > >
