Page 2 of 3
Re: Yep, Another login script
Posted: Mon Apr 20, 2009 1:07 pm
by temidayo
kaisellgren wrote:
GET:
If the processing of a form is idempotent (i.e. it has no lasting observable effect on the state of the world), then the form method should be `GET'. Many database searches have no visible side-effects and make ideal applications of query forms.
It's a pity there was no $_REQUEST in the link you supply.
But can't we safely say the same thing written for GET is true of $_REQUEST?
Re: Yep, Another login script
Posted: Mon Apr 20, 2009 1:20 pm
by kaisellgren
temidayo wrote:It's a pity there was no $_REQUEST in the link you supply.
Of course there is no $_REQUEST... $_REQUEST is nothing more, but an array_merge($_GET,$_POST,$_COOKIES); and there is no real reason to need it.
temidayo wrote:But can't we safely say the same thing written for GET is true of $_REQUEST?
What thing?
Re: Yep, Another login script
Posted: Mon Apr 20, 2009 2:23 pm
by temidayo
kaisellgren wrote:
Of course there is no $_REQUEST... $_REQUEST is nothing more, but an array_merge($_GET,$_POST,$_COOKIES); and there is no real reason to need it.
I sincerely believe $_REQUEST was introduced to make life simpler for a developer.
Take google search for example. You can do a query like
http://www.google.com/?q='search_term'
(I'm not sure I get that syntax right, but you can see my point).
In processing the q parameter as a developer, I might want to accept either from POST or GET.
Instead of testing both, I can just get it from REQUEST. Will you still call that a bad design?
kaisellgren wrote:
temidayo wrote:But can't we safely say the same thing written for GET is true of $_REQUEST?
What thing?
Can we say:
If the processing of a form is idempotent (i.e. it has no lasting observable effect on the state of the world), then the form method
could be `REQUEST'. Many database searches have no visible side-effects and make ideal applications of query forms.
Re: Yep, Another login script
Posted: Mon Apr 20, 2009 2:31 pm
by kaisellgren
temidayo wrote:I sincerely believe $_REQUEST was introduced to make life simpler for a developer.
As many features in PHP, they were made to make our lives easier. However, many features of PHP are more or less a security problem. The biggest I can think of at the moment could be the Magic Quotes feature. For sure, some features make our lives easier.
temidayo wrote:Take google search for example.
As an example for what? Google search uses GET. If you are to code a Google -like search, you would use $_GET.
temidayo wrote:If the processing of a form is idempotent (i.e. it has no lasting observable effect on the state of the world), then the form method could be `REQUEST'.
There is no such method as REQUEST. There are only (apart from custom HTTPD specific) OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE and CONNECT. $_REQUEST is not a method, it is an array and to be more specific, a combination of $_GET, $_POST and $_COOKIES.
Re: Yep, Another login script
Posted: Mon Apr 20, 2009 4:31 pm
by temidayo
kaisellgren wrote:
temidayo wrote:If the processing of a form is idempotent (i.e. it has no lasting observable effect on the state of the world), then the form method could be `REQUEST'.
There is no such method as REQUEST. There are only (apart from custom HTTPD specific) OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE and CONNECT. $_REQUEST is not a method, it is an array and to be more specific, a combination of $_GET, $_POST and $_COOKIES.
I am not saying there is a REQUEST method. What I am saying is that where we use $_GET, will it not be safe to use $_REQUEST bearing the fact stated in the above quotation in mind?
For clarity the fact is:
temidayo wrote:If the processing of a form is idempotent (i.e. it has no lasting observable effect on the state of the world), then the form method could be `REQUEST'.
(NOTE: The adjustment to the original quotation is mine)
In this case I am talking about the method of collection of data which is the security concern in this case
Re: Yep, Another login script
Posted: Mon Apr 20, 2009 4:56 pm
by kaisellgren
temidayo wrote:then the form method could be `REQUEST'.
There are no REQUEST methods, no forms can ever be REQUEST...
If you use GET, then you retrieve data from $_GET. Likewise, if you use POST, you retrieve data from $_POST. Doing otherwise introduces security issues.
Re: Yep, Another login script
Posted: Mon Apr 20, 2009 5:18 pm
by Christopher
temidayo wrote:I am not saying there is a REQUEST method. What I am saying is that where we use $_GET, will it not be safe to use $_REQUEST bearing the fact stated in the above quotation in mind?
The problem with $_REQUEST is that is has to combine $_GET, $_POST and $_COOKIE in some order. That order can be defined in the PHP configuration so it may change from server to server. So $_GET['foo'] may overwrite $_POST['foo'] (or vice versa) as $_REQUEST['foo']. It is best to not use $_REQUEST.
Re: Yep, Another login script
Posted: Mon Apr 20, 2009 5:22 pm
by temidayo
@kaisellgren
Let me first say, I appreciate your tenacity
I really enjoyed reading your replies.
However, I still think if I can use
$_GET then I can use $_REQUEST, so long as I have a mechanism for
validating the input from them.
Maybe I'm not very keen on security, but I just find it difficult to see the
security risk. Do you have a live example of how using $_REQUEST has
resulted in an exploit or security breach?
Re: Yep, Another login script
Posted: Mon Apr 20, 2009 5:36 pm
by Benjamin
kaisellgren wrote:
If you use GET, then you retrieve data from $_GET. Likewise, if you use POST, you retrieve data from $_POST. Doing otherwise introduces security issues.
kaisellgren is correct, however it is ok to use $_REQUEST as long as you know what the security issues are and ensure that your application is not vulnerable to them. One example would be to ensure that you do not perform actions based on data or commands received via get requests. This can cause cross site scripting vulnerabilities, such as 3rd party sites being able to execute commands on behalf of your users without their knowledge.
Re: Yep, Another login script
Posted: Mon Apr 20, 2009 5:38 pm
by kaisellgren
temidayo wrote:Do you have a live example of how using $_REQUEST has
resulted in an exploit or security breach?
Let's say that you have established a web hosting business at yourhost.com. You use the following code in your hosting ACP:
Code: Select all
if (isset($_REQUEST['delete_client']))
... deletes the client ...
Your ACP (Admin Control Panel) is fully secured and all sorts of data filtering is applied as well. So, what's the problem? Now, imagine your client at hacker.yourhost.com sets a cookie:
Code: Select all
setcookie('delete_client','...',time()+3600*24*365,'/','.yourhost.com');
Now when you as an admin visit the website hacker.yourhost.com, the above cookie will be generated for you. Now, when you next time visit your ACP page, the specified client will be deleted without any action from you.
Now, there are ways to prevent that from happening, e.g. using tokens, but as you can see it involves risks as you do not implicitly ask for a specific type of a method and I can guarantee you, there are many ways of exploiting the use of $_REQUEST in a way the coder did not expect.
Using $_REQUEST opens many doors, and you really have to have a decent knowledge on security. There is very rarely a need to use $_REQUEST, so do not use it.
Re: Yep, Another login script
Posted: Mon Apr 20, 2009 6:04 pm
by jayshields
Agreed.
The only time you see $_REQUEST used in practice is due to laziness. There is no reason to expect input from any of the 3 channels (POST, GET and cookies) to provide the same data. You should expect each piece of user submitted data from one channel only.
Re: Yep, Another login script
Posted: Mon Apr 20, 2009 6:12 pm
by Benjamin
Passing the session id around is a great reason to use $_REQUEST.
Re: Yep, Another login script
Posted: Tue Apr 21, 2009 6:58 am
by Mordred
The only instance I don't use request is when I pass the login arguments, they explicitly use post, as not to end up in various logs along the way.
For everything else I can think of, $_REQUEST is no worse from a security standpoint, and it has some cool benefits. Astions gave one, there are also some tricks I use in my code to pass data from get to post and v.v. between pages.
kaisellgren, what you describe is CSRF, it doesn't get remedied by using one input mechanism over another, you should know that.
Re: Yep, Another login script
Posted: Tue Apr 21, 2009 7:24 am
by kaisellgren
RFC 2616:
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
In addition to implementing your (whoever is reading and using $_REQUEST for wrong purposes) own standards, you are risking yourself with $_REQUEST as it is known to cause troubles in scripts that mess up with super global variable orders and their meaning. E.g., a cookie on a user's PC having value "vote=5" will make the user to automatically make votes in voting booths. A cookie value could make the user to autologin on a site and cookie values in most cases overwrite GET and POST values and could perform as a DOS. For certain it is possible to code securely with $_REQUEST, but by looking at Secunia that is not nearly always the case.
Mordred wrote:kaisellgren, what you describe is CSRF, it doesn't get remedied by using one input mechanism over another, you should know that.
Of course not. I just gave an example of playing around with $_REQUEST.
Re: Yep, Another login script
Posted: Tue Apr 21, 2009 11:54 am
by Christopher
astions wrote:Passing the session id around is a great reason to use $_REQUEST.
Why?