Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:16145 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 79213 invoked by uid 1010); 29 Apr 2005 18:22:22 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 79198 invoked from network); 29 Apr 2005 18:22:22 -0000 Received: from unknown (HELO cain.sh) (127.0.0.1) by localhost with SMTP; 29 Apr 2005 18:22:22 -0000 X-Host-Fingerprint: 24.94.166.115 ms-smtp-01.rdc-kc.rr.com NetCache Data OnTap 5.x Received: from ([24.94.166.115:48159] helo=ms-smtp-01.rdc-kc.rr.com) by pb1.pair.com (ecelerity 1.2.12rc1 r(5476:5477)) with SMTP id CC/9F-20173-D5B72724 for ; Fri, 29 Apr 2005 14:22:21 -0400 Received: from [192.168.0.3] (CPE-65-27-120-4.mn.res.rr.com [65.27.120.4]) by ms-smtp-01.rdc-kc.rr.com (8.12.10/8.12.7) with ESMTP id j3TIMFSC007037 for ; Fri, 29 Apr 2005 13:22:16 -0500 (CDT) Message-ID: <42727B54.90508@cain.sh> Date: Fri, 29 Apr 2005 13:22:12 -0500 User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: internals@lists.php.net References: <4266894D.1070702@cain.sh> <42668AC0.1010607@caedmon.net> <4269D32C.1080706@cain.sh> <426E6F87.5020908@velum.net> <426E7356.4020504@php.net> In-Reply-To: <426E7356.4020504@php.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: Re: [PHP-DEV] [PATCH] Modifications for ext/session/ From: dan@cain.sh ("Daniel J Cain Jr.") Chris Shiflett wrote: > It would raise the bar, but that's about it. But isn't that what increasing application security is all about? Wouldn't that be an example(albeit an arguably small one) of defense in depth? > An attacker visits your site (to initiate the session), determines the > assigned session identifier, and then uses that session identifier > (which now references an initiated session) for the session fixation > attack. But if you forced the attacker to come to the site to obtain a valid session ID before sending it to the victim. You would now have a time frame that the ID is good for. As opposed to being able to set any arbitrary session ID to begin with, simply by passing it to PHP. I'm not saying this will *stop* attacks all together, but it would require a more technically competent attacker than is currently required for some known exploits. I'm only hoping to enhance the tools available, so that more complex session handling is available to those who choose to do so. Not to change PHP to do this on the users behalf. -- D a n i e l J C a i n J r . Zend Certified Engineer http://zend.com/zce.php?c=ZEND001685&r=210869656