How to prevent direct access to php file and stop a form reload posting?

[Jmacp]

2 questions here.


1) How do you stop a form from reposting if the page is reloaded,

<form method = "post" action = "doit.php">
<input type = "text" name = "stuff">
<input type = "submit">
</form>

So a user could reload the page and the fields would be posted again, this may result in the php duplicating itself.


2) Similar to the first question and may be he same answer, how do you stop someone directly accessing the php file by navigating to it and hence running it, in this instance the form fields wouldn't be posted to the php file but you could still munipulate the php file either by manually (hacking) putting in query strings or maybe just running the php on its own may result in undesired results.?

I think you can use the

<input type = hidden...

for question one, although i am not sure on this and for questions 2 maybe something to do with the http referrer, but still the http referrer only gives the base domain or something like that, any fullproof methods i can use?

I want to protect any possibilty of for the php file to run apart from when the submit button is pressed and valid data is posted, although the valid data part could be done with javascript..

[kows]

well, your script couldn't be "hacked" using a query string because you're using POST and not GET. the query string doesn't affect POST at all. generally, you don't process any data without first checking if the form has been submitted (shown below by checking the REQUEST_METHOD environment variable. if you do this, you could also make your form and "results" page in the same script. this is something I'd highly recommend, too.

now, to let the user refresh the page or do whatever without having the browser ask them if they want you to resend the data, you could sort of trick them by setting a session with the data that was posted and then redirecting them back to the script (thus getting rid of the actual POST data), and checking if those sessions are set.

I've also included a quick call to parse_url() to make sure that the script is being posted to from our own domain, and if you need to check for "valid data," you can make sure that certain fields were set before redirecting, and even create an errors variable (stored in a session) to deal with that.

<?php
  //start our session
  session_start();

  if($_SERVER['REQUEST_METHOD'] == "POST"){

    //only accept posts from our domain
    if(parse_url($_SERVER['HTTP_REFERER'], PHP_URL_HOST) == "davidmiles.ca"){

      //our new "post" array
      $_SESSION['POST'] = array();
      foreach($_POST as $key => $value){
        $_SESSION['POST'][$key] = $value;
      }

    }

    header("Location: safe_post.php");

  }elseif($_SESSION['POST']){

    //destroy the session for the next visit
    //remember! session_destroy does not immediately destroy the session, but will on a page reload.
    session_destroy();
?>

<h1>posted</h1>
<pre><?php print_r($_SESSION); ?></pre>

<?php }else{ ?>

<h1>form</h1>
<form action="safe_post.php" method="post">
  <input type="text" name="name" value="David" />
  <input type="submit" value="Submit" />
</form>

<?php } ?>

you can see it in action here. after you've submitted the form, hit f5 (or press refresh) and it will reload the page without any prompts, and show you the form again.

hope that's at least related to what you were looking for?

[Jmacp]

That works when i load the php page at first so if i try and reload i am not prompted and also the php doesn't run but, if i modify your code and remove the redirect,

 header("Location: safe_post.php"); 

and post the page to itself so add,

<form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="post">
  <input type="text" name="name" value="David" />
  <input type="submit" value="Submit" />
</form>

which is what i think is the correct way of doing it, then after posting if i try and reload it does prompt again if i want to resend data etc...

Also the html form code is not displayed.

So how do i modify it so that i post the page to itself it still displays the html and doesn't prompt to resend.?

[kows]

uh.. you can't remove the redirect, that's the entire point of the script. the whole reason you're redirecting is because when you send a POST request you're sending data to the server, and so if you refresh the page that data needs to be sent again. I got around this by creating a session when the script was posted to, then redirected back to itself and checked if the session existed in order to know if the form had been submitted from then on. you just need to change it to redirect to itself, by using PHP_SELF if you want. you shouldn't just go removing things without actually knowing what they do :)

if you want to always display the form then you just need to take it out of the IF statement. the script I gave you works like this: if the user has posted, store a session and redirect. if a session exists, print out the session. if the user has not posted and the session doesn't exist, then show the form. you can simply change the script to only check posts/sessions and always display the form instead (get rid of the ELSE).

[Jmacp]

Yup..doh, i got the redirect part just after i posted, so i understand that.


It seems to work ok, thanks for that...

wanted to rate, but i need to "spread the rating around first"

[penagate]

The 'Referer' field can be easily forged, so checking it won't help much. Instead of worrying about where a POST request comes from, I suggest you think about the reason you consider them to be potentially harmful, and fix that instead.

[penagate]

Note: If you follow W3C recommendations religiously, then you should consider using a 303 status code rather than 302 (which is PHP's default when you set a Location header).

303 See Other

The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.

The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

But...

Note: Many pre-HTTP/1.1 user agents do not understand the 303
status. When interoperability with such clients is a concern, the
302 status code may be used instead, since most user agents react
to a 302 response as described here for 303.

[Jmacp]

The 'Referer' field can be easily forged, so checking it won't help much. Instead of worrying about where a POST request comes from, I suggest you think about the reason you consider them to be potentially harmful, and fix that instead.

Here is the scenario.

You create a webpage for a company and also create a CMS for them. A client of the company phone them up and ask them to put their house on the market. The estate agant then logs into the CMS you created and is presented with the options to add some descriptive text and upload some images(of the house) which they do. After they click submit, the CMS appends this new info into/onto the pages html so that a new listing appears on the page. But, the estate agent, for whatever reason, reloads the page, all the form tag fields are reposted and another section is appended onto the page, giving duplicte listings...etc etc.................you see what i am getting at.

[penagate]

Yes, that's why we send a redirection after accepting the POST request. But I was talking about your second question.

[Jmacp]

Yes, that's why we send a redirection after accepting the POST request. But I was talking about your second question.

Oh yeh, was really early in morn when reading that. Basically create a session/cookie and use the username/password as auth?? probably best way i think....i don't know why i didn't think of that before. Not really a php'er.

[penagate]

Web applications require a specific mindset. On the desktop, you know the user just clicked that button to delete all of their valuable documents. On the web, you're not quite sure. Validate every step of the way.

If you authenticate once and use a cookie-based session you are most of the way there. PHP will do a lot of the work for you (creating and saving session data files, creating the session token, and sending the cookie). Make sure you call session_start and do all of your checks before processing any request that has side effects. Then go ahead and delete the user's valuable documents.