Is it common to use session.use_trans_sid?

[listerofsmeg01]

Hi all,

Constructing my first web app, and wanted to enable
session.use_trans_sid so that people without cookies could still use my
site.

After braving a nightmare of set_ini(), and .htaccess to try (without
joy) to turn it on, I find when searching for help that the vast
majority of people are trying to turn it OFF.

Now I know there are potential security risks with people mailing or
posting links with session ID's embedded, but surely support is still
needed for non cookie people?

Is it common practice now to only support cookies? Do people roll their
own non-cookie support somehow instead?

Many thanks

[petersprc]

Hi,

Many session-based sites require cookies. But use_trans_sid would be
the way to go if you want to support cookie-less sessions.

[e-mail] wrote:

Hi all,

Constructing my first web app, and wanted to enable
session.use_trans_sid so that people without cookies could still use my
site.

After braving a nightmare of set_ini(), and .htaccess to try (without
joy) to turn it on, I find when searching for help that the vast
majority of people are trying to turn it OFF.

Now I know there are potential security risks with people mailing or
posting links with session ID's embedded, but surely support is still
needed for non cookie people?

Is it common practice now to only support cookies? Do people roll their
own non-cookie support somehow instead?

Many thanks

[lorento]

li************@hotmail.com wrote:

Is it common practice now to only support cookies? Do people roll their
own non-cookie support somehow instead?

Its depend on your application. If you build a secure application you
must target a cookies support browser. Btw almost of browsers now
support cookies, even the text based browser like lynx.

--
http://www.mastervb.net
http://www.theukmap.com

[Erwin Moller]

li************@hotmail.com wrote:

Hi all,

Constructing my first web app, and wanted to enable
session.use_trans_sid so that people without cookies could still use my
site.

After braving a nightmare of set_ini(), and .htaccess to try (without
joy) to turn it on, I find when searching for help that the vast
majority of people are trying to turn it OFF.

Now I know there are potential security risks with people mailing or
posting links with session ID's embedded, but surely support is still
needed for non cookie people?

Is it common practice now to only support cookies? Do people roll their
own non-cookie support somehow instead?

Many thanks

Hi,

In my humble opinion both URL-rewriting or cookiebased transport of the
PHPSESSID are unsafe (without encryption).
Why?
1) url rewriting: If somebody decides to send an url to somebody that
contains a sessionid, why care? They might as well send the original
username/password to enter that site to their friend.

2) cookie: Anybody that can tab into the IP-packages that go from a to b,
can also see the cookie, just as the url.

So url rewriting doesn't give less or more security than cookie based
PHPSESSID transport...

There are two possible extra things to pay attention to:
a) On shared hosting environments, on most setups, anybody with access on
that server can read the the filenames and content of cookies belonging to
other sites. So if somebody on the same server want to be a bad guy, they
can just steal sessions.
(This is not the case on all setups, if every site on the shared hosting
server has its own storageplace with good file/dir permissions, this "hack"
won't work).

b) With PHPSESSID passed through url, anybody with access to the logfiles of
the server can see the full urls. This won't happen with cookies (since
they are not stored in the logs AFAIK).

The best way to go is to use encrypted transport (https/ssl) if safety is a
concern.

So my advise would be to just use session.use_trans_sid to support cookie
disabled browsers while not giving away security (since the security is low
already).

just my 2 cent.

Regards,
Erwin Moller

[Chung Leong]

Erwin Moller wrote:

So url rewriting doesn't give less or more security than cookie based
PHPSESSID transport...

I think you forgot about the HTTP Referer header. If your site have any
external links--or worse, links to external images--then the session ID
is easily compromised if it sits in the URL.

There are two possible extra things to pay attention to:
a) On shared hosting environments, on most setups, anybody with access on
that server can read the the filenames and content of cookies belonging to
other sites. So if somebody on the same server want to be a bad guy, they
can just steal sessions.

Just the contents of the session file, not the cookie.

So my advise would be to just use session.use_trans_sid to support cookie
disabled browsers while not giving away security (since the security is low
already).

trans_sid doesn't work very well, especially when your site makes use
of Javascript. My advise is to turn it off, since using the feature
means doubling your QA time. Someone savvy enough to disable cookie is
probably savvy enough to make an exception for your site.

[Erwin Moller]

Chung Leong wrote:

Erwin Moller wrote:

>So url rewriting doesn't give less or more security than cookie based
PHPSESSID transport...

I think you forgot about the HTTP Referer header. If your site have any
external links--or worse, links to external images--then the session ID
is easily compromised if it sits in the URL.

Yes, add that the the list of possible problems. :-)

>

>There are two possible extra things to pay attention to:
a) On shared hosting environments, on most setups, anybody with access on
that server can read the the filenames and content of cookies belonging
to other sites. So if somebody on the same server want to be a bad guy,
they can just steal sessions.

Just the contents of the session file, not the cookie.

The name of the file reflects the sessionid.
So both are comprimised...

>

>So my advise would be to just use session.use_trans_sid to support cookie
disabled browsers while not giving away security (since the security is
low already).

trans_sid doesn't work very well, especially when your site makes use
of Javascript. My advise is to turn it off, since using the feature
means doubling your QA time. Someone savvy enough to disable cookie is
probably savvy enough to make an exception for your site.

I don't get that Cheong, what goes excactly wrong with JS in combination
with trans_sid? I use btoh a lot, so I am curious what you mean.

Regards,
Erwin Moller

[Chung Leong]

Erwin Moller wrote:

The name of the file reflects the sessionid.
So both are comprimised...

But if there are other variables in the cookies, they won't be
compromised. That's the point I was getting at.

I don't get that Cheong, what goes excactly wrong with JS in combination
with trans_sid? I use btoh a lot, so I am curious what you mean.

Let me clarify. I mean when you have URLs generated through Javascript,
then these won't be transparently handled.

[Erwin Moller]

Chung Leong wrote:

Erwin Moller wrote:

>The name of the file reflects the sessionid.
So both are comprimised...

But if there are other variables in the cookies, they won't be
compromised. That's the point I was getting at.

Allright. Agreed. :-)

>

>I don't get that Cheong, what goes excactly wrong with JS in combination
with trans_sid? I use btoh a lot, so I am curious what you mean.

Let me clarify. I mean when you have URLs generated through Javascript,
then these won't be transparently handled.

True. But you can of course add them yourself in your script.
But yes, it is a little bit more work.
But the advantage is that people without cookies can still use your
(JS-enabled) webpages.

And sorry I misspelled your name Chung. :-)

Regards,
Erwin Moller