Jump to content

Server/PHP config so you don't have to use $_POST['var']


Recommended Posts

I work for a small web design company who use their own servers.

 

When I write PHP scripts on their server i can pass variables over pages and then grab them on the other side by just using that variable again. Like if I had a form input like:

 

<input type="text" name="bob">

 

Then when the form is submitted I can use $bob on the next page without having to do somthing like:

 

$bob = $_POST['bob'];

 

But when using xampp or some other hosting that I have used I HAVE to use the $_POST['bob'] or $_GET['bob'] to grab the variable.

 

What setting is it that makes this possible, is it in the PHP ini? Thanks for any answers :)

Are you serious? That's a huge security problem. I'm not sure of the exact setting you are asking about but I know many of those settings that had security problems have been descoped or removed entirely from current versions of PHP.

 

Just think about the situation of variables used in your code that are NOT sent via POST data. A user could POST a form to your processing page with additional fields in the POST data with the same name as variables that is used in your code. This could cause, at best, your script to fail to, at worst, exposing your applications to infiltration by malicious users.

Ok, but what's stopping someone from posting to your website from a form they have made. Or GETing?

 

Absolutely nothing. But, if someone posts a form to my processing page and they include an additional field in the post data - it won't do anything since I wont be referencing that field. Let's take the example from the linked page:

if (authenticated_user()) {
    $authorized = true;
}

 

If authenticated_user() returns true then $authorized will be true - else that variable is not set. With register globals on, a user could post a field such as $_POST['authorized'] = 1. Then, even if authenticated_user() returned false the $authorized variable will still be true. However, if you could ONLY reference that additional POST variable as $_POST['authorized'] it would have no ill effect on that code.

 

That doesn't mean that you are completely safe with register globals off. I've seen plenty of people use things like list() to convert the POST array into named variables.

Taking the example in the linked page, if a user submitted a field called 'authorized' I could only reference it as $_POST['authorized'] if register globals is off.

scripting against an additional post item is one thing, but you really need to be sanitizing the $_POST contents before you do anything.

 

if you are not sanitizing the post fields correctly, posting something as simple as /* into a field can give someone access to ALL of the data in the database. or worse .. they could DELETE the entire contents of the table.

 

I understand that is some controlled environments security is not that big of an issue. But turning on register_globals to remove a step that can be simplified with a function and foreach loop is just lazy.

 

cross site forgery is HUGE security problem and without minimal security steps like sanitizing input data you are just asking from problems.

Or you could just extract the posted values and use the variables like so.

 

So, start of your script will be: extract($_POST);

 

Then let's say you had an input field with the 'samus' as the name attribute.

 

You could just use $samus instead of $_POST['samus'] and it'll return the posted value for that input field.

As long as you use one of the extract flags that prevent overwriting of existing program variables, otherwise you have just opened the door for a hacker to inject his values into your program variables.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.