[PHP] Session_id within URL
Hi, I would like to understand the purpose of placing SESSION_ID within the URL. I suppose it is for security improving... However, how to do it ? i mean how can it be useful ? how can i use it ? thanks a lot, Alain
Re: [PHP] Session_id within URL
session_start(); $s = SID; //get Session ID echo a href=\page.php?$s\Page/a; Mostly for passing the session as a GET variable to another page, like for anything from authentication tokens to form data etc... Of course for form data it would probably be better to encapsulate the session veriables within the form. -B Alain Roger wrote: Hi, I would like to understand the purpose of placing SESSION_ID within the URL. I suppose it is for security improving... However, how to do it ? i mean how can it be useful ? how can i use it ? thanks a lot, Alain -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session_id within URL
On Tue, April 11, 2006 12:40 pm, Alain Roger wrote: I would like to understand the purpose of placing SESSION_ID within the URL. I suppose it is for security improving... However, how to do it ? i mean how can it be useful ? how can i use it ? Actually, unless you are using SSL (https://example.com) then it REDUCES security as somebody *could* intercept the session ID. What it increases is browser-compatibility -- Specifically, it allows browsers and other user agents that do not accept/return cookies to use a session. Some users, such as myself, do not generally allow Cookies unless they want the content bad enough, and trust the site to not be sharing personal/trackable information with other sites. It's a pain in the ass, but it's important to me to not get as much JUNK mail, email, etc and I *KNOW* sites are doing this kind of thing when I use unique email addresses and they cross from one site to the next. E.G., just yesterday the City of Chicago sent spam to a unique email address I gave to PIRG. If your cookies are always on, always accepted, you have to assume that SOME sites are tracking you, sharing the URLs you visit with other sites, and sharing whatever personal info they can find out about you with their partner/affiliate sites, who can then target their advertising (on-line and off-line) at you. They've invariably wrapped this all up in a very long-winded Privacy (sic) Policy which nobody reads anyway. Using Sessions in the URL can be as simple as turning on the options in php.ini, or using .htaccess to turn them on. You could also roll your own to embed the session ID in the URLs you care about, ignoring, for example, images and javascript and CSS, and thus making your site SLIGHTLY less standard and amenable to attack from a shotgun random-selection of victim. Of course, that's off-balanced by your maintainability of the code you have to write/maintain yourself to handle the session ID. It's not a TON of code, for some well-structured applications, so in some cases it's probably worth it There are also some techniques you can take to validate the user with session IDs over non-SSL connections: Alter the session ID on a regular basis, so that old IDs are void Embed a second token in the GET/POST data that also expires Challenge users for passwords before particularly sensitive actions -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session_id within URL
I also use those sessions when checking on the apache logs. For a specific user, so i can trace what he did. On 4/12/06, Richard Lynch [EMAIL PROTECTED] wrote: On Tue, April 11, 2006 12:40 pm, Alain Roger wrote: I would like to understand the purpose of placing SESSION_ID within the URL. I suppose it is for security improving... However, how to do it ? i mean how can it be useful ? how can i use it ? Actually, unless you are using SSL (https://example.com) then it REDUCES security as somebody *could* intercept the session ID. What it increases is browser-compatibility -- Specifically, it allows browsers and other user agents that do not accept/return cookies to use a session. Some users, such as myself, do not generally allow Cookies unless they want the content bad enough, and trust the site to not be sharing personal/trackable information with other sites. It's a pain in the ass, but it's important to me to not get as much JUNK mail, email, etc and I *KNOW* sites are doing this kind of thing when I use unique email addresses and they cross from one site to the next. E.G., just yesterday the City of Chicago sent spam to a unique email address I gave to PIRG. If your cookies are always on, always accepted, you have to assume that SOME sites are tracking you, sharing the URLs you visit with other sites, and sharing whatever personal info they can find out about you with their partner/affiliate sites, who can then target their advertising (on-line and off-line) at you. They've invariably wrapped this all up in a very long-winded Privacy (sic) Policy which nobody reads anyway. Using Sessions in the URL can be as simple as turning on the options in php.ini, or using .htaccess to turn them on. You could also roll your own to embed the session ID in the URLs you care about, ignoring, for example, images and javascript and CSS, and thus making your site SLIGHTLY less standard and amenable to attack from a shotgun random-selection of victim. Of course, that's off-balanced by your maintainability of the code you have to write/maintain yourself to handle the session ID. It's not a TON of code, for some well-structured applications, so in some cases it's probably worth it There are also some techniques you can take to validate the user with session IDs over non-SSL connections: Alter the session ID on a regular basis, so that old IDs are void Embed a second token in the GET/POST data that also expires Challenge users for passwords before particularly sensitive actions -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Louie Miranda ([EMAIL PROTECTED]) http://www.axishift.com //JSM-W
