Ensure _POST vars originate from mydomain

DeadlySin3

Hey guys - i'm looking for a good, tried and true method to be pretty well positive that the form submitted, was submitted on my site and not spoofed elsewhere.

Currently, I have a small chunk of code that i'm using but i'm not certain it's going to work

<?php
# Testing referrer for server name
$server_name = $_SERVER['SERVER_NAME'];
$referer     = $_SERVER['HTTP_REFERER'];
             if(stristr($referer, $server_name) === FALSE) {
                $continue = "0";
             } 
                else { 
                       $continue = "1";
               // check data type, length, sanitize, etc
               }

I was doing some reading about this and searched a few forums but haven't really found a solid fix. I'm under the impression there is a method of generating a server-side token that can be checked on the form action side. Someone point me in the direction of a good tutorial? So far my google searches have been relatively fruitless. I'm not interested in the google+ api

How do YOU ensure your forms are posted from your domain?

NogDog

The problem I see is that HTTP_REFERER is not a required header that browsers must send, and even if the user's browser does send it, if they go through a proxy server, it's possible (I have no idea how probable) that it could get stripped out there, as well. Thus you risk losing valid users in your effort to (presumably) stop bots and such.

For that matter, a smart enough bot would send the referer header, anyway.

dalecosp

I'm not positive, so check, but the preferred way to do this (perhaps The Right Way(tm)) is to generate a unique token inside the form which is transmitted to the handler script and decoded before the $_POST array is read....

bradgrafelman

dalecosp's method is certainly one way to prevent the usual script kiddie hit-and-run approach. It's not bulletproof by any means, though.

I personally wrote a PHP script recently that interfaces with a Laravel site that uses authentication. It was actually a breeze to use cURL to start a "COOKIEJAR" (basically allow both session and persistent cookies to work), grab the login page, steal the csrf_token hidden field value, submit the form, grab a page displayed only to authenticated users, and submit a secondary form.

None of this was designed to be malicious (quite the opposite - was actually using it to automate a sort of test procedure)... though it certainly could have been. The "TL;DR" is that I would argue there isn't a good way to ensure that a POST request originated as a result of a form submission in a web browser that just rendered an HTML page exactly as you had intended. Pretty much the only thing you can do with some degree of reliability is to ensure that a human was involved in the loop, i.e. by adding a CAPTCHA to the form.

DeadlySin3

Thanks for the replies! I've been reading deeper into this and playing around with the concept for a bit and came up with something - not bulletproof or tried & true for that matter, but it appears to do the trick.

<?php session_start();
$self    =$_SERVER['PHP_SELF'];
$salt    = "buttery";
?>

<?php if(!isset($_POST['submit'])) {
$token   = sha1(mt_rand(1,1000000) . $salt);
$_SESSION['token'] = $token;
 ?>
<form accept-charset="ISO-8859-1, UTF-8" method="post" action="<?php echo "$self"; ?>">
<input type="text" name="name" value="">
<input type="hidden" name="token" value="<?php echo "$token"; ?>">
<p><button type="submit" name="submit">submit</button></p>
</form>

<?php
}
if(isset($_POST['submit'])) { # form submitted

if (!isset($_POST['token']) || 
    !isset($_SESSION['token']) || 
     empty($_POST['token']) || 
     $_POST['token'] !== $_SESSION['token']) {
           die('Bad Token');
}            

           else {
           $name = filter_input(INPUT_POST, 'name', FILTER_SANITIZE_STRING);
           unset($_SESSION['token']);
           echo "$name";
           }
}

?>

It's probably better if you randomly create the "salt" on the fly - but as a general example the above should work. This token is built by choosing a pseudo-random number between 1 and 1,000,000 that is concatenated to the $salt. Then we encrypt as an sha1() hash. Maybe not the best way, but it's a good starter anyway.

The form processor ensures that the values are not empty and are actually set then compares the values of the token, to the sessions value as well as what the _POST value is - to be sure they match. If the tokens do not match, the script is halted as we don't want to trust the input since it likely didn't originate from your page.

I really hope this solution helps someone else as much as i think it'll help me. If you can see some areas of improvement - by all means, point them out. Thanks!

DeadlySin3

bradgrafelman;11041399 wrote:
dalecosp's method is certainly one way to prevent the usual script kiddie hit-and-run approach. It's not bulletproof by any means, though.

I personally wrote a PHP script recently that interfaces with a Laravel site that uses authentication. It was actually a breeze to use cURL to start a "COOKIEJAR" (basically allow both session and persistent cookies to work), grab the login page, steal the csrf_token hidden field value, submit the form, grab a page displayed only to authenticated users, and submit a secondary form.

None of this was designed to be malicious (quite the opposite - was actually using it to automate a sort of test procedure)... though it certainly could have been. The "TL;DR" is that I would argue there isn't a good way to ensure that a POST request originated as a result of a form submission in a web browser that just rendered an HTML page exactly as you had intended. Pretty much the only thing you can do with some degree of reliability is to ensure that a human was involved in the loop, i.e. by adding a CAPTCHA to the form.

My line of thinking is I don't want to use a captcha. They can be kind of annoying lol. I'm designing a "Free Code Portal" CMS and really the idea behind my initial post is just to make sure that the CMS login form is being used on the site it's installed on and not being spoofed. That and for the main admin area, one who is logged in can post articles, events or add new code to the portals code gallery. I want to be (absolutely) sure that the form is being posted locally - the idea is a new concept (to me, as i've been out of the coding game for a few years now) and it's something i'm just testing and toying around with. As you mentioned, someone with a bit of know-how and isn't afraid of hacking up a bit of code could probably do the same thing you did to the idea i posted above.

Right now - it's really just for the pleasure of saying I did what I set out to do. 🙂

laserlight

bradgrafelman wrote:
dalecosp's method is certainly one way to prevent the usual script kiddie hit-and-run approach. It's not bulletproof by any means, though.

I personally wrote a PHP script recently that interfaces with a Laravel site that uses authentication. It was actually a breeze to use cURL to start a "COOKIEJAR" (basically allow both session and persistent cookies to work), grab the login page, steal the csrf_token hidden field value, submit the form, grab a page displayed only to authenticated users, and submit a secondary form.

I note that this would not have worked if bradgrafelman was trying to spoof the form on behalf of another user that he could not authenticate as, i.e., to actually make a cross site request forgery attack, rather than attempt to spoof the form on behalf of himself, but with a "form" under his own control (arguably still a "cross site request forgery", but not the kind of attack that the term normally refers to). This is because the token "stolen" would not have been the one provided to the other user that he could not authenticate as.

Besides, with the advent of developer tools like Firebug, someone who wants to mess around with your form can do so in-place and submit it on your website. So, if your desire "to be pretty well positive that the form submitted, was submitted on my site and not spoofed elsewhere" if because say, you don't want the user to mess around with your form, then you're probably asking the wrong question. If your desire is to prevent CSRF attacks of the usual variety, then dalecosp's suggested method, if implemented correctly, is bulletproof for this specific purpose.

DeadlySin3

laserlight;11041405 wrote:
I note that this would not have worked if bradgrafelman was trying to spoof the form on behalf of another user that he could not authenticate as, i.e., to actually make a cross site request forgery attack, rather than attempt to spoof the form on behalf of himself, but with a "form" under his own control (arguably still a "cross site request forgery", but not the kind of attack that the term normally refers to). This is because the token "stolen" would not have been the one provided to the other user that he could not authenticate as.

Besides, with the advent of developer tools like Firebug, someone who wants to mess around with your form can do so in-place and submit it on your website. So, if your desire "to be pretty well positive that the form submitted, was submitted on my site and not spoofed elsewhere" if because say, you don't want the user to mess around with your form, then you're probably asking the wrong question. If your desire is to prevent CSRF attacks of the usual variety, then dalecosp's suggested method, if implemented correctly, is bulletproof for this specific purpose.

dalecosp;11041397 wrote:
I'm not positive, so check, but the preferred way to do this (perhaps The Right Way(tm)) is to generate a unique token inside the form which is transmitted to the handler script and decoded before the $_POST array is read....

I really appreciate your reply. I'm glad to learn more about the subject of Cross Site Request Forgery Attacks. I'm interested to learn whats really different from what dalecosp had mentioned vs what I had posted.
The above code does generate a token within the form and is passes along to the handler via SESSION & POST vars, it's then checked for a value (not blank, empty etc) then matched - IE POST['token'] == SESSION['token'] and in that event, the session var is unset and the script is allowed to continue. In the event they do not match, the script dies.

From what i'm reading (i just woke up, forgive me if i'm wrong) dalecosps idea sounds almost identical to what I posted. I'm open to any scrutiny you can provide to the code and how I can make it better!