PHP: Security & User Input

Verifying where vars are coming from

[Nick_W]

Hi all,

Is there a way to verify that post vars sent to a page are the result of someone using a form on the site rather than some kind of external bot or script?

I've been looking through the manual and can't find what I need and can't think where (if it exists) I should be looking.

Many thanks..

Nick

[Birdman]

Hmm..I'm also interested in this topic. From what I could find so far, it seems that the best way is to have superglobals off.

See Security with PHP Superglobals [linuxjournal.com]

I don't know if I can even change that myself. My host has them On now.

[ukgimp]

BM

If you have access to your php.ini you can. But you will need to restart the server, which may be your biggest nightmare.

Cheers

[andreasfriedrich]

>>the best way is to have superglobals off.

Birdman, you probably meant to say register_globals off. Superglobals help you identify the method variables were transmitted to the server. In the old days prior to superglobals you could and should have used the $HTTP_*_VARS arrays. Then the only thing that superglobals add is that they have truly global scope and need not be declared as being global in functions as you had to do with the old $HTTP_*_VARS arrays.

While using superglobals lets you access data by transmission method it will not help you to make sure that your original form was used to submit the data.

Andreas

[DrDoc]

Nick,

Is this a constant verification, just occasionally, like a sign-up page?

On sign-up pages I create a random string that is stored in a file/db on the server. I then pass a random (different) identifyer to the user. Also, on the page is an on-the-fly generated image (text verification) which gets the data from the file/db. I can now verify that the user has seen the image, typed in the text, which is matched against the value in the file/db upon submit.

I think that's about as safe as you can get it without encryption.

[andreasfriedrich]

For DrDocs approach to ensure that each and every submit is done via a form one would need to generate a unique random string for each and every request. It´s quite a hassle for the user to have to read and enter such a text string each time she submits a form.

Even simple encryption via htpps does not ensure that the form data is actually submitted via the intended form. One could simply write a UA that handles https connections and posts data automatically. I guess the only secure way would be to use a Java or ActiveX applet that talks to the server via an encryted link. And even then one could try to analyze the transmitted data and try to decrypt them. Once the algo is know one could then imitate the applet again.

In my opinion this is not worth the hassle for most situations.

Andreas

[DrDoc]

Well, I didn't mean that the random string has to be entered whenever a page is submitted. Like Andreas says, that would be quite a hassle! But, it might be something to consider for signup/registration purposes, or for password retreival purposes... any situation where some security is required...

[andreasfriedrich]

Ok DrDoc, that makes sense :).

Why would it be important to make sure that post vars sent to a page are the result of someone using a form on the site rather than some kind of external bot or script? I am dense sometimes so there might be an obvious answer to that question.

Andreas

[DrDoc]

Well, it's just a way of preventing spamming of your server. Without any signup authentication someone can easily write a script that will "sign up" for millions of accounts!

For a normal site I see little use for it, but whenever you enable user registrations it's good to have. Just another way of making it difficult for the "idiots" out there.

[andreasfriedrich]

I just allow so many sign-ups per ip per time period. That works well.

[bcolflesh]

What about getting the referer address? If it isn't your localhost, deny the input.

Regards,
Brent

[andreasfriedrich]

The referrer can be spoofed very easily. If you have a script that tries to spam the server then there is nothing to prevent you from specifying any referrer you want.

Andreas

[DrDoc]

Andreas: Yes, unless they go through an anonymizer that switches IP for each request...

bcolflesh: Well, that can be faked. For example, I write a simple "browser" using Perl's LWP I can specify the referer and everything. It's not reliable... Besides, some UA's don't send a correct referer header anyway.

[bcolflesh]

Another idea - have a hidden field in your form with an MD5 encrypted hash - have some hash pairs in a database - compare them on the submitted page.

Regards,
Brent

[andreasfriedrich]

A script might read that hidden value and then use it to submit the data on its own. Any method that does not require human action is inherently insecure. A method requiring human action is quite a hassle.

DrDoc. Sure you can use various proxies and rotate your IP address that way. In the end you need to decide what´s cheaper. Having some spammers spam you while having a user friendly sign up process that is as easy on the user as possible or being more strict and scaring away some users.

In the old days AltaVista could require you to read and enter that random string before you were allowed to submit a page. But for an online shop that sells the same things for basically the same price users might choose the shop that has the most convenient shopping cart system that does not require them to enter such a random string.

Andreas

[DrDoc]

A script might read that hidden value and then use it to submit the data on its own.

What hidden value? There are no hidden values (well, except on the server... but that's not accessible by the user)

I agree with you though... If the use of any "verification" isn't absolutely necessary, or if it will make the signup/registration/purchase process difficult for the user - it should be avoided.

[andreasfriedrich]

>>What hidden value?

The hidden value in the hidden field as mentioned by bcolflesh of course.

>>There are no hidden values

Wrong. They exist simply by definition. Of course you could change that scenario and prescribe that there are to be no hidden fields with an MD5 encrypted hash but then we wouldn´t be talking about bcolflesh´s proposal anymore.

>>except on the server... but that's not accessible by the
>>user

I am dense but not as dense as that. I am aware of the fact that short of hacking into a server only those values that are exposed to the user via a public interface are accessible. Since bcolflesh is talking about hidden fields in a FORM [w3.org] element these values are exposed in a public interface (the form) and are therefor accessible.

Andreas

[DrDoc]

Oops, missed the post by bcolflesh :(
Sorry 'bout that...

[nosanity]

you could force the usage of sessions. then code it in such a way that a person without a session id (matched against your internal list) cannot post to that form...

just a suggestion. :)

noSanity

[Nick_W]

>Why would it be important

It's not really. Members have to sign up and then are authenticated each time they post somthing using cookies. It's secure enough. I just wondered...

I like the IP idea, easy enough to do too...

Thanks guys..

Nick

[bcolflesh]

What about taking the hidden form value I mentioned earlier, then concatenating it w/a unique session ID and the referer address to create an auth ID for the subsequent page?

Regards,
Brent