Not some code, but concepts...

suntra

Hi everyone...

I'm thinking more and more of a Web site developing (two p's ?) which would make security a priority...

So first of all, let's start with login/sessions

There would be...
-> One table containing user data;
-> One table containing session data.

When loging in, the would be a check on the email address and the password... if successful, then a new session would be created...
There would of course be the session id (integer), the current time, user's id (already "MD5-ed" with session id), user's IP, user's browser... a MD5 string would be generated from all those variables and sent to the customer, but wouldn't be stored in the databse. So when calling another page, the session ID is sent to PHP, then PHP makes a MySQL query (SELECT FROM sessions WHERE MD5(Session_ID . '' . User_id . '' .......) = Session_ID_Sent_by_User) (some MySQL vars, some PHP vars...) If the user changes IP or browser, he/she has to log in again... also, session_id would be the same if the time between two request is less than 5 minutes, otherwise the row is deleted and a new one is set with a "fresh" session id... (some cron job would also * delete all expired session...)

Now, forms... I'm getting sick of always writting form validation code, so I'm going to make a class that helps me do that... Every form will be set in a table in MySQL, the form name, some variables like minimum time, maximum time, ... Then every field will be set (name, type, min length, max length, content type, input type, etc.)... the form will point to a non-existing page (a md5 string followed by ".frm") that will be "caught" by Apache with mod_rewrite which will call a PHP script (let's say form_handling.php) that is located in a "access-forbidden" directory.. (have to check if that can cause error... I think so, but at worst, the file will be located in a strange folder)... Also, for every form call, there will be data set in MySQL : the original field id, a totally unique random generated key, the parent form, etc. So when submitting the form, the "non-existing" page gets the ID with the address... it then checks in the DB if a form has been defined with that ID, if yes, it gets all the fields and starts checking if set, if min length, max length, ..., are respected. If everything is ok, it would "finally" return true, otherwise, it returns false...

There would also be a template system which will look at the URL, check in the DB for an associated row which contains a "parent id"... then all templated (general templates, not specific templates) containing that parent id are returned. The "html contents" is contained in the DB, and the "php contents" in a folder with a strange name... the PHP is called first, it defines variables and other stuff, then the contents is parsed. That is done for every templates. At the end, depending on the parent template, all sub-templates are included where they have to go...

So my form handling class would use that template class to draw the form...

So what do you think ?

Am I parano ? Will there be way too many MySQL queries ? (I'm thinking of using caching, just need to have a brilliant idea...) Will the speed be dramatically diminished ? Any other comments ?

Thanks !

MarkR

suntra wrote:
If the user changes IP or browser, he/she has to log in again...

This is going to deny service to many users, who have a multihomed or dynamic proxy server. This includes many AOL users.

Now, forms... I'm getting sick of always writting form validation code, so I'm going to make a class that helps me do that...

Seems reasonable.

Every form will be set in a table in MySQL, the form name, some variables like minimum time, maximum time, ... Then every field will be set (name, type, min length, max length, content type, input type, etc.)...

Storing stuff which doesn't need to be changed at runtime in the database is VERY bad for maintenance- it's never user-modified, but you're making it harder to deploy new software revisions.

Prefer to store those kinds of data in a file which is static (unchanging) at runtime and maintained exclusively by the developer, and deployed with everything else instead.

the form will point to a non-existing page (a md5 string followed by ".frm") that will be "caught" by Apache with mod_rewrite which will call a PHP script (let's say form_handling.php) that is located in a "access-forbidden" directory..

This sounds needlessly complicated and I can't see how it's going to increase anything's security anyway.

Generally speaking, using mod_rewrite should not be your first choice. Use it only for legacy stuff or complicated stuff for which there is a real business requirement.

Also, for every form call, there will be data set in MySQL : the original field id, a totally unique random generated key, the parent form, etc. So when submitting the form, the "non-existing" page gets the ID with the address... it then checks in the DB if a form has been defined with that ID, if yes, it gets all the fields and starts checking if set, if min length, max length, ..., are respected. If everything is ok, it would "finally" return true, otherwise, it returns false...

I'm not sure if I understood that, however, is it try to prevent CSRF? That is done more easily. Just generate a random cookie and put that in a hidden field in the form and compare them- this ensures that the form must have originated on your own site not someone else's (Third party sites can't set cookies for your site)

There would also be a template system which will look at the URL, check in the DB for an associated row which contains a "parent id"...
then all templated (general templates, not specific templates) containing that parent id are returned. The "html contents" is contained in the DB, and the "php contents" in a folder with a strange name... the PHP is called first, it defines variables and other stuff, then the contents is parsed. That is done for every templates. At the end, depending on the parent template, all sub-templates are included where they have to go...

Sounds like you're trying to design an entry for an obfuscated programming competition. Are you sure all this is strictly necessary? What attacks are you hoping to defend against.

You have to remember to trade off increased security against maintainability. An unmaintainable application is not useful.

Am I parano ?

Not necessarily. You've not stated which specific attacks you're trying to defend against though; much of the above is somewhat obfuscated and serves no apparent purpose.

Will there be way too many MySQL queries ?

I don't know. But it sounds like a maintenance nightmare.

I think you should REALLY try to avoid storing constant (non-changing) data in the database and prefer to hard-code it. This makes deployment easier (fewer SQL scripts to run, less chance of a deployment screw up).

Code and data should be separate- and constant values (including structures e.g. form validation data) I consider to be part of your CODE not your DATA.

Mark