DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=35709>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35709 Summary: allow to crate a short-lived secondary session from a request to prevent cross-site scripting Product: Tomcat 5 Version: Nightly Build Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Connector:Coyote AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] org.apache.catalina.connector.Request.doGetSession(boolean create) only will create a new session if there is no existing one. Goal: ----- This would be used in the following way to prevent a cross-site scripting attack if a user doesn't allow for cookies and thus uses URL-rewriting with the jsessionid. Problem description: -------------------- Often web-apps deliver html files entered by one user to a receiving user via the HttpServletResponse object. When the receiver then views the received file, the browser still has the jsession ID in the referrer field. A script could use this to transfer that jsessionid to another server to hijack that session before expiration. Apparently the referring URL will be presented to a remote (attacking) server for example when the receiver's browser loads images asked for by the html file from that remote server. Solution idea: -------------- 1) obtain a secondary session without invalidating the current one to which the receiving user is logged in 2) put the html file to be downloaded into that new session redirect the file-download to another (struts-) action with that temporary session id 3) deliver the html file to the receiving user with the response of the short-lived secondary session 4) upon closing the response's outputstream, immediately invalidate that temporary session Preliminary assessment: ---------------------- ===> i) by the time a remote server receives the temporary jsessionid, it is normally already invalidated ii) if the html-file is already rendered by the receiver's browser before fully being downloaded, a remote attacker might see the jsessionid before it is invalidated. However, since there was no real login into that session, it will not have any privileges and contents beyond the very html file the attacker originally put into circulation -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
