Being a novice with PHP, I may not be taking the correct route with forms but this way works for me, up to a point. Below is an example of my setup/
I have a form at www.foo.com/add.php, which needs an admin to be logged in to the session. The form inserts data into a database. Once it is submitted, the actions is set to action="scripts/add.php" and then that is redirected using a PHP header function to www.foo.com/done.php.
What I want to know is, can you deny access to the script file directly, e.g. if you go to the script file in a web browser it could enter an empty row into the database or possibly cause some other security issues?
If the form is submitted using POST method (with attribute method="post" in <form>), you can still execute your script only on POST requests, by adding this at the top:
if ($_SERVER['REQUEST_METHOD'] != 'POST') {
exit;
}
There are a few options available to you:
Validate the form post data before inserting into the database
Include a nonce or other generated value that is only present in the form prior to submission
The problem you're trying to solve really sounds like you want to prohibit blank records from being inserted into the database- not necessarily that you want to prevent access to add.php. This is where option #1 comes into play.
In your current add.php, it sounds like there needs to be some input validation. Basically, you'd check the values that are received by the script to make sure they exist. For example, if add.php accepts a first name, as part of a phonebook app, you'd have code similar to the below:
$firstName = '';
if(isset($_GET['firstName']))
$firstName = $isset($_GET['firstName']);
// ...
if(trim($firstName) == '')
//do something to handle an error, either set an error flag or die() with an appropriate message
This is a basic example of input validation, PHP has a validation library you may want to become familiar with: http://www.php.net/manual/en/intro.filter.php
With this input validation in place, someone can navigate to add.php and should receive an error. It will also detect if someone submits a blank form as well.
#2 requires that your form receive a unique value when it's generated called a nonce. The nonce is a unique value that's specific to that instance of the form. The subsequent call to add.php will only accept the request if the nonce is valid. An approach might be to store the nonce in the user's session.
Another note outside the scope of the question, since you're inserting data into a database, you should make sure you have proper escaping of inserted data. If you're using MySQL, see here: http://www.php.net/manual/en/mysqli.real-escape-string.php. If using another database engine, you'll want to lookup the specific library to see how to escape the string.
Yuu can try this to check whether request send by post or not
if(isset($_POST)){
continue.......
}
in order to secure such pages i have applied the code below.
Except request method, it also checks that the request comes only from specific domain.
$live_site_regex = '/http:\/\/(w{3}|w*).?yourdomain.ext/';
if($_POST && preg_match($live_site_regex,$_SERVER['HTTP_REFERER']) == 1){
//everything is ok
}
Related
Guys I have an ISSUE..
I've Created 2 PHP files..
CreateAdmin.php ----------> Has a Form to Fill
Save.php ----------------> Called through jquery Ajax to insert in database.
the codes are working fine. but the problem is i can directly access Save.php file.. when i access each of access an empty row is created in database admin table.
how to prevent it.
actually I've got an idea. when ajax called a session variable should create. the top of the Save.php there should be code if there is not a session variable page should redirect..
is it possible.. if it's okay will it affect the accessing speed.
I would implement some fundamental concepts here. I try to describe them here as simple as possible:
1) In your GET request (calling your CreateAdmin.php) start a session (if not already done) and create a random string that you store to your session:
$_SESSION["token"] = sha256(uniqid(mt_rand(), true));
2) Add the token to your form as a hidden field
<input type="hidden" name="token" value="<?php echo $_SESSION["token"]; ?>">
3) Now do a http POST request with jQuery Ajax call (should not be a GET request). Important include your hidden token from the form. You could also include a special value in your JS that indicate that this is coming form a Ajax call, but this dose not make your Save.php more secure (see below).
4) In you Save.php check first if the call is a POST request, if not do not continue. Than check if the hidden token is included and matching the value in the session (you have to start it), if not do not continue.
if (!isset($_POST['token']) || $_POST['token'] != $_SESSION['token']) die('invalid');
5) If both checks pass you can continue to do your DB stuff but first I would do some additional checks about your data quality that means if the rest of the input is valid e.g.:
Field is not empty if required or the field values has a minimum or maximum length or check if only allow characters included, etc.
6) In all cases I would delete the token from your session.
Generate a new one for the next request if required.
You maybe also want to limit the time how long a token is valid, or check if the user from this session has the right to do this action.
There will be no speed issue with this. There are more things that could be considered but this should be the minimum.
For example you ask that this request should be only possible by Ajax. To be honest I would not take to much effort to check this. You could try to check if the "HTTP_X_REQUESTED_WITH" with "XmlHttpRequest" was included, but this dose not give you much more security. You can simulate a Ajax/POST request very easy in any modern Bowser with the Developer Tools. But with the described method it is not enough just putting the path to your Save.php file in the Browser.
Is there a way to ensure the $_POST data my code received came from my form and not an outside influence. Basically I don't want someone to be able to spoof a $_POST to a universally available page such as account creation. The account creation page is accessible by any user, but I want to ensure only the data submitted by my account_creation form is what gets processed.
The only thing I could think of was initiating a $_SESSION, and then supplying the session_id to the form using a hidden input. Upon $_POST the value of the hidden input would then be matched against the current session_id.
If there is a better method to achieve this result? If there is I look forward to hearing it.
You cannot ensure that data came from a form. A POST request is just a POST request, it can be generated in any number of ways. An HTML form is just one of those ways that's very user friendly. Your server needs to validate whether the data received via the POST request is valid or not and whether to act on it or not.
Having said that, there are things that can help you to restrict and validate the data that is being submitted. First of all, require that a user is logged in using (session) cookies. That eliminates random requests by anonymous users. Secondly, you can embed a token as a hidden field into the form which you also save into the user's session. The POST request needs to contain that token in order to be valid. The token is simply a pseudo-random string.
You can enhance this by preparing a hash of the form fields that you expect the user to submit. If the form value should be read-only, you can include the value into the hash as well. E.g.:
$rand = md5(mt_rand());
$hash = sha1('lastname:firstname:email:' . $rand);
$_SESSION['rand'] = $rand;
$_SESSION['hash'] = $hash;
// on form submit:
$keys = array_keys($_POST);
$checkHash = sha1(join(':', $keys) . ':' . $_SESSION['rand']);
if ($checkHash != $_SESSION['hash']) {
die('Form submission failed token validation');
}
That's just a quick example, you'll probably want to sort the keys alphabetically to make sure you'll get the same hash etc. It demonstrates the concept of the user needing to have a unique token for each request though which prevents tempering with forms and submitting more or less data than wanted.
This still does not mean that a user actually used your form to submit the data though.
$ref = $_SERVER['HTTP_REFERER'];
if($ref !== 'some site path/index.php')
{
die("Access Denied!");
}
This should prevent most people from posting data to your database from an outside influence.
Slightly better is to add additional validation such as user_agent, user_ip and some other $_SERVER vars - those are the two I use.
So, create the unique ID (or Session ID) as you describe, but add a little extra validation that the agent and ip also match. Not fool proof, but adds another little layer of security.
Edit: I should add that you don't send the user agent back; keep that server side and silently validate against the returned session id.
Also, if a submission fails validation, never reveal that back to the user as to why - that way a cheat doesn't know how your tracking them. You can also add "5 invalids and you're out" tracking, but you need to sort of login for that.
Using the session ID is certainly one way of doing it. But there are other options most (if not all) of which involve adding some data as a hidden field.
Use a CAPCHA. That will always be unique to each page load and therefore make it mandatory to use your form.
Generate random data and store it in the DB (or just the $_SESSION variable) and check it once the form is submitted.
Option one is the one I recommend for a user creation form as it pulls double duty. It stops automated submission of your own form, while ensuring that the $_POST data is coming from your own form.
This is a standard pattern pattern to prevent XSRF. Essentially it is the similar to what you mentioned. Server creates a random token when form is rendered for the user. It is tied to a browser cookie for the user. On form submission it is posted back to the server. Server then compares the token with what was issued and form action is performed only after a successful match.
There's a lot of good mentions of putting a unique value in the form and matching to the stored value in the server side session. Do that, but also think about what happens when a user uses the back button and possibly tries to submit the form twice, or they open a second browser window(same session!), or they use multiple forms on your site.
Don't create crazy bugs by not thinking your system through.
I have been googling a lot but i am still without an answer so i decided to ask this question here:
Is there a way in PHP how to check that the data i am receiving in some script are from the specific form on the page? I am asking because everyone can see the name of the script i am using for saving the data to my database, so if somebody is able to find out the whole URL, he is also able to send some fake data to the script and i need a condition, that the saving process is triggered only when the data comes from the proper form on my page.
I am using jQuery to call AJAX function, so basically if i click on the button "send", the $.POST() method is triggered to call the script for saving the data.
Thanks,
Tomas
Use tokens to check if request is valid
You could always add some kind of security token when submitting data:
Tokens can be easily extended for many different uses and covers wide area when it comes to checking if some request is valid, for example you could let your non critical forms open for public, ask users to get their secret keys from some page (forcing them to open that page) and then use those keys to identify them when submitting data.
Of course all of this can be completely transparent to user as you could give keys from front page via cookies (or session cookies, it does not matter here, no more or less security as server keys should change after use and invalidate within specified time or when user's identity changes).In this example of use, only user that opened front page can submit data to server.
Another case is when cookies is given away at same page which contains form for submitting data to server. Every user that open page will have their keys to submit data straight away, however if someone tries to make request from outside it will fail.
See OWASP Cross Site Request Forgery
and codinghorror.com Blog CSRF and You
Only with AJAX?
Here is my answer to another question, this answer covers different methods for inserting additional data to ajax request: Liftweb: create a form that can be submitted both traditionally and with AJAX (take a closer look at
$.ajax({
...
data: /* here */
...
Currently I am using tokens this way:
Form used to submit
This hidden input can be added to form, it is not requirement as you can use methods described earlier at another answer.
<input type="hidden" name="formid" value="<?php echo generateFormId(); ?>" />
Function generateFormId()
Simply generate random string and save it to session storage
function generateFormId() {
// Insert some random string: base64_encode is not really needed here
$_SESSION['FORM_ID'] = 'FormID'.base64_encode( uniqid() );
// If you want longer random string mixed with some other method just add them:
//$_SESSION['FORM_ID'] = 'FormID'.base64_encode( crypt(uniqid()).uniqid('',true) );
return $_SESSION['FORM_ID'];
}
Processing submitted form data
if (!isset($_SESSION['FORM_ID']) || $_SESSION['FORM_ID'] != $_POST['formid']) {
// You can use these if you want to redirect user back to form, preserving values:
//$_SESSION['RELOAD_POST'] = $_POST;
//$_SESSION['RELOAD_ID'] = uniqid('re');
echo 'Form expired, cannot submit values.';
//echo 'Go back and try again';
exit(1); // <== Stop processing in case of error.
}
If you need to check which form is submitting data
Then you could just add prefix when generating id's and check for that prefix when processing form data.
This is case when one php script deals with many different forms.
Remember that only ultimate answer to prevent evil users is to pull off all wires from your server...
This is an interesting topic, but you are missing an important point: A spam robot / bad user could also bomb your database by using that specific form page (!).
So, the question is not how to check if the request comes from that page or not, the question is how to check if he's a regular user or a robot/spammer/bot.
Do it with a captcha, like http://www.recaptcha.net
In case i slightly misunderstood the question: If you want to be sure that the request comes from a "real" user you will have to work with a login system / user system and check for users id / password (via db or sessions) every time you want to do a db request.
You can verify that the page is being requested via AJAX with checking against this:
strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) != 'xmlhttprequest'
You could also check the HTTP_REFERER.
But it sounds like you're trying to protect a page that processes vulnerable data. This requires more than just the two things above. I'd recommend googling 'CSRF Forgery' to get more information on this.
These are something that you should take a look at.
Capthcas.
Referer check.
Use POST than GET. [Still Curl can automate it.]
I've been trying to use jQuery to grab the information from $_POST and return the user back to the actual form if their email address already exists in the system, however I can't seem to get jQuery to grab the php variable $post (which has all the information from $_POST) and spit them back to the original form. Could someone help me out please? :)
**************** EDIT ****************
So here's the basic structure.
Form: Name, Email, Address.
Submitting the form calls a php function to check if user exists in the database. If the email address is in the database, I want it to say "sorry this email already exists, click here to try again".
After clicking on the link to try again, I want the form to re-display with the fields they just typed in to display again. <- this is what I thought jQuery could do to re-post the information back to the form page..?
If the user doesn't exist, the user is saved into the database.
Does that make more sense?
From the sound of your question what you're trying to do doesn't make sense. This is because PHP is a server side language while Javascript is a client side (in the browser). This means that Javascript, and therefore jQuery, don't have access to PHP's variables ($_POST included).
There are two common ways to solve this:
Have PHP generate the form. You would output the values from $_POST, or another data location, into the form (ex., echo the variable into the input tag's value attribute). This is by far the easiest method. For example: printf('<input type="text" name="foo" value="%s"/>', $someCleanVariable);
Have the PHP generate JSON or XML, and use AJAX to get the data from the PHP script. You would have to parse out the values into the form. This is basically the same as the previous example, except it's more portable: you can have any source consume the data instead of just your form.
However, make sure that you protect your users when doing this: you need to clean the data that you're sending back to the user to make sure that there is no HTML, Javascript, or other malicious code in it. You don't want people being able to alter the look of your page by passing it data. See Cross-site Scripting Attacks.
Cheers.
Im trying my first form validation with PHP.
I need some guidance with the logic.
I have purchase.php (which has the form) and review-purchase.php(which sets SESSION variables and displays the user data inputted)
If any of the fields fail validation I don't want the user to get to review-purchase.php
Should I be sending the user to the review-purchase.php script, checking validation there and then redirecting back the purchase.php with an error message?
or
should I be using an if/else statement with $_SERVER['php_self'] etc in the form action="" and keep all the validation on the purchase.php page itself and only letting purchase-review run if everything passes validation?
Sorry for the confusing question but i myself am very confused...
That's a question many people ask themselves, and there is probably not one right answer...
What I generally do, in your case, is :
purchase.php displays the form
that form posts on itself (ie, purchase.php)
when data has been submitted, it is dealt with -- still in purchase.php
if there is an error (like something not OK in the input), you can re-display the form really easily, this way : you already have every values that were typed in by the user
if there is no error, you can do whatever you have to with the data ; like set it in session, if that's what you need, or save it to database, for instance.
only when everything was OK (data validation OK and storage OK), you redirect to "confirm.php"
that confirmation page does nothing except display a message saying "thanks for your purchase", or something like that.
It means putting more stuff in your purchase.php, yes :
(re-)displaying of the form
dealing with the input
But, this way, it is really easier to re-display the form, pre-filled with what the use first typed, when there's a validation error.
You can use functions/classes/methods or even some included files, though, to not end up with one big chunk of un-readable / un-maintenable code...
If your form posts to another page, it'll be really harder to re-display the form... If you are using redirections, you'll to pass everything in the URL, and it'll be a mess (And there's a size limit, too)
Here, it means I would totaly remove your review-purchase.php file ; and transform it to a confirmation page, so the user knows everything was OK and his purchase is being take care of.
I suppose it's quite what you meant in your last paragraph, actually :-)
Just beware : you have to think about escaping data before injecting it back into the form (see htmlspecialchars and/or htmlentities) ; that is true for everything you get from the user (And, probably, for PHP_SELF too, I'd say) ;-)
Well, it seems you have a misconception about where and when PHP code is executed. If you want to validate user input on the server side - with PHP (and you should because any JavaScript validation on the client can be worked around by a nefarious user) - the PHP validation can only occur after the user has posted data. That is no matter to which page the user posts the data - be it the original form or a different page.
So, in your situation if you want users to go to a page if validation is successful and to a different page is validation fails yo will need to do a redirect anyway.
In this case you have two paths:
user requests Purchase.php and fills out the form
user posts data to validation page
if data is valid -> display purchase review information
else -> re-display form page and have user re-enter data
So if Purchase.php posts to itself, you can validate there and redirect to review.php only if data is valid. Which means that in the successful case you do 2 redirects and in the failed case you do only 1 post.
On the other hand, if you post directly to review.php and you validate there, you have 1 post in the successful case, and 2 in the failed case.
The above is true no matter how you spin it - unless you use the same URL for the form and the review, in which case you can put logic in the same place to do the form, validation and purchase review in the successful case.
I hope this helps.
The most common way of doing this would be to do all your validation checks in purchase.php. This way, if there are validation errors, it's easier to re-display the form with all of the information that the user has already entered.
If the validation passes, you can do a redirect to review-purchase.php with the necessary purchase information set in a database, or possibly $_SESSION if you're not using a database.
If you can separate the validation code into functions, and the display code into templates to be included, you can achieve a nice separation of logic that would allow you to use them from whichever file you go with. You might be able to avoid a redirect in that way, ie. in purchase.php you could check if there's $_POST input, validate it, and either re-display the form template, or display the purchase review template.