Page 4 - [Everyone] Must read Security Notes

Yes Jeff, we can see the stars

Jeff, now I see how you got 700+ posts
thx for *bump* though, or I would've missed it. Now I have something to do for the next couple hours....

I believe I have only done 3 or 4 bumps total since I joined this forum...

I figured everyone needed to see this again.
I was going to publish it as an article here at devshed but I contacted them again and got no response. So people need to at least see the thread.

I think you should rewrite this part so that you clearly say how sessions can be safer and how there's no need to revalidate all the time using session, since you can store whether the user is admin or user or God in a session variable. Sessions and cookies go hand in hand, so this may scare peopel into thinking they have to query the DB every time a user loads up a restricted page with sessions controlling access, which is a total waste of resources.

I've thought about that. When I wrote that I was only targeting people who did not use sessions..

But remember sessions aren't as 'magical' as people think. They aren't stored in RAM. They must still be loaded up from the hard drive and unserialized. In my experience, MySQL has been so fast that if you compare 10000 queries versus 10000 fopen()+unserialize() calls, MySQL can match or even beat the speed of the latter in many cases. Iused to think that querying the database is automatically a bad and slow process. I thought that until I tried to beat the database by caching things to the HD and unserializing the data. It didn't work. MySQL is unbelievably fast.

I'll rewrite that now.

That's true, I was tinkering with the idea of experimenting with sessions stored in shared memory, but never got around to actually testing it...

However, session are so nice and easy to use, that I won't use anything else unless I really have to. It would be interesing to do a speed comparison of a MySQL based session managment system and a standard file based though.

Yeah.. that would be interesting. I'm thinking of writing a small MySQL based session library since I like to keep things PHP3 compatible and can't use PHP4's session handing routines, and I don't like to mess with file permissions.

It really depends on how much stuff you put in a session though. For a lot of data a MySQL based session handler may be faster. But in the validation example, if the users table is large or validation requires joins or anything and you are only storing a few things in the session, then sessions are probably going to be faster in that case. If you're going to use sessions, user validation over and over probably isn't very efficient but that doesn't necessarily mean the only option is to use disk based sessions.. MySQL based sessions could be fast too.

I think that mysql is going to be quicker in most cases.
If you have a big user table, then the chances are that there are a fair few users using the system at once. Thus using sessions a lot of session files to slow things down, and a greater load on disc access. A (properly indexed) mysql database which will probably be cached in memory will repond very fast. Also, checking the data each time may not be slow, because the chances are that the person last used the system a matter of minutes, or normally seconds ago, and hence is even more likely to be cached. Asides from login, non-permanent data can be stored in memory reisdent (heap?) tables which are very fast!

In defence of sessions they are plenty fast enough for most big applications i've seen (eg web based mail systems), and normally will represent a small part of the processing time of a page. Also, if the disc access time is becoming a problem, then why not put the session files on a ramdisk?

Great post Jeff. I'm thinking you have probably saved lives here.

Here is a tutorial which shows how to build a MySQL session handler: http://www.phpbuilder.com/columns/ying20000602.php3

An additional note: if you can keep your main session var small enough so that the serialized string is never more than 255 characters long CHAR(255), then you can make your table a HEAP table, by creating it with the "TYPE=HEAP" syntax. This means your table will load into RAM, and run much faster than a regular table. HEAP tables cannot contain TEXT or BLOB column types, unfortunately, so you are stuck with CHAR(255) as your biggest column.

Also, I suppose you could get daring and mount your MySQL data directory as a RAM partition, but be careful: you are playing with fire.

If you are sticking with file-based sessions, don't think you can do such Linux tweaks as mounting the partition with "noatime", because the session mechanism needs to know tha last access time of every session file. It performs a STAT() on every file every time, which is why many file-based sessions can be expensive. You can help this out by putting sessions on a RAM partition, but the STAT() will still have to be performed.

Using shared memory, though, as andnaess mentions, will probably bring your biggest performance gain. Actually, if you compile PHP with the --with-mm option, then you can simply specify mm as your session handler and sessions are automatically stored in shared memory.

Yes, great reading

I think this topic would be a good forum by itself - but I noticed there's already a not-mutch-used Security forum already.

Many of the problems Jeff pointed out are actually instances of generic issues that not only affect PHP, but other languages as well. As such, maybe the best forum for problem discussion is Security, and in turn the forum for solution implementation should be different for each language/platform. (I wonder what the moderators/admins have to say about this?)

If you liked Jeffct's post, I think you should also review securereality's A Study in Scarlet , a paper that adresses more or less the same issues in a quite professional way (Though its slightly more difficult to understand, beware newbies)

Also you should check out The World Wide Web Security FAQ , from the W3

I wonder if the PHP coders around here actually check the 'Security' forum? Maybe its too much fuzz?

Anyway, im posting a new thread on PHP forum about a security issue I would like get some feedback (Though i should maybe post it on 'Security'? This is getting me dizzy

Great work Jeff - the more ppl get acquainted with security the better.

.pd

Another thing I have seen is to set 2+ cookies and/or sessionID. This way you can use the cookie data to query a database to see if they are valid users before giving them access to certain pages.

Yes, and all the user has to do to become registered is change the cookie variable, very secure indeed!

For this sort of thing, all you need is sessions, it's much better and safer. The idea of storing the password as a cookie variable is horrible, and you have to recheck the user every time he accesses a page, when a session will do. Why do that?