On 6/18/06, Ben Ramsey <ramsey@xxxxxxx> wrote:
On 6/17/06 5:34 PM, Satyam wrote: > Your application might require that flexibility or accepting data via > POST or GET, in which case, it is just fine. Contrary to another post > I've read, there is nothing good of register_globals, that is why it is > now defaulted to off and kept for compatibility, though highly > discouraged. There is nothing intrinsically wrong with $_REQUEST, it is > slightly more vulnerable than differentiating POSTs from GETs, but it is > not the worst you can do I never said there was anything good about register_globals. In fact, I was implying that it was bad. With register_globals, you can't tell whether the variable $foo is local, global, from POST, from GET, from COOKIE, etc. I compared $_REQUEST to register_globals because it behaves similarly: you still don't know whether $_REQUEST['foo'] comes from POST, GET, or COOKIE. The good thing is that you at least know it comes from an HTTP request, so you know not to trust anything from it.
You're in a bad state of affairs when the security of your application comes down to whether the input came from POST, GET, or COOKIE. I wouldn't compare register_globals to $_REQUEST. The problem with register_globals is that it injects variables into your script. $_REQUEST doesn't do that. There are pros and cons for each: $_REQUEST is more flexable - $_GET and $_POST are more self-documenting - if you see $_POST, you know that the info came from a POST form, where as $_GET variables could be <a href="x.php?name=value">like this</a>. If your security is so bad in the first place that your use of $_REQUEST instead of $_POSTcauses a vulnerability, then it's time for a serious code audit. Good code won't be vulnerable to register_globals either, but having register_globals on is a security problem because there are security flaws that can only be exploited when register_globals is enabled.
