Re: [PHP] Re: trying to figure out the best/efficient way to tell whois loggedinto a site..
On Wed, September 14, 2005 4:03 pm, Ben wrote: >>>using $_REQUEST you'll be oblivious. You ought to know where your >>>variable values are coming from, $_REQUEST hides this. I think I must object to saying "$_REQUEST" hides this. $_REQUEST tells you it came from POST or GET (or COOKIE) Anyway, I have several applications where both GET and POST are supported, and behave the same, using $_REQUEST. I really don't care if somebody wants to web-scrape with GET instead of POST, or even if they manage to fargle their Cookies to get the data they need. GET, POST, and COOKIE are all equally untrustworthy in my eyes. Lumping them into one big mess to deal with, and responding to them "the same" makes sense to me from a Security standpoint. And certainly providing an HTTP response to both GET/POST, not caring which way the requestor asked for it, doesn't matter to me. I don't think it "reduces" security to not care about whether the request is GET or POST -- Any moron can fake up either GET or POST in minutes. No difference, in the Big Picture. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: trying to figure out the best/efficient way to tell whois loggedinto a site..
Dan Baker wrote: "Ben" <[EMAIL PROTECTED]> wrote in message [snip] Interesting, but I think I wouldn't spend the extra code to detect if I was expecting a POST, but got a GET. If I didn't get the value from POST, I'd just assume it wasn't there -- I wouldn't go looking elsewhere for it, and report an error. There's no extra code with !empty($_POST['whatever']). They didn't send the information in the correct format (as a $_POST), so more than likely it's someone trying to do something funny. So ignore it or whatever. It's a real fast way to check if the data your getting came from your form. You still need to do all the other checks too. I see it not as a real security measure per se, but more like an initial check to make sure what I'm getting from my forms (may) have really came from my forms. If you can eliminate some funn business right off the bat then you don't have to do any extra processing on what most probably is bad data. [snip] And the lazy guy answer... typing $_POST and $_GET is faster than typing $_REQUEST ;-). This is, by far, the best reason I've ever heard! DanB I'd agree with that one too! ;) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: trying to figure out the best/efficient way to tell whois loggedinto a site..
Dan Baker wrote:
On the one hand, you can't trust anything that came from the client, but
on the other if you're expecting a variable to come from a cookie and
instead it comes from a get you know something weird is going on, but
using $_REQUEST you'll be oblivious. You ought to know where your
variable values are coming from, $_REQUEST hides this.
Interesting, but I think I wouldn't spend the extra code to detect if I was
expecting a POST, but got a GET. If I didn't get the value from POST, I'd
just assume it wasn't there -- I wouldn't go looking elsewhere for it, and
report an error.
Sorry, I didn't mean to suggest you spend the extra time checking to see
if you got a get when expecting a cookie, I meant to suggest that if you
were expecting a cookie you only look for a cookie and therefore ignore
the get (and generate whatever error is appropriate if you didn't get
the value). No point doing any extra coding. The point was that you
shouldn't accept a variable from where you weren't expecting it, which
$_REQUEST doesn't allow you to do.
The *main* reason I use $_REQUEST is so I can code up GET and POST pages
that all are handled by the same php functions. I may have an item called
"Key" that contains what the end-user is expected to be doing ("User.Create"
or "User.Edit" or whatever). Then I may have a link (GET) that has
?Key=User.Create, while a form (POST) that has a hidden value "Key" with
value "User.Create". I don't really care if it came from a GET or POST --
if the data is all valid, I'll allow it to work.
How are you passing your values to your functions? If you stick to
local variables in your functions they won't care where you got the
values from. Deal with the post or get values in whatever script
handles your form submissions and have it pass the values on to your
functions.
IE
In your post handling script:
$result=doSomething($_POST['this'],$_POST['that']);
In your get handling script:
$result=doSomething($_GET['this'],$_GET['that']);
- Ben
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: trying to figure out the best/efficient way to tell whois loggedinto a site..
"Ben" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Dan Baker wrote:
>
>> Why is using $_REQUEST a security issue? You know every value in the
>> entire array came from the end-user, and needs to be validated somehow.
>> If your code is written so the end-user can send this data to you via a
>> POST/GET/COOKIE, why not use $_REQUEST?
>
> On the one hand, you can't trust anything that came from the client, but
> on the other if you're expecting a variable to come from a cookie and
> instead it comes from a get you know something weird is going on, but
> using $_REQUEST you'll be oblivious. You ought to know where your
> variable values are coming from, $_REQUEST hides this.
Interesting, but I think I wouldn't spend the extra code to detect if I was
expecting a POST, but got a GET. If I didn't get the value from POST, I'd
just assume it wasn't there -- I wouldn't go looking elsewhere for it, and
report an error.
The *main* reason I use $_REQUEST is so I can code up GET and POST pages
that all are handled by the same php functions. I may have an item called
"Key" that contains what the end-user is expected to be doing ("User.Create"
or "User.Edit" or whatever). Then I may have a link (GET) that has
?Key=User.Create, while a form (POST) that has a hidden value "Key" with
value "User.Create". I don't really care if it came from a GET or POST --
if the data is all valid, I'll allow it to work.
> In older versions of PHP4 this is even more of an issue since $_FILE
> information was also included in $_REQUEST. If someone uploades a file
> while including conflicting information from another source (cookie, post,
> get) this could lead to all sorts of problems.
I didn't know this one. This might cause problems for me.
> And the lazy guy answer... typing $_POST and $_GET is faster than typing
> $_REQUEST ;-).
This is, by far, the best reason I've ever heard!
DanB
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
