Re: [PHP] $_POST vs $_REQUEST
Op 2/24/10 11:18 AM, Ashley Sheridan schreef: On Wed, 2010-02-24 at 07:55 +, Jochem Maas wrote: Op 2/22/10 10:49 PM, John Black schreef: On 02/22/2010 11:42 PM, Michael Shadle wrote: The difference here is you can at least have some control over the data and expect it in a certain fashion. Also the behavior of cookies vs. get vs. post are different (cookies have length and expiration limits, get has length limits, post has server confgured limits) The cookie and post/get part is all mixed up now :) I use $_COOKIE when I want cookie information but I know that the data is not to be trusted and is easily fabricated. When reading get or post I just use $_REQUEST nowadays because I don't have to care how the submitting form is written. This makes my form handling data more portable. a. if your updating/inserting/storing data for the user you should require POST in order to mitigate CSRF et al - not to mention using a nonce in your forms. b. when you use $_REQUEST like you do you assume it's either GET or POST data, but it might be COOKIE data ... which will overwrite what is sent via GET or POST in the $_REQUEST array .. which creates a potential for a denial-of-service attack on the users of a site: imagine an 'id' parameter for displaying articles, then imagine a user was tricked into loading a cookie onto his machine for your domain with the name of 'id' and a value of 1 ... said user would only ever be able to see the article referred to be id=1 if you wrote code that took the 'id' parameter from the $_REQUEST var. ... I advocate not trusting any data *and* being explicit about the input vectors on which any particular piece of data is accepted in a given context. (GET, POST and COOKIE are 3 different vectors) Which becomes a moot point if you use the request_order ini setting to specify the ordering of the overriding of variables in $_REQUEST. which I think is another bit of magic I can do without. besides you don't always have control of the ini file (and you obviously can't change this value during the running of the script as $_REQUEST is already defined) I do see what you're getting at, and yes there are concerns to be had with one global array overriding another if you don't know to look out for such a caveat. The thing is, there are many times where $_REQUEST is just perfect. Imagine a stylesheet picker, that remembers the visitors choice in a cookie. You can utilise $_REQUEST to handle the whole thing very easily, and in a way that makes sense. which would require a request_order of CPG - the opposite of what it normally is, which is a complete WTF for any new developer of the code base, all so you can save a couple of lines of very simple code. I don't think it's worth it. BUT given that you do know what all the ramification are and can control the request_order in your environment then it's true to say that in your case there is no actual problem. Thanks, Ash http://www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
sry i gotta disagree. a function that queries $_POST/$_GET first and then $_COOKIE seems much wiser to me. it consolidates all logic in the script, and making that logic obvious by syntax, rather than relying on functionality being determined by php.ini, which could well cause a new developer to lose heaps of time if he/she has to work on it.. On Wed, Feb 24, 2010 at 11:18 AM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Wed, 2010-02-24 at 07:55 +, Jochem Maas wrote: Op 2/22/10 10:49 PM, John Black schreef: On 02/22/2010 11:42 PM, Michael Shadle wrote: The difference here is you can at least have some control over the data and expect it in a certain fashion. Also the behavior of cookies vs. get vs. post are different (cookies have length and expiration limits, get has length limits, post has server confgured limits) The cookie and post/get part is all mixed up now :) I use $_COOKIE when I want cookie information but I know that the data is not to be trusted and is easily fabricated. When reading get or post I just use $_REQUEST nowadays because I don't have to care how the submitting form is written. This makes my form handling data more portable. a. if your updating/inserting/storing data for the user you should require POST in order to mitigate CSRF et al - not to mention using a nonce in your forms. b. when you use $_REQUEST like you do you assume it's either GET or POST data, but it might be COOKIE data ... which will overwrite what is sent via GET or POST in the $_REQUEST array .. which creates a potential for a denial-of-service attack on the users of a site: imagine an 'id' parameter for displaying articles, then imagine a user was tricked into loading a cookie onto his machine for your domain with the name of 'id' and a value of 1 ... said user would only ever be able to see the article referred to be id=1 if you wrote code that took the 'id' parameter from the $_REQUEST var. ... I advocate not trusting any data *and* being explicit about the input vectors on which any particular piece of data is accepted in a given context. (GET, POST and COOKIE are 3 different vectors) Which becomes a moot point if you use the request_order ini setting to specify the ordering of the overriding of variables in $_REQUEST. I do see what you're getting at, and yes there are concerns to be had with one global array overriding another if you don't know to look out for such a caveat. The thing is, there are many times where $_REQUEST is just perfect. Imagine a stylesheet picker, that remembers the visitors choice in a cookie. You can utilise $_REQUEST to handle the whole thing very easily, and in a way that makes sense. Thanks, Ash http://www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
Hi, Well people better than me (how is that possible?!) have said that $_REQUEST has the potential to open your app up to security vulnerabilities, and that it should be avoided because of that. Here's a post from Stephan Esser about it on the PHP-Internals list: http://www.mail-archive.com/intern...@lists.php.net/msg32832.html Stephan heads up the Hardened-PHP project and when it comes to security, I don't know of anyone better. So, if he advises not to use _REQUEST, it's a good idea to follow that advice. -- Richard Heyes -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Tue, 2010-02-23 at 09:19 +, Richard wrote: Hi, Well people better than me (how is that possible?!) have said that $_REQUEST has the potential to open your app up to security vulnerabilities, and that it should be avoided because of that. Here's a post from Stephan Esser about it on the PHP-Internals list: http://www.mail-archive.com/intern...@lists.php.net/msg32832.html Stephan heads up the Hardened-PHP project and when it comes to security, I don't know of anyone better. So, if he advises not to use _REQUEST, it's a good idea to follow that advice. -- Richard Heyes Well, he's only saying there that it 'most probably vulnerable' and mentions that cookies can overwrite post and get data. This isn't a problem with $_REQUEST itself but rather an applications' use of it. So what if someone crafts a cookie to send a bad value. If someone has the gen to do that, then they are going to know how to send get and post values as well. Only decent sanitisation will be able to protect against this. If the order of override variables in $_REQUEST is such an issue too, use the request_order ini setting to specify the order you'd prefer. I've never had any issues with using $_REQUEST, but found a lot of advantages to using it, as I often use a mix of data sources in the same app. Thanks, Ash http://www.ashleysheridan.co.uk
RE: [PHP] $_POST vs $_REQUEST
From: Rene Veerman [mailto:rene7...@gmail.com]
On Mon, Feb 22, 2010 at 9:39 PM, Slack-Moehrle
Single quotes is best, correct to prevent sql injection?
sql injection fixing is an evolving art, but you can start by pushing
all variables that can be changed by end-users going into a database
through a marshalling-function fixSQLinjectionToDB ($var) { return
addslashes($var); };
addslashes is the minimum fix i believe, but google around and give us
back the up-to-date uber-fix-function please :)
Slash is the wrong character. The correct SQL escape character is the
single quote.
The best way to prepare text fields is to use the DB specific escape
functions on each text field before assembling the command string, i.e.
pg_escape_string(). But that is after all fields have been sanitized and
validated.
In addition, if magic_quotes is turned on, you also need to remove them
before doing the validation. The contributed notes in the online manual
have some good suggestions on how to accomplish this.
Bob McConnell
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
At 11:07 PM +0100 2/22/10, John Black wrote: On 02/22/2010 10:37 PM, Michael Shadle wrote: On Mon, Feb 22, 2010 at 1:30 PM, David Murphyda...@icewatermedia.com wrote: Richard, The use of $_REQUEST it no more a security hole than $_GET or $_REQUEST, they should ALL be treats as bad data until normalized and sanitized. The claim that it opens a security hole is just false, that's like saying PHP is insecure, its not it just allows for lazy coding such as $_REQUEST. It represents a way for people to exploit coders who don't know any better. Expecting a cookie value to come through in $_REQUEST but you could override using a query string parameter makes for easy exploitation. And how is this more secure? I can create a cookie, send post or get on my client machine and send anything I want to the server. Just because you are getting a cookie does not mean that you created it :) So you might as well use request because the data can not be trusted either way. -- John It is true that you cannot trust any data coming from a client (i.e., POST, GET, COOKIE, REQUEST, Whatever). However, in trying to secure what you are doing it makes sense to know specifically the origin of your data. Additionally, if you know specifically where your data is coming from, then there are no surprises as there can be by using REQUEST. I am sure you realize that the data provided by a REQUEST can be overridden by processes you may have not accounted for. For example, while you are thinking that the data you're working on was provided by one super global it actually was overridden by another can lead to problems, including security. One security directive is to keep the process simple and under control. The more complicated you make it, the less secure it becomes regardless of the method of data collection. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
Op 2/23/10 10:27 AM, Ashley Sheridan schreef: On Tue, 2010-02-23 at 09:19 +, Richard wrote: Hi, Well people better than me (how is that possible?!) have said that $_REQUEST has the potential to open your app up to security vulnerabilities, and that it should be avoided because of that. Here's a post from Stephan Esser about it on the PHP-Internals list: http://www.mail-archive.com/intern...@lists.php.net/msg32832.html Stephan heads up the Hardened-PHP project and when it comes to security, I don't know of anyone better. So, if he advises not to use _REQUEST, it's a good idea to follow that advice. -- Richard Heyes Well, he's only saying there that it 'most probably vulnerable' and mentions that cookies can overwrite post and get data. This isn't a problem with $_REQUEST itself but rather an applications' use of it. So what if someone crafts a cookie to send a bad value. If someone has the gen to do that, then they are going to know how to send get and post values as well. Only decent sanitisation will be able to protect against this. If the order of override variables in $_REQUEST is such an issue too, use the request_order ini setting to specify the order you'd prefer. I've never had any issues with using $_REQUEST, but found a lot of advantages to using it, as I often use a mix of data sources in the same app. and that is exactly Essers point. you use $_REQUEST and assume the data came from either GET or POST ... I'd hazard a guess your apps never expect such 'mixed' data to be coming via COOKIE ... so your app will work as 'advertised' but if some one happens to slip a cookie onto someone else machine whose name matches some rather important GET/POST input then it's that user who potentially has just suffered a denial of service - and you'll get the blame for the fact things don't work and you'll probably never be able to work out that it's a rogue cookie on the client putting a spanner in the works. (imagine you have an 'id' parameter and I managed to set a cookie on your users' machine called 'id' with a value of 1 ... have fun with that) you should be as strict with exceptable input vectors as you are with sanitisation of the actual input. use of $_REQUEST is rather lazy - if you want to except either POST or GET for a given input write a simple wrapper function for that specific requirement - this will also save you from unforeseen problems related to incorrect or changed values for the request_order ini setting. Thanks, Ash http://www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
Hi, I have Forms that I submit for processing. I have seen examples of people using either $_POST or $_REQUEST. When would I choose one over the other? It's a wise choice to go with $_POST, unless your form is a GET form, in which case use $_GET. $_REQUEST has the potential to open your script(s) up to security issues. ... Use quoted strings - either single or double quotes. Eg: $myArray['myKey'] $myArray[myKey] -- Richard Heyes HTML5 canvas graphing: RGraph - http://www.rgraph.net (updated 20th February) Lots of PHP and Javascript code - http://www.phpguru.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Tue, Feb 23, 2010 at 2:39 AM, Slack-Moehrle mailingli...@mailnewsrss.com wrote: Hi All, I have Forms that I submit for processing. I have seen examples of people using either $_POST or $_REQUEST. When would I choose one over the other? Also, I see examples of these being used with and without the single quotes Like: $_POST[j_orderValue] or $_POST['j_orderValue'] Single quotes is best, correct to prevent sql injection? You must use quote. either single or double. It wont affect sql injection. Sanitize your data before using it in any sql. $_REQUEST['var'] means a variable var was passed in http request. $_POST['var'] means a post variable var was passed in http request. A get or cookie variable var2 will set $_REQUEST['var2']. When you are strictly expecting a Post variable 'var3' use $_POST['var3'], not $_REQEUST['var3']. This is because a $_GET['var3'] will make $_REQEUST['var3'] available to you which is not what you want. Correct me if I am wrong. -- Shiplu Mokaddim My talks, http://talk.cmyweb.net Follow me, http://twitter.com/shiplu SUST Programmers, http://groups.google.com/group/p2psust Innovation distinguishes bet ... ... (ask Steve Jobs the rest) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
Richard wrote: It's a wise choice to go with $_POST, unless your form is a GET form, in which case use $_GET. $_REQUEST has the potential to open your script(s) up to security issues. I am not sure what the security issues are you are referring to as the $_REQUEST superglobal contains both $_GET and $_POST values. Could you expound on that? Thanks. Use quoted strings - either single or double quotes. Eg: $myArray['myKey'] $myArray[myKey] To answer your question though, the quotes will not protect you from SQL injection at all. It simply has to do with processing the values. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Mon, Feb 22, 2010 at 9:39 PM, Slack-Moehrle
mailingli...@mailnewsrss.com wrote:
Hi All,
I have Forms that I submit for processing. I have seen examples of people
using either $_POST or $_REQUEST.
When would I choose one over the other?
I like to be specific and go for $_POST, but some people want
flexibility in their code and use $_REQUEST.
It's usually no big deal to me.
Also, I see examples of these being used with and without the single quotes
Like:
$_POST[j_orderValue]
or
$_POST['j_orderValue']
i'd expect without quotes to query a define('j_orderValue','??')..
and yea, use single quotes whereever possible..
it's my exp that
'bla bla $var da da' is harder to read (in syntax-highlighted source
editors) than
'bla bla '.$var.' da da'
that's aside from speed improvements, which do add up quickly in high
load situations.
Single quotes is best, correct to prevent sql injection?
sql injection fixing is an evolving art, but you can start by pushing
all variables that can be changed by end-users going into a database
through a marshalling-function fixSQLinjectionToDB ($var) { return
addslashes($var); };
addslashes is the minimum fix i believe, but google around and give us
back the up-to-date uber-fix-function please :)
Might be wise to look ahead and use a unmarshalling function
placeholder fixSQLinjectionFromDB() for any (varchar/text) variable
coming from the database and being used by your program for anything.
You'll have to look ahead; if you allow endusers to store any text in
your database, you can't just re-use that text in your output HTML
another time. you will need something that strips bad html, imgs,
flash, and javascript, to be completely secure. I've once been
infected with a piece of very cryptic js (that loaded quite a bit more
into the browser) that caused my site to be blacklisted by google..
Big fat red-black warnings by firefox about it too..
lastly, it also helps to use something like adodb.sf.net as a database
abstraction engine, btw.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On 02/22/2010 09:39 PM, Slack-Moehrle wrote:
Hi All,
I have Forms that I submit for processing. I have seen examples of people using
either $_POST or $_REQUEST.
When would I choose one over the other?
When you don't care how you get the data use $_REQUEST.
$_REQUEST will contain $_GET,$_POST,$_COOKIE in the order specified in
php.ini. Don't know what the default is.
$_POST[j_orderValue]
Don't do that, PHP will bitch that you are attempting to use a constant
as a string or something like that. Make sure you enable error reporting
in php.ini and use
display_errors = On
error_reporting = E_ALL | E_STRICT
for development but not on your server unless you log only.
$_POST['j_orderValue']
There are a few ways to write this properly, depending on how you use
it. The above is how I usually use it but this is also possible.
x = $_POST['j_orderValue'] = that is how I write it
x = $_POST[j_orderValue] = also ok because it is a stirng
for $x=0; $x 10, $x++ )
$foo[$x] = $_POST[j_orderValue$x]
is also possible
echo foo $_POST[j_orderValue];
echo foo {$_POST['j_orderValue']};
and a few more, there was a great thread a while back which listed
every possible combination.
Single quotes is best, correct to prevent sql injection?
SQL injects happen when you use the $_RESQUEST[] information, as is, in
your SQL string.
SELECT * FROM foo WHERE XXX=$_REQUEST['yyy'] = very bad!
You should be doing:
... code sanity check here.
- is a number really number, length and so on ...
Then if you use a MySQL database you would escape the string like this
$tmp = mysql_real_escape_string($_REQUEST['yyy']);
and use it like this.
SELECT * FROM foo WHERE XXX=$tmp
mysql_real_escape_string() protect from SQL injection by escaping your
string according to what your charset requires.
--
John
Nur wer im Wohlstand lebt, schimpft auf ihn.
[Ludwig Marcuse]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
i'd expect without quotes to query a define('j_orderValue','??')..
oh, and that, if not defined, defaults to the string 'j_orderValue'.
So while your $_POST[] with or without quotes will do the same, use
single-quotes anyway because it's the right thing to do ;)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
Hi, I am not sure what the security issues are you are referring to as the $_REQUEST superglobal contains both $_GET and $_POST values. Could you expound on that? Thanks. Not really, do a search. -- Richard Heyes HTML5 canvas graphing: RGraph - http://www.rgraph.net (updated 20th February) Lots of PHP and Javascript code - http://www.phpguru.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
Hi Slack-Moehrle
Slack-Moehrle wrote on 22/02/2010 21:39:
Hi All,
I have Forms that I submit for processing. I have seen examples of people using
either $_POST or $_REQUEST.
When would I choose one over the other?
$_REQUEST['test'] is true on both $_GET['test'] and $_POST['test']
I use it from time to time if I have a edit link followed by a form
posting (where I use method=post), if I decide to have all editing in
one statement, IE:
if($_REQUEST['test']) {
if($_GET['test']) {
// make the form here
}
elseif($_POST['test']) {
// get posting from the form
}
}
Also, I see examples of these being used with and without the single quotes
Like:
$_POST[j_orderValue]
or
$_POST['j_orderValue']
Single quotes is best, correct to prevent sql injection?
Best practice is with '', if you have E_NOTICE on you'll get notices if
you use $_POST[test] instead of $_POST['test']
It has nothing to do with SQL injection here. But when dealing with SQL
statements it's best practice to use '', for instance if you are about
to insert and a number at some point could be inserted as part of the
statement: price = 250 will do fine, but if price ain't entered price
= will cause an error, while price = '' will not make the sql insert
fail.
Regarding SQL injection, run all inputs through the function
mysql_real_escape_string()
--
Kind regards
Kim Emax - masterminds.dk
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
I have Forms that I submit for processing. I have seen examples of people using either $_POST or $_REQUEST. Look at this example: form action=page.php?foo=bar input type=hidden name=foo value=pub /form Now what do you thing $_REQUEST will return? You had better not even think. Just use $_POST or $_GET as you _know_ what they will return. Don't forget, there might even be a cookie with the name foo. -- Dotan Cohen http://bido.com http://what-is-what.com Please CC me if you want to be sure that I read your message. I do not read all list mail. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Mon, Feb 22, 2010 at 12:55 PM, Joseph Thayne webad...@thaynefam.org wrote: I am not sure what the security issues are you are referring to as the $_REQUEST superglobal contains both $_GET and $_POST values. Could you expound on that? Thanks. $_REQUEST opens you up to POST/GET values overriding cookie values or vice versa. It's best to choose your source of data specifically. I unset($_REQUEST) wherever I can to enforce stricter coding practices. To me it's lazy. If you really need to mix POST and GET, then you can always array_merge($_POST, $_GET) Use quoted strings - either single or double quotes. Eg: $myArray['myKey'] $myArray[myKey] single quotes are better (by a marginal fraction) as it won't look for interpolated strings :) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] $_POST vs $_REQUEST
Richard, The use of $_REQUEST it no more a security hole than $_GET or $_REQUEST, they should ALL be treats as bad data until normalized and sanitized. The claim that it opens a security hole is just false, thats like saying PHP is insecure, its not it just allows for lazy coding such as $_REQUEST. David Murphy -Original Message- From: richard.he...@gmail.com [mailto:richard.he...@gmail.com] On Behalf Of Richard Sent: Monday, February 22, 2010 3:03 PM To: Joseph Thayne Cc: Slack-Moehrle; php-general Subject: Re: [PHP] $_POST vs $_REQUEST Hi, I am not sure what the security issues are you are referring to as the $_REQUEST superglobal contains both $_GET and $_POST values. Could you expound on that? Thanks. Not really, do a search. -- Richard Heyes HTML5 canvas graphing: RGraph - http://www.rgraph.net (updated 20th February) Lots of PHP and Javascript code - http://www.phpguru.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Mon, Feb 22, 2010 at 1:30 PM, David Murphy da...@icewatermedia.com wrote: Richard, The use of $_REQUEST it no more a security hole than $_GET or $_REQUEST, they should ALL be treats as bad data until normalized and sanitized. The claim that it opens a security hole is just false, that’s like saying PHP is insecure, its not it just allows for lazy coding such as $_REQUEST. It represents a way for people to exploit coders who don't know any better. Expecting a cookie value to come through in $_REQUEST but you could override using a query string parameter makes for easy exploitation. Probably not catastrophic but much easier to brute force things if you don't have to bother with cookies, or can fake a user identity easier; things of that nature. If you coded your app well, in theory it won't make much difference, however, why keep something out there that makes it easier for people to mess with your site, period? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
John, Then if you use a MySQL database you would escape the string like this $tmp = mysql_real_escape_string($_REQUEST['yyy']); mysql_real_escape_string() protect from SQL injection by escaping your string according to what your charset requires. Good point, I should be doing that. But only to String, not data stored in MySQL as Int or Date, etc. -ML -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On 02/22/2010 10:37 PM, Michael Shadle wrote: On Mon, Feb 22, 2010 at 1:30 PM, David Murphyda...@icewatermedia.com wrote: Richard, The use of $_REQUEST it no more a security hole than $_GET or $_REQUEST, they should ALL be treats as bad data until normalized and sanitized. The claim that it opens a security hole is just false, that’s like saying PHP is insecure, its not it just allows for lazy coding such as $_REQUEST. It represents a way for people to exploit coders who don't know any better. Expecting a cookie value to come through in $_REQUEST but you could override using a query string parameter makes for easy exploitation. And how is this more secure? I can create a cookie, send post or get on my client machine and send anything I want to the server. Just because you are getting a cookie does not mean that you created it :) So you might as well use request because the data can not be trusted either way. -- John Gerechtigkeit entspringt dem Neid; denn ihr oberster Grundsatz ist: Allen das Gleiche. [Walther Rathenau] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Mon, Feb 22, 2010 at 2:07 PM, John Black s...@network-technologies.org wrote: And how is this more secure? I can create a cookie, send post or get on my client machine and send anything I want to the server. Just because you are getting a cookie does not mean that you created it :) So you might as well use request because the data can not be trusted either way. Kind of like saying why bother exercising and keeping healthy - we're going to die anyway Secure might be the wrong term here. As you can easily change GET to POST and vice-versa and send any cookies you like, this is why I tried to revise my statement and quantify it better... in a properly coded app it doesn't present much issue. However, it encourages laziness and PHP's barrier to entry is so easy that there is a lot of people who consider a cookie to be trusted, and overriding it with a simple GET parameter is too easy of an attack vector. At least make it difficult. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Mon, Feb 22, 2010 at 5:02 PM, Slack-Moehrle mailingli...@mailnewsrss.com wrote: John, Then if you use a MySQL database you would escape the string like this $tmp = mysql_real_escape_string($_REQUEST['yyy']); mysql_real_escape_string() protect from SQL injection by escaping your string according to what your charset requires. Good point, I should be doing that. But only to String, not data stored in MySQL as Int or Date, etc. -ML Just to clarify, while you would not use mysql_real_escape_string() for datatypes other than strings, you still need to do filtering, validation, and sanity checking on other datatypes as well. As I pointed out in another thread recently, these are just as vulnerable to SQL injection even though the variable values are expected to be integers or dates: $sql = SELECT `my_id`, `my_message` FROM `my_comments` WHERE `my_id` = $my_id; $sql = SELECT `post_id`, `post_text`, `post_date` FROM `blog_posts` WHERE `post_date` BETWEEN '$first_post_date' AND '$last_post_date'; IMO mysql_real_escape_string() (or any similar function used for different db vendors) is just a method to escape sequences that have special meaning in a SQL query. It is the LAST step you should perform when processing input to be saved in a MySQL database (when parameterized queries are not available), after you have done everything you can to ensure that ALL the values being passed in the query are valid. Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On 02/22/2010 11:17 PM, Michael Shadle wrote: Secure might be the wrong term here. As you can easily change GET to POST and vice-versa and send any cookies you like, this is why I tried to revise my statement and quantify it better... in a properly coded app it doesn't present much issue. However, it encourages laziness and PHP's barrier to entry is so easy that there is a lot of people who consider a cookie to be trusted, and overriding it with a simple GET parameter is too easy of an attack vector. At least make it difficult. Just because someone believes that a cookie is something that can be trusted does not make it so. A properly coded app should not care how the client sends the information, only that the information is it valid and expected. A cookie is the same thing as $_POST or $_GET data but it can be stored for a period of time, what happens to the stored data is out of our control. Treating one any different from the other is just wrong and will create apps with security holes. For anybody who would like to try the GUI version of tampering with data sent to the server checkout TamperData for FireFox. -- John Klarmachen zum Ändern! http://www.youtube.com/v/AYM-_qfytfA -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Mon, Feb 22, 2010 at 22:37, Michael Shadle mike...@gmail.com wrote: On Mon, Feb 22, 2010 at 1:30 PM, David Murphy da...@icewatermedia.com wrote: Richard, The use of $_REQUEST it no more a security hole than $_GET or $_REQUEST, they should ALL be treats as bad data until normalized and sanitized. The claim that it opens a security hole is just false, that’s like saying PHP is insecure, its not it just allows for lazy coding such as $_REQUEST. It represents a way for people to exploit coders who don't know any better. Expecting a cookie value to come through in $_REQUEST but you could override using a query string parameter makes for easy exploitation. Probably not catastrophic but much easier to brute force things if you don't have to bother with cookies, or can fake a user identity easier; things of that nature. If you coded your app well, in theory it won't make much difference, however, why keep something out there that makes it easier for people to mess with your site, period? Using $_REQUEST poses no security issues whatsoever. Just because there are incompetent programmers doesn't mean that a language feature is inherently insecure. It's entirely dependent on how you use it. A pen is also dangerous if you stab someone in the eye with it. Certain features in PHP may be dangerous if you give them to incompetent people who don't know what they're doing. Besides, whether or not you can override cookie values depends on whether the programmer also uses $_REQUEST for cookie values and the request_order php.ini directive. The value in the php.ini files that ship with PHP 5.3 default to only including GET and POST data for instance: http://svn.php.net/viewvc/php/php-src/tags/php_5_3_1/php.ini-production?view=markup#l671 If an attacker can do an HTTP GET request, he can most likely also do an HTTP POST request (and vice versa) and the input value will be no more (in)secure regardless of the source. Using $_GET/$_POST in place of $_REQUEST is no more than security theater in my opinion. -- Daniel Egeberg -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
The difference here is you can at least have some control over the data and expect it in a certain fashion. Also the behavior of cookies vs. get vs. post are different (cookies have length and expiration limits, get has length limits, post has server confgured limits) Like I said a properly coded app won't really suffer much but why allow for lazy coding practices and non properly coded apps to be exploited as easy? The great deal of apps out there are not properly coded. Again I reference my metaphor about dying. At least try to put effort into something. On Feb 22, 2010, at 2:26 PM, John Black s...@network- technologies.org wrote: On 02/22/2010 11:17 PM, Michael Shadle wrote: Secure might be the wrong term here. As you can easily change GET to POST and vice-versa and send any cookies you like, this is why I tried to revise my statement and quantify it better... in a properly coded app it doesn't present much issue. However, it encourages laziness and PHP's barrier to entry is so easy that there is a lot of people who consider a cookie to be trusted, and overriding it with a simple GET parameter is too easy of an attack vector. At least make it difficult. Just because someone believes that a cookie is something that can be trusted does not make it so. A properly coded app should not care how the client sends the information, only that the information is it valid and expected. A cookie is the same thing as $_POST or $_GET data but it can be stored for a period of time, what happens to the stored data is out of our control. Treating one any different from the other is just wrong and will create apps with security holes. For anybody who would like to try the GUI version of tampering with data sent to the server checkout TamperData for FireFox. -- John Klarmachen zum Ändern! http://www.youtube.com/v/AYM-_qfytfA -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
Op 2/22/10 8:39 PM, Slack-Moehrle schreef: Hi All, I have Forms that I submit for processing. I have seen examples of people using either $_POST or $_REQUEST. When would I choose one over the other? use $_POST, $_REQUEST is normally an amalgam of GET, POST and COOKIE - as such using $_REQUEST can open you up to a denial of service attack (if someone manages to place cookies with the same names as your form fields they will always override what was in the POST). avoid using $_REQUEST. Also, I see examples of these being used with and without the single quotes Like: $_POST[j_orderValue] this generates an E_NOTICE and is bad practice, it's also slower, essentially PHP sees the CONSTANT j_orderValue which it can't find and does it's best to accomodate sloppy code by tranlating it into the string 'j_orderValue' try turning up the ini setting 'error_reporting' to include E_NOTICE warnings (and everything else) and see what else your code might be doing which isn't quite right ... it can be very helpful, I'm assuming you're running a local webserver, as running that in production is a bit pointless in my view (additionally having the ini setting 'display_errors' turned on in production is a security issue) or $_POST['j_orderValue'] Single quotes is best, correct to prevent sql injection? this does nothing for SQL injection prevention, for that you need the escaping function for the DB you use ... for MySQL that would be mysql_real_escape_string(). -ML -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On 02/22/2010 11:42 PM, Michael Shadle wrote: The difference here is you can at least have some control over the data and expect it in a certain fashion. Also the behavior of cookies vs. get vs. post are different (cookies have length and expiration limits, get has length limits, post has server confgured limits) The cookie and post/get part is all mixed up now :) I use $_COOKIE when I want cookie information but I know that the data is not to be trusted and is easily fabricated. When reading get or post I just use $_REQUEST nowadays because I don't have to care how the submitting form is written. This makes my form handling data more portable. -- John You may say I'm a dreamer, but I'm not the only one, I hope some day you'll join us, And the world will live as one. [John Lennon] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vs $_REQUEST
On Mon, 2010-02-22 at 23:49 +0100, John Black wrote: On 02/22/2010 11:42 PM, Michael Shadle wrote: The difference here is you can at least have some control over the data and expect it in a certain fashion. Also the behavior of cookies vs. get vs. post are different (cookies have length and expiration limits, get has length limits, post has server confgured limits) The cookie and post/get part is all mixed up now :) I use $_COOKIE when I want cookie information but I know that the data is not to be trusted and is easily fabricated. When reading get or post I just use $_REQUEST nowadays because I don't have to care how the submitting form is written. This makes my form handling data more portable. -- John You may say I'm a dreamer, but I'm not the only one, I hope some day you'll join us, And the world will live as one. [John Lennon] As many people have mentioned already, there's absolutely no security risk of using $_REQUEST over $_POST or $_GET. I generally use $_REQUEST unless I am specifically coding something that needs me to send data over both post and get at the same time. The thing is, just make sure you sanitise all the data that comes from the browser. That includes cookie values, post data, etc. Proper sanitisation is crucial and necessary, and no amount of obscurity about how you are getting your data will help. Thanks, Ash http://www.ashleysheridan.co.uk
