ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
AFAIK, PHP *relies* on being able to write cookies in order to *implement* "sessions", doesn't it? Once you create a session, aren't you implicitly using cookies anyway , whether or not you explicitly read or write cookies in your own PHP code?
I know that. But there are cookie functions which allow me to set cookies explicitly.
Sessions work even if cookies are disabled, but uses the query string in the browser to keep track of the session vars. I read somewhere that this may be a security risk, but I cannot seem to find it.
Anyway, most users have cookies enabled. Which way would create portable and secure code?
The security problem with encoding stuff in the URL is two-fold:
1. It's easily read (even more easily than the stuff in forms you'd have
to "view source" to see), revealing (possibly unwanted) details about
your web application's internals
2. It lends itself to cross-site scripting attacks (people can cut/paste
from the URL to manually access different parts of the web app, perhaps
subverting it).
I know that. But there are cookie functions which allow me to set cookies explicitly.
Sessions work even if cookies are disabled, but uses the query string in the browser to keep track of the session vars. I read somewhere that this may be a security risk, but I cannot seem to find it.
Anyway, most users have cookies enabled. Which way would create portable and secure code?
yes sessions will work without using cookies. the way i have sessions setup on my server i use mm to manage the sessions. this way they are never written to disk, even on the server. there is no use of any cookies at all..
sure there are some security concerns, but imo they are *at worst* balanced with cookies. the technique i use to preserve the session id is to pass the id using GET.. the requested page then checks the session id with a database that contains active sessions that allows only one session per userid.. the system checks the request against the current session, referrer url, ip address, and i had implemented a timestamp but threw it out due to being a bit of an overkill for my purposes. if anything does not match the user info in the db, the session is erased and the user is forced to login again.
while it may be possible to hijack a session using this method, it is extremely unlikely.
if you would want anymore info feel free.. i worked a while on this system and built it from scratch.. so i feel like i have a pretty good understanding of any security concerns with it..
2. Here's a bit more on the "session hijacking" Xhi mentions:
Quote:
URL based session management has additional security risks compared to cookie based session management. Users may send a URL that contains an active session ID to their friends by email or users may save a URL that contains a session ID to their bookmarks and access your site with the same session ID always, for example.
3. PHP "global variables" is another potential security risk. Newer
versions of PHP all default to "register_globals = false" (in php.ini):
Quote:
If register_globals is disabled, only members of the global associative array $_SESSION can be registered as session variables. The restored session variables will only be available in the array $_SESSION.
Use of $_SESSION (or $HTTP_SESSION_VARS with PHP 4.0.6 or less) is recommended for improved security and code readability. With $_SESSION, there is no need to use the session_register(), session_unregister(), session_is_registered() functions. Session variables are accessible like any other variables.
4. To the extent you're using PHP "out of the box" (it sounds like Xhi has
done considerable work on his own infrastructure), cookies are arguably
the best, easiest, most reliable way to go.
1. "mm" is completely a server-side thing. It has nothing directly to do with the "cookies vs URL" issue we were discussing:
true.. but i felt it is good information to throw in there if OP is going to be searching on how to setup a server to support sessions without cookies.. since it is one of only three ways to implement sessions tracking.. (there are only 3 that i know of anyhow)
Quote:
to the extent you're using PHP "out of the box" (it sounds like Xhi has done considerable work on his own infrastructure), cookies are arguably the best, easiest, most reliable way to go.
im not sure about most reliable, but cookies are definately the easiest way to go.. yes it was considerably more work.. if you choose the path i did, you can rest assured you will spend a few extra hours fine tuning php, as well as a database to track the sessions.. the verdict is still not in on my system as far as reliability under load goes..
good description on the session hijacking.. that is why i would recommend doing checks on ip address and referrer url along with the session id.. and of course you are correct on the global variables.. they should *never* be enabled..
my only reasons for using cookieless sessions were that i just do not like using cookies and wanted to see if i could implement a fully functional site without cookies.. i did and so i ran with it..
I am creating a script where I cannot predict how the server set up will be like since I'll release it to the public.
My script is a simple CMS system (GPL license) with a small number of features to build a website. Actually I think at present I'll stick to the session management that is built in to PHP.
When I complete my script, I would be glad if experts could take the code, see what security flaws exist and so on.
I'm doing all the basic security things like converting form data into correct data type and converting to mysql query safe strings and such. I am also writing the code to be entire using $_SESSION vars and checking if they are set and so on.
That's what Open Source is for, isn't it? Learning something new all the time.
Last edited by vharishankar; 03-04-2006 at 11:06 PM.
one thing i had done was everytime a user is registered they have a unique hash entered in a userhash db.. you could store a hash of a hash, or hash of part of a hash, etc in the cookie and test against the admin hashes in the db..
I'm also using JavaScript to MD5 encrypt the password before it's submitted. Since this is a single user application (CMS with one user only) is that a good idea? Anyway, I guess most people have JavaScript enabled. Otherwise the password will not work.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.