>>> Hai Ram <[EMAIL PROTECTED]> 18-Jan-01 8:56:33 AM >>> >why dont u use hidden variables in forms. u can pass >the session id in all forms. when the user logs out u >can invalidte the session. You can do that with URL re-writing as well of course. In fact using hidden fields is almost exactly the same as URL re-writing. They're identical in terms of security weaknesses. >>for mainting the session throught the project I >>already asked which is we can't use cookiee & >>session because both are storing in browser >>cookiee when browser cookiee option disabled I don't really understand what you're saying. Are you saying that cookies can be disabled so they're not a usefull means for session carrying? If so that's true to an extent. But cookies are becomming more and more reliable because less and less people are concerned about them (which was the main reason people turned them off apparently). The only other way to carry session data is through an SSL socket using SSL's implicit session handling. To my knowledge there isn't a single servlet container that actually supports this. There are some issues with using SSL (I can't remember them - check the advanced-servlets list archive). Coming back to URL re-writing it's really quite a safe way to do things except for 3 things: 1. the session id is exposed on the wire in the response and request But so it is with cookies. 2. the session id is visible in the URL "window" in browsers Which is only a problem if the user's are located where physical peeking by attackers is a real threat (ie: user's are mainly in the workplace) 3. the session-id can be "captured" This happened to me recently on a mail project I work on. I was dumb to overlook it. Here's what happened: - the app shows mails - it uses sessions to keep track of stuff - the mail display page is loaded using session re-writing - the mail display allows inline HTML If the mail content includes an HREF to some other site the other site can capture the session-id of anyone clicking on the link in the content page. This is possible because browsers send information called: the REFERRER to a link target which indicates the page the user was on before the current one. Thus all an attacker had to do was read the REFERRER variable from any request he recieved from a link within a mail. Getting round the problem isn't hard but it's a bit of a pain. We simply parse the content and replace dangerous HTML tags with links to a servlet that causes a redirect and then performs the action. That way the attacker gets a REFERRER pointing to the redirected location which doesn't include the session id. Of course this problem can only occur when your application has some way for attackers to introduce a link for the user to follow. That is not normal application behaviour (remember the scenario I describe is with a webmail system). Nic Ferrier ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
