i have a webshop running, and every couple days an empty mail is send, like an order. Is this most likely google?
I have a file called send2.php, it takes all info from session, all post data, and sends it via mail. after that it redirects to a "thank you" page.
Can and will google send empty forms just to see whats in send2.php? What would be the best way to prevent this from happening?
Add a file called robots.txt to your root directory and place this in it:
User-Agent: *
Disallow: /path/to/send2.php
Keep in mind that this is not a perfect solution. This will prevent (co-operating) web crawlers from visiting your page.
Reference: http://en.wikipedia.org/wiki/Robots_exclusion_standard
A better solution involves user authentication (ensuring that the agent prompting your script is not a bot).
As others have mentioned there are a variety of way of getting around benign bots using empty() checks and robots.txt. However, these rely on the bots respecting your site. Many bots will attempt to inject values into the form (meaning an empty check won't work) and these bots don't care about robots.txt (I wouldn't be surprised if robot.txt:Disallow actually encourages some bots to target your site under the presumption that you may have something sensitive... but that's just conjecture).
Your best best is going to be a "human-check". Either implement a captcha/recaptcha solution, or some other logical test that's difficult for computers to solve or parse/understand before you allow submission: "What's this animal? [photo of common animal]", "Solve this simple equation [(12/4)+1]", etc etc.
These checks will have to be server-side. They generally involve setting a $_SESSION variable with the "answer" to the challenge task when the form is first loaded and then checking that the value they entered against this session variable once they submit the form. Never rely on Javascript to do validation for you (as you mentioned you are doing in your comment to x711Li). Javascript validation is purely done as a convenience to users (so they can see issues before they submit) or to reduce loads on your server (so you don't have to run/log lots of failed submissions). Any person or bot can bypass or manipulate Javascript validation, so make sure whatever method you end up using involves a server-side check.
If the mail your receiving is blank values as the values have not been set throughout the session then, why dont you check for those values before sending the mail, its true that the culprit is most likely a crawler, and many of them (inc bingbot) will not listen to a robots.txt file, plus a robots file is the first place a hacker looks for for info gathering.
<?php
if(!empty($_SESSION['some_info'])){
mail(...);
}
?>
Related
So I am having a page where there is a submit function. When you click submit you get to a site named send.php
I don't want people to be able to refresh the site and that way send the same answer twice or more for spam. I figured that one way of doing this would be to make sure that they come from the submit site, if that is possible. Another way would also be to redirect them if they tried to refresh.
Is there any way to do this? Or another way to fix my problem for that matter
Have a look at the HTTP_REFERER variable. It will tell you what site the user was on before he came to your site.
It will gives you info like:
192.168.1.10 - - [16/Apr/2008:16:12:36 +1200] "GET /php-http-referer-variable/ HTTP/1.1" 200 2014
"http://www.websitefromexample.com/" Mozilla/5.0 (compatible;
Konqueror/3.5; Linux) KHTML/3.5.8 (like Gecko)"
$_SERVER['HTTP_REFERER'] is supposed to contain the referring page. But:
it may be omitted by the client for privacy reasons
it may be modified by the client(the contents of it comes from the client's request after all, by protocol design)
As mentioned in the PHP documentation: In short, it cannot really be trusted.
Doing a redirect after successfully receiving a submission should do good, as it forwards the user away from your submission processing code(provided you redirect somewhere else..)
But someone with a black hat might still record the request to the server when doing the original, legit submit. And reuse it. So the redirect method should be enough to keep you "safe" from ordinary users, but not from a person who wants to spam your site. I.e it's like a booth where your site sits and accepts submissions, and then politely tells the person who handed in the submission to "move over there". No locks or anything. The person may even ignore the request to move on.
If you:
add some hidden field to your form with some sufficiently-hard-to-guess value(varying, not some constant phrase!)
store it somewhere in the session data, a database or what suits you
rewrite your code to only accept a submission if the value of the hidden field matches your stored value
Then you've put a hatch on your booth, which only opens for those who know the secret code given to them. You've limited the ways an user can access your submission processing. The secret value should be discarded after use, as otherwise it can be reused and loses its purpose..
The user can still alternate between the form page and the submission/form target page to receive new secret values and be allowed to do a new submission each time though. If you want to limit the number of submissions that a user is allowed to make then you should keep track of the number of times a user has requested the form page lately.
..and of course, look for forbidden words etc in your processing code if you need to.
I am using a simple PHP API that takes requests and connects to a MySQL DB to store/retrieve user information. Example: Login is done using a HTTP POST to the API with username and password.
How do I prevent people from flooding my API with requests, potentially making thousands of accounts in a few seconds.
Thanks
You could serve a token generated and remembered on the server side which is rendered with your forms and validated when the form is sent back to your server. That prevents the user from just generating new post requests without actually requesting the according form from your server since they need the according token generated on your server to get it through.
Then there is the mentioned captcha which would be way too much for a login form from my point but when it comes to things like registering a new user the captcha in combination with the token sounds very good to me.
UPDATE
I Just found this article which is about floot protection of script execution in general. I think their approach is good as is the ip tracking provided you have the ability to use memcache or something similar to speed the checks up.
First, when registering a user, also save her IP address at the time of registration in the DB.
If the IP already exists within 45 minutes of previous registration, reject the request.
Another method is the Captcha, I personally prefer a different method that I found to be even more effective against robots.
Instead of asking the user to "type what they see in an image", and verify they are humans (or robots with sophisticated image processing),
Add another field (for example city), and make it hidden with javascript.
The robots would submit that field to the server, and humans would not.
Note that the robots must run the javascript in order to know what fields are hidden, and this is a time consuming process that they usually don't do.
(see turing halting problem)
For a system I'm working on I've got a bit of a problem: I'm messing with one of the basic rules of HTTP and I'm allowing users to post data through a GET request.
Don't get mad at me yet: I've got a reason for this: Users arrive in my application from an external environment and I can't prompt them for any extra input (so all necessary data is in the GET query). They should be able to close the browser window right after it opens and the input should be saved. And no, I can't do this through AJAX, an API or other under-the-hood method.
These requirements kind of rule out captcha, calculations, forms etc. So I'm left with the problem that I really do want some type of verification to prevent bots/crawlers from "accidentally" submitting something.
One of the solutions I am looking into is making a very lightweight landing page that submits itself through javascript onload but it would be the ugliest thing in my application so I'm trying to prevent it. Another is to let the landingpage not do any of the processing but instead use an AJAX-call to do this. This would however mean that older browsers (and many mobile phones) would have to use another solution.
Background: Application written in PHP5.3, built on Yii Framework, 100% cross-browser compatible (this includes pretty much every mobile phone out there).
Some more background: The "exteral environments" I'm talking about vary from e-mail clients to websites. Manipulation of our content at runtime isn't possible.
Update: Here's what I'm going to do: I'm probably going to combine solutions posted here in a fallback mechanism so that a chain of verifications will be attempted:
1. Ajax verification
2. Non-Ajax javascript verification (automatic form submission)
3. Prompt for user input (user has to click a confirm button)
Besides this I'm going to implement a bot trap as descripbed by http://www.kloth.net/internet/bottrap.php
After I'm done with building this I'll update the post if I did anything different.
Hard to understand where you app is and where external environment really are. But one simple bot-removal technique I use is to put an hidden field named 'login' or 'name' and give it an empty value.
Human people will never fill this hidden field, but spam bots are always filling it. So you can discard any request with that field being not empty.
Now you must prevent crawlers and not only spam bots. Never did it, but here are some thoughts. You could add a hidden 'human' hidden input in the form on first mouseMove events (but keyboard-only -- and think about blind people -- users will be considered as robots). So maybe if this field is not there you can launch a javascript 'confirm' where you ask "Confirm that you are a robot or click cancel if you are human".
You can make your anchor link containing a default value that this hidden field values will overwrite in js. Most crawlers will not overwrite the values, especially if you must cancel a confirmation to get the right behavior (and avoid confirmation with mouseMove event for most users).
If you are able to modify the place that your users are coming fro, you could try including a checksum. Calculate some kind of checksum or hash of all the fields in the GET request and add it to the GET request itself (i.e. through javascript, but do it in the place your users are coming from, not where they are landing). Then, in your application, reject all hits with an incorrect checksum.
So I have a form that can create an account and right now the process to create the account is by calling a javascript REST API. I was thinking that it might be really easy to hack that programmatically since all they would need to do it look at the javascript to find out the url to spam and that it might be safer to do the processing in a PHP script. Then I though well, they could just look at the form to find the URL just as easy if I don't do it through javascript. The form is going to be processing only POST data but not sure if that is enough and if it matters if i process it through javascript or PHP.
What it the best way to prevent someone from spamming a form programmatically (ie prevent them from writing server, like PHP, or client, like javascript, code to spams the processing script).
One way is to use Captcha to filter the bots out reCaptcha but its not 100% protection
Using Captcha is probably the first method:
Google's Version
Secondly I would do data checking on the server side and possibly email verification, if the E-Mail is not verified I would have a cron to clean out the rows in your table which don't have e-mail verification.
With these two methods you should avoid a good majority of it.
Go for reCAPTCHA. It's pretty easy.
You can obtain a key pair there by registering your website URL. Use that key to generate the reCAPTCHA image/textbox in your form. Your form's data will be posted and added to database only if entry matches the text displayed in the image, otherwise not (that's aserverside check that you have to keep). You'll get plenty of related code in Google :)
Another technique, as most of the websites now a days follow, is to send an account activation link to the user via email. An account will get created only when that activation link is clicked upon. You can also set an expiration time (say, 24 hours) for this purpose.
Hope this helps.
iam using ajax for sending requests to one of my php pages in the site... but i do this from my html page. This is secure....
But what if others know my php page and they send ajax requests to that page from their script? This may cause any security problems.
How can i avoid this ?
You seem to be trying to defend against CSRF attacks.
You can include a nonce in your page, then require that all AJAX requests have that nonce.
Since the attacker is on a different domain, he will have no way of getting the nonce.
The only way they can send AJAX requests to your page is if they are on the same domain (ie. their script would have to be hosted on your domain).
AJAX won't work cross-domain, so it's quite secure.
There is very little you can do to stop this, the only think that can help prevent this is by having a good application architecture.
For example, the following rules will help:
Try and keep your Ajax down to read only.
If you have to use Ajax to write then you should follow these rules
Only allow users that are logged in to submit data
Validate Validate & Validate your post data, Make sure its exactly as you expect it
Implement a form hashing technique that generates a unique hash for every form on every page, and validate against a variable within the session Aka (Nonce)
If the user is logged in make sure there's a validation period, such as "You must wait 30 seconds before posting".
Always use session_regenerate_id() before you call session_start
These are just a few pointers that should get you on your way, when researching these you will come across other techniques used by other site owners but you should always remember the following 2 rules.
Never trust your users, just act like you do
Whitelist and never blacklist.