It is true that PHP has had a number of vulnerabilities, but so has other languages, and as for perl, security has never been a fundamental part of the language ;-)

How secure/insecure PHP is compared to other languages I don't know, and I'm not even sure if that is the most important issue here.

One way of securing yourself is making sure that you have the latest version of PHP, or whatever language you prefer, installed. No matter what language you use, there is always a good chance that sooner or later someone will find a new vulnerability.
A good idea is to sign up for the bugtraq mailinglist, for info on the latest vulnerabilities:
http://online.securityfocus.com/cgi-bin/sfonline/subscribe.pl

As for the man in the middle attack, you can make sure that the session id is impossible to guess. NEVER use incrementing numbering for session ID's. As far as I know it is always possible to hijack a session unless you use SSL.

The perhaps most important things to do, regardless of language, is validating the input data. Make sure nobody can input data that may be harmfull in any way. One thing that many seems to forget, is that it is possible to input data even if the user isn't supposed to do any input.
Just concider someone changing the URL whenever variables are passed using GET.

For those interested in security in building web applications there is an interesting ongoing project called "OWASP Guide to Building Secure Web Applications and Web Services". They've written a guide full of good advice for webdevelopers, pdf can be downloaded from their site:
http://www.owasp.org/guide/

Originally posted by bcyde
Regarding incremental session IDs, are you speaking of when generating your own session IDs via session_id() or are you speaking of a setting within PHP that generates incremental session IDs automatically when you call session_start()?


I was thinking more of a case where it for some reason could be useful to create your own set of session identifiers.

A nice way to create a session id is first seeding the random number generator:

srand((double)microtime()*1000000);

Then generate a unique id:

md5(uniqid(rand()));

Originally posted by bcyde
...
2)use $_SESSION[] instead of session_register
3)In PHP 4.3 or newer use session.use_only_cookies to true if you don't want to use sessions through URLs (although this will reduce functionality for people who don't/can't use cookies)
...


Could you please describe more in details as for PHP Security Question newbie what these two rules are and why better keep to them?

aZa

2)use $_SESSION[] instead of session_register
----------------------
Well basically this is something I learned the hard way a while back from the kind folks in #php on irc :). At the time I was asking about $_SESSION[] vs usage of session_register() and basically got just use $_SESSION[] without a real explanation. After a while I realized that it was just better coding practice because:
a)It can remove reliance on register globals and removes possible confusion that may occur with variable scope
b)Since $_SESSION[] is a super global its value is available from within functions without having to extract it

This basically says it all this was taken straight from the PHP manual at php.net for session_register

If you want your script to work regardless of register_globals, you need to use the $_SESSION array. All $_SESSION entries are automatically registered. If your script uses session_register(), it will not work in environments where register_globals is disabled.

3)In PHP 4.3 or newer use session.use_only_cookies to true if you don't want to use sessions through URLs (although this will reduce functionality for people who don't/can't use cookies)
----------------------
In PHP 4.3 this setting was introduced and if you're sure your website visitors allow cookies then this would be a little more secure because the user's session ID won't get embedded within the URL by accident making it readily visible and easily accessible for copying. Still, using cookies won't protect you from a packet sniffer/man in the middle unless you're also doing things over SSL. If you're not sure that cookies are enabled this setting will interfere with your session capabilities though.

Hope this helps clarify things.

-b

Tried searching for "$_SESSION" in PHP manual (pdf-version) and didn't find any mention of it. Any clue? :rolleyes: Could you give me some more detailed description where to look for it?

Regarding use_only_cookies: that's why I'm actually using sessions (because some of the users forbid cookies)! If you don't want to use pure sessions than there is no need at all to implement them and you can easily do the same thing through cookies (in my case that was authetification process on the site).

I can only see this function useful in case when you are using some standard scripts and without getting much deep in to the code you wish to make them use only cookies for passing variables. This way you just put that function at the top of the main script pages. But if you program from "clean sheet" you can use cookies from the very beginning without even touching sessions ... Just my 2 cents. Or did I not understand something important again? ;)

Hi in regards to $_SESSION check out http://www.php.net/manual/en/function.session-register.php and read the caution portions.

As far as cookies/sessions I'm not exactly sure what you mean by using either one or the other. When you use sessions the session ID must be passed to the server and is either passed along through the URL, form variable or by a cookie. Are you saying that you use sessions specifically by sending the session IDs through the URLs or hidden form vars?

Thanks for the link! I seem to have a bit out-of-date manual I guess which doesn't have 'sessions' part at all. that's why I couldn't find mentioning of "_SESSION" in the document.

Truly saying currently I use my hosting provider's default settings for passing session variables (through URL). :D I didn't quite understand the purpose of function use_only_cookies ... I thought that it simply sends all your session variables information using cookies, not only session's ID ... This way it seems to be much more secure than sending through URL and makes sense, I would even say big sense! Will surely redo my scripts with that setting turned ON.