Re: Hiding variables passed via URL

On Jul 14, 3:47 pm, The Natural Philosopher <a...@xxx> wrote:
Michael Fesser wrote:
.oO(The Natural Philosopher)

I have no trouble understanding cookies and sessions.

Its jerry's assumptions that I didn't know that irritate.

All that is needed t preserve states across a session is to have some
unique session ID. That has to be carried by a cookie or by a URL .

After that, you can associate any amount of crap with that session ID.

I simply didn't see any difference in principle between carrying the
session ID as a URL than as a cookie.

There are a dozen ways for a URL to leak (the HTTP_REFERER is just one
way), which would easily allow other sites to grab valid session IDs.
Such attacks were done some years ago against a number of big free mail
services, which led to thousands of stolen accounts.

Session cookies are much more secure, because you actually have to sniff
the HTTP communication between the clients and the server or use XSS to
grab them.

Which I pointed out. Jerry then said 'what's cookies got to do with it'
so I explained what they had to do with it.

But they don't have anything to do with the OPs problem, which was about
passing data from one page to another. POST won't work here, GET is not
wanted, so the only viable alternative is a session. Question answered.

No the only viable way is a cookie. Whether or not that is used with PHP
sessions or not, is actually not the point. They are no more secure than
simply setting a number in your own custom cookie.

All PHP sessions are area wasy of pasing a unique ID using cookies, and
a handy interface fr dummies, but they still use either the URL or the
cookie to pass that one vital bit of info.

Now I also thought that the point was that the user was worried about
his clients seeing the info in the URL and messing with it.

My point was that they could as easily mess with the cookies.

I don't recall any issues about security with respect to third parties
at all, which makes your point another straw man.



Micha- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

Okay, I'm beginning to see why some other group members are rather
frustrated with Natural Philosopher.

Using sessions only stores the ID associated with the user on the
client machine. That ID is linked to the client's data which is stored
on a file on the server the client is communicating with. Cookies
actually store all the data on the client machine. That means that
when you use cookies, all the data is available for the client to view
and edit. Using sessions seperates the client from his or her data,
thus making it uneditable; the only thing that can be edited on the
client is the session ID, which isn't very useful, since at best you
associate yourself with someone else's data, and at worse, you divorce
the client from its session data. Therefore, using sessions is more
secure because the client cannot directly access his or her data.

How did this even become a security discussion????
.

Relevant Pages

  • Re: Do IIS applications "go to sleep"?
    ... client side. ... This type of cookie is not disabled when one disables client ... using these session items. ... need your timer when you extend a session timeout to five days. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Do some operation just before sending response header
    ... If I want to change PHP session mechanism to store session data into ... you are allowing the client unrestricted access to modify the ... creating a cookie first) but it's a really bad idea to push the ... is it possible to hook before sending response header? ...
    (comp.lang.php)
  • RE: Wont save session object
    ... client machine's cookie setting. ... the ASP.NET's session is by default associated with all the client ... something incorrect with the client's cookie setting. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: WebService session sessionstate SOAP
    ... InfoPath as a client doesn't respect the session cookie. ...
    (microsoft.public.dotnet.framework.aspnet.webservices)
  • Re: WebService session sessionstate SOAP
    ... InfoPath as a client doesn't respect the session cookie. ...
    (microsoft.public.dotnet.framework.webservices)