NYCPHP Meetup

[Chris Shiflett]

--- Hans Zaunere <hans not junk at nyphp.com> wrote:
> > This Jacqueline Emigh lady seems to enjoy making up stories. I
> > wrote about her once already here:
> > 
> > http://shiflett.org/archive/18
> 
> You can't buy that type of press Chris!  :)

Heh, do I want that type of press?

I am going to drop her a note. I'll give her the benefit of the doubt and
assume she took crappy notes, but dang, surely the Novell/SuSE stuff was
on a separate page in her notebook than SCO stuff. :-P

Chris

=====
Chris Shiflett - http://shiflett.org/

PHP Security Handbook
     Coming mid-2004
HTTP Developer's Handbook
     http://httphandbook.org/

>From hans not junk at nyphp.com  Mon Dec  1 22:43:47 2003
Return-Path: <hans not junk at nyphp.com>
Received: from londo.swishmail.com (londo.swishmail.com [209.10.110.95])
	by virtu.nyphp.org (Postfix) with ESMTP id E83FCA85E6
	for <talk at lists.nyphp.org>; Mon,  1 Dec 2003 22:43:46 -0500 (EST)
Received: (qmail 56484 invoked by uid 89); 2 Dec 2003 03:43:46 -0000
Received: from unknown (HELO nyphp.com) (hans not junk at nyphp.com@66.65.174.214)
	by londo.swishmail.com with AES256-SHA encrypted SMTP;
	2 Dec 2003 03:43:46 -0000
Message-ID: <3FCC0A71.5090704 at nyphp.com>
Date: Mon, 01 Dec 2003 22:43:45 -0500
From: Hans Zaunere <hans not junk at nyphp.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6a) Gecko/20031030
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: NYPHP Talk <talk at lists.nyphp.org>
Subject: Re: [nycphp-talk] security? we don't need no stinkin security!
References: <20031202024938.GA10184 at panix.com>
	<001501c3b87f$4ae25490$6400a8c0 at thinkpad>
In-Reply-To: <001501c3b87f$4ae25490$6400a8c0 at thinkpad>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: talk at lists.nyphp.org
X-Mailman-Version: 2.1.2
Precedence: list
Reply-To: NYPHP Talk <talk at lists.nyphp.org>
List-Id: NYPHP Talk  <talk.lists.nyphp.org>
List-Unsubscribe: <http://lists.nyphp.org/mailman/listinfo/talk>,
	<mailto:talk-request at lists.nyphp.org?subject=unsubscribe>
List-Archive: <http://lists.nyphp.org/pipermail/talk>
List-Post: <mailto:talk at lists.nyphp.org>
List-Help: <mailto:talk-request at lists.nyphp.org?subject=help>
List-Subscribe: <http://lists.nyphp.org/mailman/listinfo/talk>,
	<mailto:talk-request at lists.nyphp.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Dec 2003 03:43:47 -0000



jon baer wrote:

>>phpBB search.php SQL Injection Vulnerability
>>http://www.securityfocus.com/bid/9122
> 
> 
> im just curious - what exactly was the solution that does work and why does
> it work?  someone care to explain:
> 
> if (intval($search_id)) {
> vs.
> $search_id = intval($search_id);
> if ($search_id) {

It's not those couple of lines that have the effect.  Later in the code $search_id is used in the SQL statement.  In the first case, $search_id is used verbatim; in the later, the return value from intval() is used.  It's nothing concerning intval() or the structure of the if() - just sloppy programming.

H

>From hans not junk at nyphp.com  Mon Dec  1 22:53:00 2003
Return-Path: <hans not junk at nyphp.com>
Received: from londo.swishmail.com (londo.swishmail.com [209.10.110.95])
	by virtu.nyphp.org (Postfix) with ESMTP id 23CEAA85E6
	for <talk at lists.nyphp.org>; Mon,  1 Dec 2003 22:53:00 -0500 (EST)
Received: (qmail 58630 invoked by uid 89); 2 Dec 2003 03:53:00 -0000
Received: from unknown (HELO nyphp.com) (hans not junk at nyphp.com@66.65.174.214)
	by londo.swishmail.com with AES256-SHA encrypted SMTP;
	2 Dec 2003 03:52:59 -0000
Message-ID: <3FCC0C9B.3070607 at nyphp.com>
Date: Mon, 01 Dec 2003 22:52:59 -0500
From: Hans Zaunere <hans not junk at nyphp.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6a) Gecko/20031030
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: NYPHP Talk <talk at lists.nyphp.org>
Subject: Re: [nycphp-talk] PHundamentals topic #4B:  managing php.ini settings
References: <6.0.1.1.2.20031201203111.01b056d8 at mail.optonline.net>
In-Reply-To: <6.0.1.1.2.20031201203111.01b056d8 at mail.optonline.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: talk at lists.nyphp.org
X-Mailman-Version: 2.1.2
Precedence: list
Reply-To: NYPHP Talk <talk at lists.nyphp.org>
List-Id: NYPHP Talk  <talk.lists.nyphp.org>
List-Unsubscribe: <http://lists.nyphp.org/mailman/listinfo/talk>,
	<mailto:talk-request at lists.nyphp.org?subject=unsubscribe>
List-Archive: <http://lists.nyphp.org/pipermail/talk>
List-Post: <mailto:talk at lists.nyphp.org>
List-Help: <mailto:talk-request at lists.nyphp.org?subject=help>
List-Subscribe: <http://lists.nyphp.org/mailman/listinfo/talk>,
	<mailto:talk-request at lists.nyphp.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Dec 2003 03:53:00 -0000


> On a server we control, that seems straightforward: we modify php.ini.
> But we may also control some PHP settings using a <Directory> or
> <Files> directive in httpd.conf, or in .htaccess. What is best
> practice here?

Personally, I make extensive use of Apache's directive to control PHP's environment and application behavior.  Properly using these directives, one can realize a great deal of power only thought to exist in those "other platforms."  I especially use the <Directory> and <VirtualHost> directives to manipulate certain areas of my application.

That said, settings that never need to be manipulated, like register_globals :) I set in php.ini.  Other major settings, like output_buffering, or those that can only be set in php.ini, I set in php.ini as well.  I take a hybrid approach to settings like include_path, setting it to different values in different places, but with a sound default in php.ini.

> And what is best practice on a server we don't control, where we have
> access only to our own directories? How can we make certain that our
> required settings are in effect?

In some cases, you just can't and will have to contact the system administrator.  For that with control, .htaccess can be handy, although access to that file may be limited as well.  In these cases, these settings have to be dealt with using ini_set() in the application's logic.

Determining what settings can be set how and where is vital and explained in http://php.net/ini_set

Setting PHP values in Apache's conf files also have added flexibility.  Setting a value with php_admin_value or php_admin_flag are non-overrideable elsewhere in the application logic, .htaccess files, or even virtual hosts - only Apache's main server config.  More details at http://us3.php.net/configuration.changes

H