Mark Fuller wrote: >>>> o Add the session id to the URL. This method has the most problems, and >>>> is not recommended. >>> What are the problems with the last option? ... >> Google for XSS - Cross-site scripting attacks, as a starter. > > I thought the problem with putting the session ID in the URL is that > the user might copy/paste the URL to others. When they try to use it, > the app would have no way to know it's not the real user?
While that is a problem (it holds true with any user identifiable information not just sessions. You need to especially watch what you put into emails since they will get forwarded) it's not XSS. XSS is Cross Site Scripting. So you need 2 domains (hence the cross-site) and it involves Javascript (can also be ActionScript/Flash, VBScript, or any other future client-side scripting language). Basically it's problem of people embedding Javascript into a page that others will see. That Javascript can steal sessions, etc from the user who sees it. It doesn't matter if the session id is in the URL or a cookie, Javascript can see both. This is why escaping any data that could potentially come from a user is so important. <tmpl_var foo escape=html> or [% foo | html %] -- Michael Peters Developer Plus Three, LP ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################