CODEWITHSUNDEEP
phpapachepost
cj333
cj333

Reputation: 2609

php / apache, is there any way to block cross domain post

I have some ajax page with php post (so that CAPTCHA is not a good idea).

some fsockopen or curl could set POST value to steel data with cross domain.

So php / apache, is there any way to block cross domain post?

Upvotes: 0

Views: 407

Answers (2)

mrbinky3000
mrbinky3000

Reputation: 4291

A lot web services that offer an API, but don't want just any old person to access the API, use public / private keys via CURL. You would have to do a little research on public / private key encryption if you are not familiar. I am sure there are PHP libraries that get all if not most of this done for you.

Credit card merchants like Authorize.net, and several customer database services that handle PII (Personally Identifiable Information) that I've worked with over the years allow you to post to a URL and retrieve the result. They protect their services using public / private key encryption. They issue me a key and I have to post that key along with my request data. The key is usually sent in a header, hence the need to use CURL.

Background Information: http://computer.howstuffworks.com/encryption3.htm

PHP Examples: http://www.joeldare.com/wiki/php:php_public_private_key_cryptography

Note: the benefit of this system is that you have absolute control over who is allowed to post to the PHP script on your server. If you don't need that level of control, you can just use something called "http basic auth". Place your sensitive scripts in a directory and protect it with .htaccess authentication. Here is a tool to get you started. http://www.htaccesstools.com/htaccess-authentication/

When you make requests via ajax (jquery, I take it) you can pass the login and password. Just make sure you use an SSL connection in your ajax (HTTPS). Otherwise, people can sniff out your login and password as it will be sent in plain text without the use of SSL.

If you do use basic auth instead of public/private keys, your domain will need an SSL cert if it does not already have one. You can buy one from someplace like Thawte.com (not cheap), or self-sign your own certificate. However, if you're going to go through all that trouble, you're 80% to the point of just going the public/private key encryption route. Self-signed certificates usually prompt the user's browser with a warning. This scares away a lot of people.

Upvotes: 0

Quentin
Quentin

Reputation: 943571

You are publishing the data. You can't stop people requesting it.

If you want to keep it secret, require authorisation before allowing access.

There are various barriers you can put in people's way—while still keeping the data public—but none of them are difficult to bypass. Testing the user agent doesn't stop the requestor specifying a user-agent that matches a common browser. Requiring a cookie from another page on your site doesn't stop them requesting that page and getting a cookie for their tool. Etc.

Upvotes: 1

Related Questions