On Jan 17, 2008, at 10:17 , Stefan Esser wrote:
When someone injects you a cookie like +++action=logout through an
XSS or through a feature like foobar.co.kr can set cookies for
*.co.kr
(in FF atleast).
Ok, you are assuming one security issue here, that is not related to
the topic.
Hello Lukas,
Ah ok .. sorry for having missed that point. Of course I was assuming
that the feature worked as advertised. I guess I was thrown off by the
fact that Stefan initially made it sound like the concept in general
is flawed and would automatically make an application insecure.
On Thu, Jan 17, 2008 at 10:17:18AM +0100, Stefan Esser wrote:
So you see that you nearly NEVER ever want the cookie in _REQUEST. And
even if you can think up a theoretical situation where you don't care
the problem is that everyone else uses _REQUEST in unsafe places...
Therefore my
On Wed, January 16, 2008 12:54 am, Stefan Priebsch wrote:
Richard Lynch schrieb:
If a web service really doesn't care whether it is responding to GET
or POST or even forged COOKIES to product its output, why would it
not
just use REQUEST?
It's not as if it's any harder to forge GET vs. POST
On Wed, January 16, 2008 1:45 am, Stefan Esser wrote:
Stefan Priebsch schrieb:
Richard Lynch schrieb:
If a web service really doesn't care whether it is responding to
GET
or POST or even forged COOKIES to product its output, why would it
not
just use REQUEST?
It's not as if it's any
On Wed, January 16, 2008 2:17 pm, Stefan Esser wrote:
It would have been a good idea to have such a configuration option
that
allows to specify what is in _REQUEST and what not...
Perhaps it would be wise to add yet another php.ini setting?
[Yeah, I know the usual response to that. Just think
@Richard: You don't understand the Problem with _REQUEST. It is not
about the fact that someone can forge GET, POST; COOKIE variables.
It is about the fact that COOKIEs will overwrite GET and POST data in
REQUEST.
Isn't it solved by setting variables_order to correct value, at least
partially?
Stanislav Malyshev wrote:
@Richard: You don't understand the Problem with _REQUEST. It is not
about the fact that someone can forge GET, POST; COOKIE variables.
It is about the fact that COOKIEs will overwrite GET and POST data in
REQUEST.
Isn't it solved by setting variables_order to correct
Stanislav Malyshev schrieb:
@Richard: You don't understand the Problem with _REQUEST. It is not
about the fact that someone can forge GET, POST; COOKIE variables.
It is about the fact that COOKIEs will overwrite GET and POST data in
REQUEST.
Isn't it solved by setting variables_order to
Changing the variables_order to CGP is not a good idea either, because
then applications that use cookies through _REQUEST could be tricked by
I can imagine why one would use _REQUEST to work with GET and POST
alike. However I can not imagine what would be the reason to use REQUEST
if you
On Jan 16, 2008, at 9:17 , Stefan Esser wrote:
Stanislav Malyshev schrieb:
@Richard: You don't understand the Problem with _REQUEST. It is not
about the fact that someone can forge GET, POST; COOKIE variables.
It is about the fact that COOKIEs will overwrite GET and POST data
in
REQUEST.
I dont understand the problem. You use request if you do not care where
a parameter is set and you use the other superglobals when you do care.
The problem is that variables_order should specify what gets into
_REQUEST (as documented in the manual) and as Stefan reports it doesn't
exactly do
On Jan 16, 2008, at 11:55 , Stanislav Malyshev wrote:
I dont understand the problem. You use request if you do not care
where a parameter is set and you use the other superglobals when
you do care.
The problem is that variables_order should specify what gets into
_REQUEST (as documented
On Sat, January 5, 2008 2:48 pm, Stefan Esser wrote:
Hello,
typing into PHP, even if it is optional. Passing $_REQUEST['age']
to a
that $_REQUEST['age'] has been checked for numeric before the
functio
would you please not use $_REQUEST in any of your examples? $_REQUEST
is
one of the
Richard Lynch schrieb:
If a web service really doesn't care whether it is responding to GET
or POST or even forged COOKIES to product its output, why would it not
just use REQUEST?
It's not as if it's any harder to forge GET vs. POST vs. COOKIE data,
really.
You can easily have sombeody
Stefan Priebsch schrieb:
Richard Lynch schrieb:
If a web service really doesn't care whether it is responding to GET
or POST or even forged COOKIES to product its output, why would it not
just use REQUEST?
It's not as if it's any harder to forge GET vs. POST vs. COOKIE data,
really.
I am
On Jan 6, 2008 5:06 AM, Stefan Esser [EMAIL PROTECTED] wrote:
Hello Daniel,
It may be off-topic for the initial post, but I disagree
wholeheartedly with the above statement, Stefan. There are
innumerable reasons where $_REQUEST would be much more economic than
writing out all
Hello Daniel,
It may be off-topic for the initial post, but I disagree
wholeheartedly with the above statement, Stefan. There are
innumerable reasons where $_REQUEST would be much more economic than
writing out all conditions for $_POST, $_GET, $_SESSION, $_COOKIE
it doesn't
On Sat, Jan 05, 2008 at 09:48:37PM +0100, Stefan Esser wrote:
Hello,
typing into PHP, even if it is optional. Passing $_REQUEST['age'] to a
that $_REQUEST['age'] has been checked for numeric before the functio
would you please not use $_REQUEST in any of your examples? $_REQUEST
Hello,
typing into PHP, even if it is optional. Passing $_REQUEST['age'] to a
that $_REQUEST['age'] has been checked for numeric before the functio
would you please not use $_REQUEST in any of your examples? $_REQUEST is
one of the biggest design weaknesses in PHP. Every application
opinion) reason why type hinting should NOT be introduced. BTW accepting
the string '1' where an (int) type hint is placed would be the next
stupid design decision.
Why
Because type hinting is supposed to limit what kind of variable type is
allowed for a parameter. When you magically
On Sat, Jan 05, 2008 at 10:13:29PM +0100, Stefan Esser wrote:
opinion) reason why type hinting should NOT be introduced. BTW accepting
the string '1' where an (int) type hint is placed would be the next
stupid design decision.
Why
Because type hinting is supposed to limit what
Also,
function foo(SomeClass $obj) would error out if passed something other
than a SomeClass instance, while
function foo(int $number) would just cast $number to int.
Not really intuitive and not really consistent.
Regards,
Vlad Bosinceanu
Stefan Esser wrote:
Hello,
typing into PHP,
On Jan 5, 2008 3:48 PM, Stefan Esser [EMAIL PROTECTED] wrote:
Hello,
typing into PHP, even if it is optional. Passing $_REQUEST['age'] to a
that $_REQUEST['age'] has been checked for numeric before the functio
would you please not use $_REQUEST in any of your examples? $_REQUEST is
one
Because type hinting is supposed to limit what kind of variable type
is
allowed for a parameter. When you magically convert you kill the whole
idea of type hints and replace it with some magical function parameter
auto type conversion, which would be another hard to understand magic
feature
On Sun, 2008-01-06 at 01:11 +0200, Vlad Bosinceanu wrote:
Also,
function foo(SomeClass $obj) would error out if passed something other
than a SomeClass instance, while
function foo(int $number) would just cast $number to int.
Not really intuitive and not really consistent.
My patch does
On Sat, 2008-01-05 at 15:59 -0800, Mike Lively wrote:
Because type hinting is supposed to limit what kind of variable type
is
allowed for a parameter. When you magically convert you kill the whole
idea of type hints and replace it with some magical function parameter
auto type
On Sat, 2008-01-05 at 21:35 -0500, Sam Barrow wrote:
On Sat, 2008-01-05 at 15:59 -0800, Mike Lively wrote:
Because type hinting is supposed to limit what kind of variable type
is
allowed for a parameter. When you magically convert you kill the whole
idea of type hints and replace it
Mike Lively wrote:
That being said I still do agree with Stefan that changing the type of a
variable would be aweful. I do know that for any purpose I have for
additional type hinting would actually be solved by just introducing
type hints for 'scalar' (read string or int) and 'resource'.
If
29 matches
Mail list logo
