Secure Php Programming tips and pointers

[jlhaslip 4]

PHP Security Pointers

Read this link: http://forums.xisto.com/no_longer_exists/ about register_globals being set to "off" by default
and this one, too: http://us2.php.net/manual/en/security.globals.php
about the reasons why they are "off" by default and the impact setting "on" has for your site security.

Secure Programming includes:

1. Initializing variables - see Example #1 on the second link. Set values to 'false' until they are sourced and confirmed.
2. Know where your data is coming from and avoid using $_REQUEST['data']
3. Validate your Data. This includes knowing where the Data is expected to be coming from, what its "type" is, what range of values is acceptable, etc.
4. Use $_GET or $_POST or $_SESSION or $_COOKIES to restrict the source of your Data. Not $_REQUEST.

Misuse of the $_REQUEST array can have consequences for your site and account security. It doesn't take an extreme amount of effort to avoid the implications.

If you have questions, please start a new Topic in the PHP Programming section.

No serious programmer would ever want to have register_globals = "On".

Thanks.

[truefusion 3]

I wouldn't say that avoiding $_REQUEST makes things more secure, but rather that avoiding $_REQUEST helps makes it easier to debug your code. I mean, what makes $_REQUEST less secure than $_GET, $_POST, $_SESSION and $_COOKIE (although $_REQUEST doesn't store $_SESSION data)? Because $_REQUEST stores the same data as $_POST, $_GET and $_COOKIE? If that is the reason, then why not avoid the other global variables, the ones that $_REQUEST takes from?But $_REQUEST can come in handy, however rare that may be. For example, if your script allows for users to access the same data via the methods GET and POST, $_REQUEST could be used to reduce the need for unnecessary conditional statements and function calls.

[rvalkass 5]

But $_REQUEST can come in handy, however rare that may be. For example, if your script allows for users to access the same data via the methods GET and POST, $_REQUEST could be used to reduce the need for unnecessary conditional statements and function calls.

That, in part, leads to its lack of security. If you are expecting data to be passed via POST then fetching it with $_POST['variable'] means it can only be sent via the POST method. If you fetch it with $_REQUEST['variable'] then the user could easily override the variable by passing it via the GET method in the URL. Depending on what that variable is, what security you have built into your code, etc. that could have no effect at all, or cause people to gain access they shouldn't have and launch a nuclear missile at France... (Here's hoping the nukes aren't controlled with PHP )

[truefusion 3]

That, in part, leads to its lack of security. If you are expecting data to be passed via POST then fetching it with $_POST['variable'] means it can only be sent via the POST method. If you fetch it with $_REQUEST['variable'] then the user could easily override the variable by passing it via the GET method in the URL. Depending on what that variable is, what security you have built into your code, etc. that could have no effect at all, or cause people to gain access they shouldn't have and launch a nuclear missile at France... (Here's hoping the nukes aren't controlled with PHP )

The example i gave expects data from both GET and POST, not just POST alone. But you can't externally modify the data once it has already been sent—you'll have to resend the data. Specifically limiting your program to use $_POST alone instead of $_REQUEST does not make your program more secure (though it may make it easier to debug), because POST can still be messed around with using XSS. Therefore it is not the case that $_REQUEST is insecure, but rather how you have your script handle the request. I'm not sure how PHP fills in the data for $_REQUEST when $_GET and $_POST have data stored in the same key: whether $_POST overwrites $_GET or vice versa when storing in $_REQUEST is beyond me at the moment. But if one does overwrite the other in $_REQUEST, that still doesn't pose a security threat if your script was designed to handle any kind of input—that is, if your script filters the data properly.