Die on direct access to a php form sent by AJAX

[etrader]

I want to perform a php process initiated by AJAX according to the method described in http://www.w3schools.com/PHP/php_ajax_database.asp

 

with this line

xmlhttp.open("GET","getuser.php?q="+str,true);

the php process in getuser.php is initiated. But how I can restrict direct access to getuser.php?

 

If someone visit getuser.php?q=something; the process will be started for "something". I want to run the getuser.php process only and only when it is initiated from my main page.

[the182guy]

There is no way to know for sure where the call was initiated from because an AJAX request is just the same as any other page request. If you add any sort of variable to check, it will always be breakable by just copying the AJAX HTTP request.

 

Have you considered securing it with a login system? So only give access if a user is authenticated.

[etrader]

Thanks for your attention. There are two issues:

 

1. Some features are available to all visitors and I cannot limit by login

 

2. My concern is about security issue. If it is for posting something on the website. Even logged users can abuse the system to post something by direct access to the php file.

[Adam]

If you're using jQuery or another framework, you can pretty safely rely on this method of detecting AJAX requests. If you're not using a framework, you can still include the header in your own script and use it. As mentioned though, you can't safely restrict access to pages if not from an AJAX request, because essentially there's no difference in the request, only that one was scripted.

 

Your code should have the neccesary security checks to prevent any kind of abuse; time-outs, user validation, etc. You're approaching security from the wrong angle.

[etrader]

Since I use jQuery for some function; the method seems to be practical.

 

However, I did not get your point about security. This is a simple script and I think there is less space for security holes. Could you please give me some tips to check security issues?

[Adam]

2. My concern is about security issue. If it is for posting something on the website. Even logged users can abuse the system to post something by direct access to the php file.

 

This is a simple script and I think there is less space for security holes. Could you please give me some tips to check security issues?

 

??

[etrader]

I meant that if someone access the php file directly, he can post spam automatically (whether logged or guest visitor).

 

This is the security issue I can see; otherwise, it is a simple form. What else can be its security risk?

[Adam]

How are they not able to post spam through an AJAX request?

[etrader]

I mean an automatic system. For submitting a form, it is needed to be filled. But a spammer just needs to run a simple script to visit

file.php?q=word1, file.php?q=word2, .... file.php?q=word10000,

[xyph]

A bot that submits forms is by no means complex. There are lots of tutorials out there.

 

The method found here: http://davidwalsh.name/detect-ajax is by no means secure. You're relying on headers sent by the client that can be easily spoofed.

 

Allowing non-registered users to post will open you up to SPAM. Your best bet is probably to include a Captcha for non-registered users, and perhaps a Captcha every 10 or so posts for registered members.

[etrader]

Nice point! This is exactly what I meant. Captcha is a must, as human spam is also a serious problem. However, I think captcha hinders submitting the form; but when someone directly accesses the php file, no captcha is there to hinder him. Right?

[xyph]

The PHP file will require the Captcha ID and a correct response to be passed to it through the headers in either the query string ($_GET) or through post ($_POST). Accessing the file directly won't display a Captcha to respond to and make it theoretically impossible to break.

 

This is a great way to force the user to submit the post through your main page. Accessing the AJAX page with a bad/no id/response could lead to a 404, error message, etc.