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/18 14:21:42 UTC
DO NOT REPLY [Bug 35709] -
allow to create a short-lived secondary session from a request to prevent cross-site scripting-like attacks
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
hauser@acm.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|allow to crate a short-lived|allow to create a short-
|secondary session from a |lived secondary session from
|request to prevent cross- |a request to prevent cross-
|site scripting |site scripting-like attacks
------- Additional Comments From hauser@acm.org 2005-07-18 14:21 -------
cookies might not be a good answer because the adversarial script might be able
to read them too in some browsers.
If one is bound to a scenario where url-rewriting with redirects is the way to
go, I guess a work-around is:
1) when the user clicks on the action starting the html file-download,
commons-http-client gets a new session and retrieves the jsessionid
2) in the application scope, a hash-table is stored where the html file to be
downloaded is stored under the jsessionid as key
3) the browser is then redirected to the new session (thus no more a referrer
with the ongoing session id) - probably in 2 steps first on a landing page in
the new session that then triggers the download-action with yet another redirect
itself.
4) the browser retrieves the file with its temporary jsessionid and referrer
5) once the download is finished, the file is removed from the app-scope
hash-table and the session invalidated
I guess the almost the same would work if the adversarial script were to exploit
the jsessionid's inside cookies. Anyway, being able to obtain a secondary
session Id still appears attractive to me instead of such a "home-made" work-around.
--
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