On 12/01/2016 15:57, Thomas Scheffler wrote: > What I read in the specification is that a *fix* could be implemented > that would a allow the bug to disappear. The third point above, changing > the sessionId only if the user is "new" to the session, would fix the > problem, could be integrated easily and would help me and possibly > others. Does it open a new security risk? No.
I'm not (yet) convinced that that is the case. I'd need to think through the various corner cases. But, as explained below, even if there were no additional security risks, I remain unconvinced about this approach. > You are right. Again there is nothing that prevents you to help to fix > that issue, neither spec nor anything. Yes there is. Read section 13.10 of the servlet spec. I was looking for something else but found section 13.10 and it is explicit that the behaviour you are asking for is not specification compliant. On top of that, the issue can't be fully fixed. And if it can't be fully fixed then all a partial fix would do is make the issue more difficult to reproduce and harder to track down. Even with the fix above, it doesn't solve the following (more involved than my previous example) race condition: UA sends sends request1 on connection 1 Request1 creates session1 with sessionid1 Request1 returns response1 to the UA UA sends request2 with sessionid1 on connection1 UA sends request3 with sessionid1 on connection2 request2 uses session1 reuqest2 returns response2 to the UA request3 authenticates and sessionid1 changes to sessionid1001 UA sends request4 with sessionid1 on connection1 request fails because sessionid1 no longer exists Fundamentally, if you want to use Tomcat's session fixation protection then you have to ensure that authentication can not happen concurrently with any request for the same session. Similar issues will occur if you have two parallel requests that both create a session. > You don't see the frustration you brought to me but you could read it. I > am sorry for that. In a world of asynchronous request handling and > protocol upgrading you are forcing users to deliver responses > sequentially. Sorry. This is so disappointing. There is no way around the fact the a request that does any of the following (and probably other actions as well) can not be concurrent with any other request from the same user else something is likely to break: - create a session - authenticate the user if session fixation protection is enabled Once you have done those things, you can use all the concurrency you like. > The spec just states that the user information on the request does not > change if one does not call login(), logout() or authenticate(). It says > nothing on the initial state, neither. But when I call authenticate() on > a request and used login() on an other request object, why can't > authenticate() not use that credentials? Why does the user have to > re-login again (basic auth)? See reference to servlet 13.10 above. > You are right. But I have no code to alter the session handling. It is a > standard webpage with restricted information that refers to restricted > images on the same fast server. A rather simple use case. I use the > login() method that was introduced in Servlet 3. There is no standard > conform way to have login() work for me. I cannot modify the browser to > load the images one by one. I could do by using JavaScript to load the > images and waiting for each response. Is that what you are suggesting? I don't know how your application is written so I can't give you specific advice. What I can say is any web application has to conform to the constraints I explained above else it will likely break. > It is just like a homepage that give a tiny information, who is logged > in. And depending on the user returns some information not readable by > "guests". No way to force a user to enter his credentials. You can visit > twitter without being asked for your login. You decide when you log in > and you never loose a session. One URL returns different results > depending on the user being logged in. Because Twitter is careful not to do parallel requests that might require authentication. > Of cause, if I require authentication, I can force Tomcat to not use > BasicAuthentication but FormAuthentication. That isn't going to solve the parallel request problem. > But during the page > generation I used the login() method to get the user information and > check for roles. Where is the user information coming from? > The page is delivered to the user At this point the UA should have the new session ID since it is after authentication takes place. > referencing thumbnails that are itself protected OK. So requests to those should use the new session ID which should pick up the authenticated user. > and lack of authenticate() to work as expected, The key question is why are these failing. > calling login() with the same credentials all over again > for every thumbnail. That's causing all the trouble. Those requests are going to be concurrent, so yes authenticating here is likely to break stuff. The point is, if authentication took place for the referencing page, it shouldn't be necessary again here. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
