开发者

Prevent off site form posts?

I'm looking for the safest way to not allow my web form, which uses PHP and MySQL, to be posted to from off site. I've done some searching and found that most people suggest setting a hidden field in the form and a session variable with a md5() hash value and check for it on form submission. But that doesn't seem very secure because the md5() hash value can be seen in the source of the form in the hidden value.

Here is my idea to not allow off site form submissions. It's a bit more resource intense with the database calls but looks to be more secure because the code hash is never sent to the client side.

Please take a look at it and see if you can poke any holes in this security measure to prevent off site form posts.

// First time form loads
if (!$_POST) {

    session_start();

    $code_options = array('A','B','C','D','E','F','G','H','I','J','K','L','M','N','P','Q','R','S','T','U','V','W','X','Y','Z','1','2','3','4','5','6','7','8','9');
    for ($i=1; $i<=20; $i++) {
        $code .= array_rand(array_flip($code_options), 1);
    }

    // Insert new record
    $con = connect_to_db(); // connects to db
    $sql = "INSERT INTO security_table (form_code) values('$code')";
    $result = run_query($sql, $con); // runs the query

    $_SESSION['formcode'] = $code;
    $_SESSION['formid'] = mysql_insert_id();

}

// If form was posted to    
if ($_POST) {

    session_start();

    $con = connect_to_db();
    $form_code = mysql_real_escape_string($_SESSION['formcode']);
    $form_id = mysql_real_escape_string($_SESSION['formid']);

    $sql = "SELECT form_code FROM security_table WHERE form_code = '$form_code' AND form_id = '$form_id '";
    $result = run_query($sql, $c开发者_运维百科on);

    if (mysql_num_rows($result) > 0) {

        // Process the form

        // If form processes successfully
        $_SESSION['formcode'] = "";
        $_SESSION['formid'] = "";

    }else{

        // Error

    }

}


Instead of doing this in your application, you could control access to your site though your web server configuration. Nice separation of concerns if you can do it this way -- the server deals with requests and the application only deals with the logic.

Assuming you're using Apache and you have read/write access to your apache http.conf or a local .htaccess, you can add a rule like this:

<Limit GET POST>
  order deny,allow
  deny from all
  allow from 199.166.210.
  allow from .golden.net
  allow from proxy.aol.com
  allow from fish.wiretap.net
</Limit>

So, deny everyone, except for the few IP or network addresses you chose to allow.

See the Apache docs for the nitty gritty details.


But that doesn't seem very secure because the md5() hash value can be seen in the source of the form in the hidden value.

It doesn't matter. If you encrypt it well enough, the token will be greek to anyone, and therefore impossible to recreate unless you know the key mechanism in the php script. Since you regenerate the token after each post, seeing what it looks like won't help any bad guy.

Your way of securing your form is basically "if you have the session, you're fine". So if the spamming machine has visited your page once, the security layer has been passed. The reason for why you have a client side token is that the spammer has to provide something that only is attainable in your actual form.

There are lots of discussions about secure forms at stackoverflow, have a look at Good Form Security - no CAPTCHA, for example.


Here's a good article explaining different methods of securing a form. I've used these methods with good results. http://www.campaignmonitor.com/blog/post/3817/stopping-spambots-with-two-simple-captcha-alternatives

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜