mezzoblue: SHA-1 and DB Integrity

By Justin Perkins, at 18:00:48 on 2005-04-27.

2005-04-27T18:00:48-08:00

I have no idea why that comment turned out so weird looking, I certainly didn't type it that way. If only you had editable comments :)

By Ben O'Neill, at 08:37:29 on 2005-04-29.

2005-04-29T08:37:29-08:00

I've come across problems similar to this before. The argument of storing the hash in the table or calculating it each time keeps cropping up, but most of the time I can rely on the fact I know approximately how many people will be using the application at one time so I know that the server can cope (closed systems).

I can't see a way of getting around either storing the hash or calculating it each time and I'd strongly recommend against PHP's built-in session management, I can't see how this would solve the problem either as it would just shift the data to the servers hard drive instead of the database.

By David Barrett, at 10:19:54 on 2005-04-29.

2005-04-29T10:19:54-08:00

It's better to use built-in routines than writing your own. Much as I dislike PHP as a language, there's no point in reinventing the wheel.

If PHP sessions offer you everything you need, you should use that instead of coming up with your own way of doings things, because chances are you'll do a worse job than the language developers.

By eijikel, at 14:08:59 on 2005-04-29.

2005-04-29T14:08:59-08:00

Dave,
I'm more into server side dev than client side (and that's the reason why I read your blog, to improve my poor skills). What I can tell you is that your app, as you described it above, is highly unsecure. As it was stated above, if I can guess the name of one of your users, it's easy to calculate a few hashes for this name (md5 and sha1 being the most popular) and use the result in the query string.

If people are going to manipulate personal data, you don't have many options: you'll end up with an auth system based on session and/or cookie management.

Here is an excellent link to get the basic idea of such an auth system (you will need to understand the basic of OOP though):
http://www.sitepoint.com/article/anthology-2-1-access-control

I highly recommend the reading of the two volumes of the PHP anthology to anyone willing to improve his/her skills.

George Shlossnagle, in his book "Advanced PHP Programming", has also some excellent thoughts on authentication (even though it's more complicated to understand, as the title let you guess).

If you don't feel like reinventing the wheel, PEAR has some already built auth system that are excellent (even though installing PEAR can be a pain in the neck).

Good luck Dave.

-Alex

By Jblanch, at 19:02:05 on 2005-05-01.

2005-05-01T19:02:05-08:00

This method of not logging in leaves you with no choice other then for the client to either have a completely random hash stored and given to them secretly, or just using a password for their link. If you give them a password feild then they can do requestId=mypassword , because if sombody is trying to get data from a certain person, i'm sure it woulden't be hard to find things like street addresses, and it would be very easy to just use their name, chances are they already know it.

By flump, at 15:23:55 on 2005-05-02.

2005-05-02T15:23:55-08:00

someone said that PHP automatically escapes $_GET and $_POST, this is only true if magic_quotes_runtime is set to 1.

that's like saying php is immune to SQL injection, which is certanly isn't. simply escaping certain characters isn't going to stop SQL injection.

By Amit Lamba, at 17:01:26 on 2005-05-02.

2005-05-02T17:01:26-08:00

From my understanding, some of the best practices, in no particular order, used to prevent SQL Injection are:

(a) Type-caste input variables
(b) Use regex to filter data
(c) Single-quote all variables in sql statements
(d) Escape quotes using mysql_real_escape_string (php version > 4.3) for input strings
e) Best to turn off all 3 magic_quotes settings in php.ini or at runtime since quotes are not the only thing coders should be escaping
(f) Log anything out of the ordinary

None of these steps by themselves can prevent SQL Injection. By this method, you can avoid using addslashes and stripslashes since they are not as robust as the alternatives. If I've missed anything or need to be corrected, feel free to correct or update this.

By Amit Lamba, at 17:05:48 on 2005-05-02.

2005-05-02T17:05:48-08:00

Sorry, "type-caste"ing is available to Untouchables as well.

*correction: type-cast input variables

By Vincent Grouls, at 01:00:19 on 2005-05-05.

2005-05-05T01:00:19-08:00

I couldn't post this normally so I put it up on my server.

http://vincentg.sytes.net/misc/mezzoblue.com%20-%20SHA-1%20and%20DB%20integrity.txt

By Lauri Jutila, at 05:27:11 on 2005-05-11.

2005-05-11T05:27:11-08:00

PHP Security Consortium has put together a great read about PHP security. You can find it here:

http://phpsec.org/projects/guide/