'Hacking' submit button with a url param

Anon

Hello,

maybe it's a well known problem, maybe not. But here it is:

The following happens all in one .php code file: The idea is showing a page only after the user has clicked on the submit button on one page. I found out some time ago, that this can be very easily hacked by just giving the name of the submit button as a url parameter and assigning it any value. Then the code will parse the thing and see that the submit variable is declared and show the block of code that is supposed to be shown only when the submit button is pressed.

I hope it's a good description, here is also an example of it:
suppose I have a block in a source to show a page with a form and the button:
<code>
<input type='submit' name='mysubmit' value='send'>
</code>
Then somewhere else in the source I have a block like:
if ($mysubmit)
{
//do something here meant for people that pressed 'mysubmit' previously
}
Well, if I call the code like:
...myfile.php?mysubmit=x
then the code will show all the 'authorised' part at one, without caring if I clicked the button or not.

Is there any solution how to secure this piece of code?

Thanks in advance for your answer.

vsego

Yes, instead of $mysubmit use $HTTP_POST_VARS["mysubmit"]

[deleted]

There is literally NOTHING you can do to stop anyone from submitting any kind of data.
It's very easy to fake a form using GET or POST methods.

It is therefore not a good idea to put authorization information into a form (for example through a hidden field)

Access rights should be decided serverside. Try using sessions. When a user logs on, you put his authorzation data in the session.
Then whenever a user tries to do something, you first check the authorization in the session data to see if he is allowed to do that.
That way, he can put as much info into the fake forms as he likes, it will have absolutely no effect on his access-rights.

[deleted]

That's useless because the $mysubmit var is created from the data in the $HTTP_POST_VARS array.

Anon

use fsockopen or cURL to do the most secure switching and passing.

[deleted]

Euh? what does fsockopen have to do with anything?

amcgrath

I'm not following you here, if the person requests the script appending mysubmit on the url, then $HTTP_POST_VARS would not be present... enlighten me, cuz I've used something similar in the past and if it's wrong, I'd like to fix (mine usually is some variation or another of if ($HTTP_POST_VARS && $REQUEST_METHOD == "POST" && whatvber else I feel like checking....)

jc94062

unset ($ACCEPTED_GET_VARS);

or something?

As long as the form is post, your not going to need anything to be passed in the URL (and if you are, you need to rethink your security!)

Just an idea...

dannys

You could also check the refering page and jump back to the form page if it wasn't the referer.

This is also pretty easy to hack though, as are most client side stuff - best use sessions etc, then you can jump back to the login page if the session hasn't been started or has expired.

jc94062

If they can't put ?refer=page or whatever into the URL its pretty hard to hack?

But I'm not an expert, so I'd be happy to know more to try and cut down on attempts...

vsego

vincent wrote: "$mysubmit var is created from the data in the $HTTP_POST_VARS array."

If the request was POST. Try it with GET (or just type url yourself). Should be empty...

For example,

phpinfo.php:
<?php phpinfo(); ?>

call phpinfo.php?test=a

You DON'T have $HTTP_POST_VARS["test"], but you DO have $test and $HTTP_GET_VARS["test"]!

[deleted]

headers are plain ASCII, you can put anything you want in them, it's not that difficult at all.

[deleted]

And this helps how?

[deleted]

True, if you use the GET method then the POST_VARS is empty. But what's to stop me from making my own form and using the POST method that way?

vsego

If you use $HTTP_POST_VARS["submit"], instead of $submit, you will have empty value if this was reasult of script.php?submit=whatever.

I'm not saying this is not fakeable and I agree that authorisation code shouldn't be in hidden fields, but this is not the issue. The issue is: preventing common user from avoiding form. This can be useful, for example, if you have ads on the page with form. Most users will not know how to cheat such script (or won't bother with it).

jc94062

unset ($ACCEPTED_GET_VARS);

would prevent that, wouldn't it?

Its part of a piece of code I run that only allows about 15 things to be put into the URL, obviously, things like admin, username, ... arn't allowed...

vsego

This "hacking" story went far too far. Please tell us why do you want to prevent this being called from url and not from form?

Anon

Indeed, the discussion went further than I expected. But I think this is because it shows a vulnerability in practically every PHP form used for authentication. And since we all use these forms, it's an interesting subject.

I am trying several of the suggestions in this thread and I will try to mail back my opinions. Concerning my initial question: I don't expect "hackers" to look into every form I build, but I had at least once a case of someone hacking a hidden field with a url parameter and changing a money amount with it, which is highly undesirable as you may imagine. So now I try to do it all via sessions or the database and never with url parameters and hidden fields (when it comes to sensitive data).

But in the case I mention, I can't use sessions, because to give a session parameter, I also have to give a loop like if ($mysubmit)
{
$SESSION["param"]="OK";
}
so it's still the same problem....But I'm trying out some things now and I'll post some ideas. And by the way, thanks everyone that replied here.

dannys

Well i'd think the obvious thing to do is never ever use hidden input fields to store sensitive data.

The situation is the same for PHP, ASP or indeed ANY CGI app.

Use sessions or encrypted cookies to store such data.