Re: security
| From: | Justin Patrin | Date: | Tue, 24 May 2005 18:12:50 +0000 |
| Subject: | Re: security | ||
| References: | 1 2 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-37820@lists.php.net to get a copy of this message | ||
On 5/24/05, Sean Coates <sean@caedmon.net> wrote:
> Lukas Smith wrote:
> > I search on PEAR reveals alot of usage of PHP_SELF in examples and
> > library code as well. I suggest that everybody give their packages a
> > look and make sure that they are using PHP_SELF for one of the few
> > proper reasons or change to SCRIPT_NAME when not.
>
> While I agree that everyone should review their packages, moving to
> $_SERVER['SCRIPT_NAME'] is not appropriate, IMO.
>
> The variables in $_SERVER are SAPI-dependent, and you know that your
> code works with $_SERVER['PHP_SELF'], but aren't entirely sure that it
> will with $_SERVER['SCRIPT_NAME'] -- perhaps some of your users run
> under the aolserver SAPI which (at quick glance of the source) seems to
> not implement $_SERVER['SCRIPT_NAME'] (but does implement PHP_SELF).
>
> The best practice, here, IMO, is to escape (htmlentities(), or
> urlencode()) $_SERVER['PHP_SELF'] on output. Remember, it's not
> important to deliver a nicely rendered/properly functioning page to
> someone who is deliberately screwing with the URL; it's only important
> to avoid arbitrary HTML output (allowing XSS attacks).
Hmmm, good point. I switched FormBuilder without thinking, but then
realized that this value is going into QuickForm which is going to
escape it anyway. In addition, it's important for PATH_INFO (and any
GET vars) to be in the action of a form as some scripts rely on the
this information.
>
> I'm by no means a SAPI expert, though, so if I'm wrong, please correct
> me and accept my apology, in advance.
>
--
Justin Patrin