|
|
Posted by Jerry Stuckle on 10/12/72 12:00
Sebastian Lisken wrote:
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>> You're correct that SID is not set if the session id was stored in a
>> cookie. However, the question is - why are you even doing this? If
>> properly configured, PHP handles sessions quite well. All you need to
>> do is issue a session_start() at the beginning of each page where you
>> use sessions.
>
> This was in the code I took over, there are numerous examples like
>>> <a href="script.php?<? echo SID; ?>">
>
> The obvious purpose is to pass on the session ID from one page
> to the other. I hadn't done this before so I'm glad you're asking
> about it. I have now read the section "Passing the Session ID" in
> http://www.php.net/manual/en/ref.session.php and it says that the ID is
> passed on transparently if session.use_trans_sid is enabled. I can only
> guess that the code was developed in a context where it wasn't. As it
> turns out, on my WAMP 5 installation it is disabled too. I've enabled
> it, taken away the <? echo SID; ?> part from one of my links, and seen
> the effect of the option. Thanks for educating me there, but with that
> experience I'd say it's good practice not to rely on the option (I don't
> even know what the setting is on the production server that my work will
> be transferred to, but the site has switched servers before so I don't
> want to rely on the setting there anyway).
>
I always rely on it. If your hosting company doesn't support it, get a
new hosting company. It's pretty standard in PHP. Every host I know of
has it enabled.
>> And sure, anything CAN be manipulated - theoretically. But the default
>> PHP session id is a long alphanumeric string. It would be virtually
>> impossible to manipulate it unless you were somewhere in the path
>> between the client and the server. And not even then if it's a secure
>> connection.
>
> If you're bringing in direct manipulation of HTTP packets somewhere
> between the server and client then of course everything is possible (as
> you say, SSL would be the counter-measure of choice but it's not in use
> here). So if we have to go that far to construct an attack on SID then
> it's probably not something I should worry about. Password sniffing would
> be the more likely thing an attacker would do if they could intercept
> HTTP communications at all.
>
> Thanks
>
> Sebastian
>
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|