You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2005/07/12 22:43:43 UTC
DO NOT REPLY [Bug 35709] New: -
allow to crate a short-lived secondary session from a request to prevent cross-site scripting
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: hauser@acm.org
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org