[PHP-DB] Re: [PHP] Re: [PHP-DB] Re: [PHP] Passing variables to a PHP script on clicking a hyperlink
On Fri, August 24, 2007 3:20 am, Goltsios Theodore wrote: Please do not encourage the use of $_REQUEST. You might as well just tell people to enable register_globals again. This is *SO* not correct at all! $_REQUEST[] is merely array_merge($_GET, $_POST, $_COOKIE); It is *NOT* in any way, shape, or form, polluting the global namespace of all your variables, which is what register_globals is. Don't use http://php.net/extract on $_REQUEST would be the same as enabling register_globals again. There is no real difference from a SECURITY stand-point between GET or POST or COOKIE. They are all equally trivial to inject any data the user chooses. Using $_GET versus $_POST (versus $_COOKIE) is an issue of code clarity -- You know that the data is expected to come from the URL or the POST data. It is not, repeat not, an issue of Security. There could easily be a script written which is expected to respond to GET or POST data in the same way, particularly a simplistic web-service that doesn't really care if the web Designers prefer to have buttons or links or CSS links that look like buttons or CSS buttons that look like links or rabid squirrels that send the GET and/or POST data to make the HTTP request. So the blanket statement to never use $_REQUEST is probably ill-advised. Use $_POST when you expect the data to always be in POST data. Use $_GET when you expect the data to alwasy be in GET data. If you actually want to accept HTTP requests of either kind for flexibility to an external user, by all means use REQUEST. You must, of course, also factor in that you should never ever use POST for a non-idempotent operation. Or, in layman's terms, if the script *changes* data, use POST and not GET. That is a totally separate reason to choose POST over GET or vice versa. ymmv naiaa ianal -- 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/browse/from/lynch Yeah, I get a buck. So? -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Re: [PHP] Re: [PHP-DB] Re: [PHP] Passing variables to a PHP script on clicking a hyperlink
On 8/26/07, Richard Lynch [EMAIL PROTECTED] wrote: This is *SO* not correct at all! $_REQUEST[] is merely array_merge($_GET, $_POST, $_COOKIE); Yes and it mimics being lazy - allowing overriding values from $_POST vs. $_GET vs. $_COOKIE depending on what the programmer wants to trust It encourages poor practices. There is no reason to not name the proper source of data - i.e. i want it from POST not GET It is *NOT* in any way, shape, or form, polluting the global namespace of all your variables, which is what register_globals is. That is why I said it was *one* reason register_globals was disabled - global namespace was probably the biggest reason, but also variable overriding and sloppyness allowing for exploits was probably up there too. There could easily be a script written which is expected to respond to GET or POST data in the same way, particularly a simplistic web-service that doesn't really care if the web Designers prefer to have buttons or links or CSS links that look like buttons or CSS buttons that look like links or rabid squirrels that send the GET and/or POST data to make the HTTP request. Yes, there could. But part of that would rely on a *very* motivated end-user (or we'll call them hacker) - they would probably find a way in or do what they want either way. There's no reason to make it easier just because well they can hack something up to do that anyway - that's a Microsoft approach to security. Whatever happened to people at least trying to discourage abuse or issues. I have never used $_REQUEST and my applications don't seem to have any issues. Obviously someone could have tried to switch POST/GET on me, but I still ensure proper bounds checking/sanity checking/type checking/etc. But I would not allow someone to issue a GET variable to override a cookie value without having to make the extra effort (and furthermore understand how the variables work on the server side to make it actually work how they want.) Use $_POST when you expect the data to always be in POST data. correct. Use $_GET when you expect the data to alwasy be in GET data. correct. If you actually want to accept HTTP requests of either kind for flexibility to an external user, by all means use REQUEST. In my opinion a properly coded web application shouldn't be lazy and should know the source of data. So I consider this incorrect. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Re: [PHP] Re: [PHP-DB] Re: [PHP] Passing variables to a PHP script on clicking a hyperlink
On Sun, August 26, 2007 6:37 pm, mike wrote: On 8/26/07, Richard Lynch [EMAIL PROTECTED] wrote: It is *NOT* in any way, shape, or form, polluting the global namespace of all your variables, which is what register_globals is. That is why I said it was *one* reason register_globals was disabled - global namespace was probably the biggest reason, but also variable overriding and sloppyness allowing for exploits was probably up there too. I'll say it again: regsiter_globals has *NOTHING* to do with $_REQUEST. Zero. Zilch. Nada. Zip. There could easily be a script written which is expected to respond to GET or POST data in the same way, particularly a simplistic web-service that doesn't really care if the web Designers prefer to have buttons or links or CSS links that look like buttons or CSS buttons that look like links or rabid squirrels that send the GET and/or POST data to make the HTTP request. Yes, there could. But part of that would rely on a *very* motivated end-user (or we'll call them hacker) - they would probably find a way in or do what they want either way. No, it only relies on one Designer who wants their request to look like a FORM and another Designer who wants their request to look like a link. And I don't really *CARE* if the search terms (or whatever input it its) comes from GET versus POST as there is NO Security difference whatsoever. They need equal filtration. There's no reason to make it easier just because well they can hack something up to do that anyway - that's a Microsoft approach to security. Whatever happened to people at least trying to discourage abuse or issues. The point is not that they can hack something up to use GET instead of POST and make it work. The point is that GET and/or POST are equally tainted data, and that I wish to provide the same services to either kind of request, and there is NO DIFFERENCE between them for this service. I have never used $_REQUEST and my applications don't seem to have any issues. Obviously someone could have tried to switch POST/GET on me, but I still ensure proper bounds checking/sanity checking/type checking/etc. But I would not allow someone to issue a GET variable to override a cookie value without having to make the extra effort (and furthermore understand how the variables work on the server side to make it actually work how they want.) You're still not getting the point. There *ARE* valid reasons for allowing GET and POST to be used inter-changably. Consider a stupid simple web service that lets you look up Longitude, Latitude by zip code from their own website. Do you really CARE if they use a link or a form to REQUEST the long/lat with the zip input? No. You don't. So go ahead and use REQUEST. And register_globals should be off, and using REQUEST does not undo *anything* that was done by register_globals being turned off. Use $_POST when you expect the data to always be in POST data. correct. Use $_GET when you expect the data to alwasy be in GET data. correct. If you actually want to accept HTTP requests of either kind for flexibility to an external user, by all means use REQUEST. In my opinion a properly coded web application shouldn't be lazy and should know the source of data. So I consider this incorrect. I'm sorry you feel that way. But please do NOT spread mis-information that using $_REQUEST un-does what turning register_globals off does. Because that is simply not factually correct, no matter how you feel about $_REQUEST. -- 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/browse/from/lynch Yeah, I get a buck. So? -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Re: [PHP] Re: [PHP-DB] Re: [PHP] Passing variables to a PHP script on clicking a hyperlink
I'll say it again: regsiter_globals has *NOTHING* to do with $_REQUEST. Zero. Zilch. Nada. Zip. To me it allows for the same [lazy] behavior. Period. I've had other people agree. Say what you want about it. No, it only relies on one Designer who wants their request to look like a FORM and another Designer who wants their request to look like a link. I've never had to write an app where I allow GET and POST. Either way can be created using a form, a button, a link, etc. Pick one and stick with it. And I don't really *CARE* if the search terms (or whatever input it its) comes from GET versus POST as there is NO Security difference whatsoever. They need equal filtration. Agreed The point is that GET and/or POST are equally tainted data, and that I wish to provide the same services to either kind of request, and there is NO DIFFERENCE between them for this service. I disagree with that approach to a web application. You're still not getting the point. No, I get it. I was too vague in my original message. To me newbies picked up PHP easily because hey, this query string variable is $foo just like when I do a post variable of $foo! and $_REQUEST to them is their way to get around a register_globals = off installation. I've seen it many times with people just learning PHP. I associate the use of $_REQUEST with people new to PHP, because I've seen it many times. Also when told about $_GET, $_POST, $_COOKIE, etc... they realized how much cleaner that is and adjust appropriately. There *ARE* valid reasons for allowing GET and POST to be used inter-changably. Consider a stupid simple web service that lets you look up Longitude, Latitude by zip code from their own website. Do you really CARE if they use a link or a form to REQUEST the long/lat with the zip input? No. You don't. You're right - I don't. But I tell them to use GET or POST and they prepare their client-side code appropriately. Both ways can be done. I don't make my applications lazy and then allow two interfaces to them when one is perfectly fine and allows for one consistent interaction method. But please do NOT spread mis-information that using $_REQUEST un-does what turning register_globals off does. Because that is simply not factually correct, no matter how you feel about $_REQUEST. Eh, you call it mis-information. I call it advising on how to code a tighter web application. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Re: [PHP] Re: [PHP-DB] Re: [PHP] Passing variables to a PHP script on clicking a hyperlink
On 8/24/07, Suamya Srivastava [EMAIL PROTECTED] wrote: Hi.. in the settings, session.use_cookies is turned ON but session.trans_sid is turned OFF. do i need to enable this as well? by doing this can i disable the register_globals? - suamya You need to make sure session_start() is called on all pages to be able to read/write the session data. This is probably the case. I have never needed to use trans_sid. It introduces some complexities that I don't think are needed. $_REQUEST is basically a new way of doing register_globals, which is a security issue. register_globals can allow a savvy user to overwrite a variable with another source - say you wanted a POST variable, a user could supply GET instead. or if you want it to come from a cookie using $_COOKIE it could be overridden using GET. If that makes sense. There's a lot of information about it. It was disabled by default a while back. Never enable it. You do not need it, period. Anyone telling you to enable it or reading somewhere you need to enable it is *absolutely* incorrect. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
