Click to See Complete Forum and Search --> : session alternatives


youssefe2k
05-19-2004, 01:00 PM
hi all,

is there an alternative solution to sessions using php? i dont think sessions are that secure even with ip checking. i want to do it without cookies if possible .... is there a way to create a physical connection with the user? something like an ftp login or something.

thanx

bwkaz
05-19-2004, 06:48 PM
Not with HTTP, there isn't.

One of HTTP's biggest strengths is that it's stateless -- there is absolutely no state maintained between requests.

sharth
05-19-2004, 07:13 PM
you could probably pull something off with post and get variables, but that would probably be even more insecure, and pointless.


I'd go with sessions... I dunno of anything else.

youssefe2k
05-19-2004, 08:45 PM
really? well my univeristy has a site that works without cookies ... the page extensions are .wb any ideas

bwkaz
05-19-2004, 10:34 PM
You don't need cookies for a site. You need cookies to implement any kind of state preservation, though -- like sessions. If your university's web site does not need to keep state across requests (most sites actually don't), then it won't use cookies. What is its address, BTW?

There are alternatives to cookies (hidden <input> tags are what ASP.Net likes to use, for example), but they all depend on the client to some extent, because the server doesn't know anything about who the client is, or when they're coming back, or anything like that. The client has to keep track of the state. Of course, hidden <input> tags are just as easy as cookies to spoof.

youssefe2k
05-19-2004, 11:46 PM
ok .... how do u keep track of which user is logged in without cookies? i dont think the site is asp not sure ... the web site pages are $$$.wb what is that? hidden input is abit better can any script use that or is it only asp?

youssefe2k
05-20-2004, 12:39 AM
ps how do u prevent the hidden's input from appearing in the page's source code?

sharth
05-20-2004, 06:47 AM
Originally posted by youssefe2k
ps how do u prevent the hidden's input from appearing in the page's source code? you can't. thats what I was referring to above, and it really isin't any more secure. If i have read correctly, sessions were craeted as an alternative to this method.

:edit: well... actually. you can. but the only other place (that i know of) that you could place the variables would be in the address of the page itself. ie... example.com/index.html?variable=data

The file extension also doesn't say as much as the mime-type of the page would...

Post the webpage?

youssefe2k
05-20-2004, 01:29 PM
oh ok so the only way is sessions ... well i do have the session id in the url if the usr does not support cookies i think its setup automatically in the php.ini file ... which web page do you want? the university site is www.rosi.utoronto.ca

youssefe2k
05-20-2004, 01:32 PM
i just realized the site uses hidden input types ... i think im going to do it that way but encryt it first .... im not passing in valubale information just the session id ....

youssefe2k
05-20-2004, 01:43 PM
ps is there a way to disable cookies and url ?PHPSESS=ddd using functions?

sharth
05-20-2004, 01:52 PM
as the web page creator...

for cookies, just never ask for any, or create any.

for the session vars (in the web address), just never request their use..


as the user..

some browsers will allow you to disable cookies.

just delete the vars from the web page's address.

youssefe2k
05-20-2004, 06:24 PM
well i mean as a webpage creater but there is a problem when u do session_start() it automatically sets cookie and if cookies are disabled it will add session vars actually one var which holds the name of the session id ...

bwkaz
05-20-2004, 07:09 PM
What do you have against cookies, that you want to use a hidden input field?

I'll say this again, in case you missed it the first time: Using a hidden input tag is LESS secure than using a cookie, not more...

youssefe2k
05-20-2004, 08:44 PM
yeah but ie needs a privacy policy in order to allow cookies ... and for what im doing hidden input is better since the information u can see is not important and you cannot change the value but in a cookie u can copy the cookie file and so long as one user is logged another can log in as well ... the security issue is not what the user can see but what he can do with it...

bwkaz
05-20-2004, 09:30 PM
Originally posted by youssefe2k
yeah but ie needs a privacy policy in order to allow cookies No it doesn't, at least not on any version of IE I've ever used... where did you hear (or see) that?

hidden input is better since <...> you cannot change the value Um, yes, a user can actually change the value of a hidden input field. The simplest way is to use telnet to access your site, but I'm sure there's a browser somewhere that doesn't respect the "type=hidden" attribute.

The input field's value is sent in the HTTP POST along with the rest of the data (and the cookie name and value are sent in the headers of the exact same request) -- if the user can change the cookie, they can change the input field. If all else fails, the user can use a piece of Javascript code that they have written to use the DOM to access and change the value of the hidden field on page load.

but in a cookie u can copy the cookie file and so long as one user is logged another can log in as well I don't understand what you're saying here... can you reword it maybe? How does this make a cookie undesirable? Are you saying that another user can copy the cookie file and therefore get access to the session of the logged-on user? If so, that's a hole with input fields too -- the attacker can sniff the entire HTTP session, and intercept any part of it. ARP poisoning is one way, and operating a router between your server and the user is another way.

If you want your scheme to be secure against any of this, you NEED to use some kind of encryption, for the entire connection. That way, the attacker can't even tell what URL is being accessed, let alone the value of any input fields or cookies being sent.

And if you don't trust the disk that the cookie gets written to, make it a cookie with an immediate expiration (or whatever causes the browser to expire it as soon as the user closes the window). And educate your users to log out when they're done, so that nobody else can steal a cookie that may be written to disk even though you've made it a session-only cookie.

the security issue is not what the user can see but what he can do with it... Anything that can be done with a cookie (from the user side) can be done with an input field. Using telnet and speaking HTTP "manually" is the easiest way for me, but if you don't think your users can do that, I'd behave as if somebody, somewhere, has created a browser that will do it for them -- because somebody, somewhere, may very well have.

youssefe2k
05-20-2004, 10:05 PM
hahah uve made ur point.

What i wanted to put in the cookie or input field is the session id. When a person logs in a session file is created and i can find it using the session id. So if i login and save the session id in the cookie and give that cookie to you and you visit my site then the site will think your logged in as me since ur cookie has the same session id as mine. But if i use this input field:
<input type="hidden" value="id" name="name" readonly>
then the user can't(i think) or atleast have a hardER time changing the input field.

Another thing is that i already have cookies enabled on the site and ie does not accept them and gives me this error: "could not find site's privacy policy"

i would like to use cookies and i can use a usrs ip to make sure that one person is connected at a time but there is still the privacy policy thing

any suggestions?

bwkaz
05-20-2004, 11:01 PM
Originally posted by youssefe2k
Another thing is that i already have cookies enabled on the site and ie does not accept them and gives me this error: "could not find site's privacy policy" Have whoever is doing the testing turn off whatever it is that got installed to make IE do that. I've never seen anything like that in any version of IE I've ever used (4.0 through 6.0 SP1, inclusive). At least, not standard.

But there are popup blockers for it (that generally do a horrific job, but that's beside the point), so it wouldn't surprise me if somebody wrote an add-in that blocks cookies unless it can find a privacy policy.

Or, maybe have whoever this is look around in their advanced settings. Buried in that tree somewhere, there might be a relevant option (if I remember, I'll look at work tomorrow, to see if I can find anything in IE6 SP1's advanced dialog).

youssefe2k
05-21-2004, 12:17 AM
this is all of ie6 any one who has tested my site find the same problem. there is an option in ie to allow all cookies through but its not the default and usually no one changes it