> From: Dave [mailto:[EMAIL PROTECTED]
> Hi, I am using URL rewriting for session tracking, ie,
> session id is on the URL. After I login into a web
> application, if someone else knows my current session id,
> he/she can access my account using the session id. It is ok
> because it is difficult for others to guess my session id.
... although they can eavesdrop on it with a network sniffer. If you don't
want third parties to be able to sniff your session information, either from
the URL or from the cookies in the headers, then encrypt all traffic between
client and server. In other words, implement SSL.
> But right now I encounter an issue that will breach the security.
>
> Our web application is using a 3rd party payment system,
> when a user clicks pay button, we need to tell the payment
> system a return URL, a page URL to go after a user finishes
> with the payment system. The return url needs to have the
> user's session id so that he/she will not need to login again
> after returning from the payment system. In this case, the
> 3rd payment system will know the user's session id, a security hole.
>
> Is there a solution for this scenario?
Use cookies.
> the same security
> hole for cookie based session tracking?
No. With cookie-based sessions, the cookie is known by the client and the
server, but not sent to the third party, and so it remains unknown by them.
As a side note, if the same user can have multiple sessions, you need to think
about which session you bounce the user back to from the third-party site - the
third-party site will have to have some form of session ID passed to it at this
point, though you might be able to get away with a fragment rather than the
entire ID. The way to fix this problem is to have one session per user.
> In our case, we have
> to use URL rewriting because sometimes a new session is
> needed when users click some links on pages.
Patching a broken design: You could possibly force new sessions when the user
clicks on those links, but use cookies at other times. There was a discussion
about how to do this a couple of months ago on the list. However, this still
isn't secure, as session IDs get appended to some URLs; those URLs can
accidentally be bookmarked or emailed, for example.
Alternatively, fix the design: What feature of your user experience requires a
new session at this point, why, and how can you remove that requirement?
> In my opinion, session id is not sufficient to identify a
> session, it should have client's ip address for more security.
Proxies can break that really thoroughly - AOL's proxy clusters are notorious
for this.
Sessions should be identified by a shared secret. Shared solely between the
user agent and the application server, and secret by being encrypted. Cookies
over SSL meet the "shared secret" test. I hate to say it, but if you're
concerned about security then you should redesign your application until it has
a single session and can therefore use cookies over SSL for sessions. Why do
you need multiple sessions?
- Peter
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
