Page 1 of 1
HTTP Post is not working
Posted: Thu Sep 08, 2005 11:30 pm
by usagichan
Weirdan | Please use Code: Select all
tags where approriate when posting code. Read: [url=http://forums.devnetwork.net/viewtopic.php?t=21171]Posting Code in the Forums[/url][/color]
I entered this code in a program called test.php:
Code: Select all
<? if (isset($Submit)) {
echo "The Submit button was pressed" ;
} else { ?>
<form action="<? echo $PHP_SELF ?>" method="POST">
<input type="submit" name="Submit" value="Submit" >
</form>
<? } ?>
I have a linux/PHP/mySQL server. When I upload this program t my server and run it, it functions as it should. Clicking the button displays "The Submit button was pressed.
However, I have a new Apache/PHP/mySQL installation on my personal computer. When I run the very same program there, nothing happens, no matter how many times the button is clicked.
Obviously, the installation on my Personal computer refuses to function with HTTP Post. I have tried another test program which uses GET and it works ok.
Why ?? Any ideas??
bob
Weirdan | Please use Code: Select all
tags where approriate when posting code. Read: [url=http://forums.devnetwork.net/viewtopic.php?t=21171]Posting Code in the Forums[/url][/color]
Posted: Thu Sep 08, 2005 11:44 pm
by harrisonad
The value attribute of a submit button serves as caption rather than it's value when the form submitted.
If you want to check if the form is submitted, don't check for the existence of submit button, because HTML forms can be submitted in many ways other than clicking on it.
Better yet, check the existence of any other form elements such as textbox, hidden field, checkbox, etc.
Lastly, using HTTP globals is a high security risk. Turn off globals and use $_POST[] array rather that specified variable
Code: Select all
if(isset($_POST['username'])){
// .. blah, blah blah
}
Posted: Thu Sep 08, 2005 11:48 pm
by feyd
your machine has register_globals off, which is what it should be, and has been the default in php since 4.2 (a long time ago)
$_POST['Submit'] should contain the value. However, I always highly recommend not
ever relying on a submit button existing in the submission. Reason why is because if you use the enter-key in IE (at least) while inside a text-field, the form will submit but will not contain the button. You'd likely get a bug report from a user afterward.

Thanks
Posted: Fri Sep 09, 2005 12:40 am
by usagichan
Thanks, that did it. I'm using the SAPI extension for PHP with Apache and apparently it defaults to Register Globals off. My server has Register Globals on.
I've been running it this way for a few years with no problems. There is over a meg of programs there which I wrote that are compatible with Register Globals on. I understand there is a security issue with this. That's a lot of programs to re-write so could you please explain more specifically what the danger is.
thanks
bob
Posted: Fri Sep 09, 2005 6:19 am
by John Cartwright
http://ca3.php.net/register_globals
better yet, a quick google will bring up dozens of articles.
Re: Thanks
Posted: Fri Sep 09, 2005 7:44 am
by Roja
usagichan wrote:I've been running it this way for a few years with no problems. There is over a meg of programs there which I wrote that are compatible with Register Globals on. I understand there is a security issue with this. That's a lot of programs to re-write so could you please explain more specifically what the danger is.
Basically, any user can overwrite variables simply by editing the url in their browser. So if your script tested if $admin = 2, the user can overwrite $admin and set it to 2, giving them admin status.
Thats true of *every* variable in *every* script with reg_globals on, unless you explicitly define them after the script execution begins. As a result, reg_globals is considered *extremely* insecure.
You will also want to turn error reporting WITH warnings on. That way you can see all the undefined variables you have, so you can ensure you define them while cleaning up the reg_globals issues.
Best practice for developing is reg_globals off, and error_reporting set to all but E_STRICT.
Thanks again
Posted: Fri Sep 09, 2005 12:02 pm
by usagichan
Ouch !
I did try a critical variable in the browser using the format:
http://mysite.com/file.php?criticalvariable=T
It did set that variable and allowed an access which I really do not want. I had been passing this as a hidden variable in forms. I certainly will fix this asap. Yes it is very insecure. The upside is that a person would need to know the variable name and what it needs to be set to. So it's not a "walk in the park" to exploit this flaw.
thanks again
bob
Re: Thanks again
Posted: Fri Sep 09, 2005 12:29 pm
by Roja
usagichan wrote:
The upside is that a person would need to know the variable name and what it needs to be set to. So it's not a "walk in the park" to exploit this flaw.
Actually, thats not accurate. There are methods of gaining those variable names, which does make it a walk in the park. Whether its via command injection, path exposure, OS-level compromise, or a dozen other methods, there are plenty of other weakpoints that can expose those variable names. That also ignores the ability for them to brute force various common variable names ($a-$z, $admin, etc), or look at examples of the code, or...
The list goes on. Register_globals is extremely dangerous, and definitely makes things a "walk in the park" for an attacker with knowledge.
To repeat a previous point: Also use error reporting to ensure that while developing you see ALL warnings, which can prevent many security issues by encouraging best coding practices!