Jump to content


hijacking of tomcat/struts session via return_url?

  • This topic is locked This topic is locked
No replies to this topic

#1 ralfhauser



  • Members
  • Pip
  • 4 posts

Posted 05 March 2004 - 12:27 AM


When somebody who is logged into my application pays via IPN, I would like that person to get back after the payment without the need to login into my application again.
Therefore my return_url (and possibly also cancel_url) ends with ";jsession=2345ade324".
This unfortunately has the effect that everybody seeing this URL can jump into that session as long as it is alive. Even if the connection to paypal is protected via https, at least they could hijack the session!
The best approach probably would be to tie the tomcat session with the SSL session ID upon login since every new browser will negotiate a new session with my server. If that SSL-session is not the same as the one before my user left my application to pay with paypal, then it is probably time to ask for a re-login.
Does anybody reading this forum have any experience which browser handles such SSL sessions how (what is the timeout, will a second window of the same browser exe instance share the SSL sessions?).
Unfortunately, accessing such an SSL session ID is hard when using tomcat's own SSL (pls see and vote/comment http://nagoya.apache...ug.cgi?id=22679). When tomcat runs behind apache httpd with mod_jk, getting that inside struts may be even harder.
A second best approach might be to remember the origin IP upon login in the struts session until the user returns after paypal, but this has the disadvantage that some users are behind gateways and thus they may share a single IP address towards my application and secondly, quite some ISPs frequently change the user's IP such that sessions may get invalidated by this mechanism before the real timeout.

Any thoughts? Pls let me know to hauser@acm.org

(P.S.: just to register with this forum, to bad, I had to downgrade my zonealarm cookie setting... :( )

Reach me securely via:

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users