0

I'm using a form-token to secure the validation process of my php-file.

Basically the structure of the php-file looks like this:

if ($_POST) {//form has been submitted?

    if (validateFormToken) {
        //process form-data
    }

} else {

    //display form and generate token
    include 'includes/forms/form.php';

}

I would like to know if it would be more secure if I split the php-file into two files:

  1. the form itself and
  2. the validation php-file

I just ask because currently I use one file only and this file can be accessed directly. If I use two files (mentioned above) I could prevent direct access of the validation-file via the generated token. But the form-file could still be accessed directly. Is there another way to prevent direct access via .htaccess or some other method I am not aware of?

2

Code is not going to become more secure per se by splitting it differently across files. The important thing is what code is going to be executed when anyone requests a certain URL. Whether this changes because your web server is executing a different file or because you have an if..else statement in one file is entirely irrelevant. Separate files may help code organisation and thereby prevent possible bugs, but it's not more secure per se.

If it's possible to access "include files" which should not generally be executed by themselves, and this allows an attacker to circumvent some protection or another, that's entirely your fault for exposing this executable code publicly in the first place. You must only place "public" code in the public webroot directory. If a visitor is not supposed to go to http://example.com/include/never/execute/this/directly.php, then this URL must prompt a 404 response by the web server instead of making it execute some code. The sane way to do this is to not put the file there in the first place, but outside the webroot:

myapp/
  includes/
    sensitive.php
    ...
webroot/
  contact.php
  index.php
  ...

This can go so far as to only have one index.php in the webroot, using mod_rewrite to direct all requests into it and using a request router to handle requests in PHP.

Your web server is responding to URL requests. This has nothing to do with physical files at all. Always keep that in mind. Which URL request involves which files is completely up to you. The point is which URL will trigger what response; how the files are laid out on the backend is completely irrelevant.

  • What about sessions? I was wondering if I could prevent execution of includes via a session-variable (declared at index.php or at the top of the header)? – drpelz Nov 27 '13 at 19:51
  • No. Code which should not be executed must not be executed by the webserver, period. Put it outside the webroot or convince your webserver to not execute the code by configuration. – deceze Nov 27 '13 at 20:04
  • Ok. I just read some threads about placing it outside the webroot and this is a very good idea to protect ALL includes. After moving all of my includes outside the webroot they are protected. Thanks for this great hint! You saved my day, man!:) BTW: SE and SO are a real gold mine! – drpelz Nov 27 '13 at 20:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.