Radio button form security

[wsmeyer]

I have a few poll type forms sprinkled around a website that have from 2-4 radio buttons and a submit button. They are so simple that on the target page, instead of my standard security precautions, I simply put the radio button values into an array and do an IN_ARRAY on the POST values. Now someone else has the client all in a tizzy about these forms being insecure and poorly written.

When I did this two years ago I wanted them to be simple and self contained so I didn't have to worry about some function included from somewhere else that might get lost/deleted or some new hacking technique that it wouldn't catch.

I still think I achieved my goal but am I just not seeing how this is insecure?

William.

[Readie]

One reason it's unsecure is somebody could create an off-site form with the same form element name(s), but say a textarea or text input; that then posts to the same location as your form.

Depending on where you're saving the info from these forms will affect what measures you need to take to rectify this particular insecurity.

[wsmeyer]

@Readie

Thanks for the input. As the data is written to a database, where the POST comes from would usually be a concern to me but the value of the POST is checked against an array of the possible values from the radio buttons. Since there is only supposed to be one POST value I didn't even bother checking for the name.

I guess a form of hacking would be vandalism and someone could easily post data to the target from anywhere, but the value is limited to that of the radio buttons so what would be the point?

To be a little more specific, I did this as a favor for a friend a few years back that was trying to reduce the number of emails he was getting from customers asking questions that were answered in the FAQ's. These forms are found next to the answers and ask if the answer is adequate or not. As i suspected, it was more a problem of not reading the FAQ's than the quality of the answer but that's another post :)

I guess what I'm really trying to figure out is if this other person:

A. Is over exaggerating the risk
B. Is disparaging my work to make themselves look better
C. Is seeing some risk that I am not

William.

[Readie]

I think most likely A :)

Just to allay their fears though, it may be worth changing

$variable_name = $_POST['form_element'];

to

$variable_name = mysql_real_escape_string($_POST['form_element']);

[rocknbil]

I vote "all three." One of the problems with web development is that there is always someone smarter and may know something you don't, so look at this as an opportunity to improve something, and learn something new in doing so.

There will always be someone nit-picking at your work to steal jobs. It's the way it is. My favorite is "memory leak", followed by these technical nit-picks, which the client most likely doesn't understand but is scared to death by it. Your job is to sort the wheat from the chaff and allay their fears, one way or another.

Rather than argue the point, just grab the bull by the horns and change it. Make sure the data is exactly what you expect, even if you leave it in an array. Set up a demo, throw some mySQL and XSS injection strings at it, display the result. The client won't understand that either, but they will see you're addressing the issue proactively.

Even though this is a friend, whatever you do, don't address it with the client the way you have here, contesting their claims. All it does is turn it into a p***ing match, and it always ends badly. When you visit a couple and they start fighting, do you choose sides?

No. You say "It's time for me to go . . . "

:-)

but the value is limited to that of the radio buttons so what would be the point?

Because they can.