Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:16149
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <42729DAB.5060806@php.net>
Date: Fri, 29 Apr 2005 22:48:43 +0200
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: "Daniel J Cain Jr." <dan@cain.sh>
CC: internals@lists.php.net
References: <4266894D.1070702@cain.sh> <42668AC0.1010607@caedmon.net>	<pkhi61di24djruht2uhqhjfppn6bt6dsme@4ax.com> <4269D32C.1080706@cain.sh>	<d0cb926205042518356213b551@mail.gmail.com> <Pine.LNX.4.61.0504260952410.29267@chatserv> <426E6F87.5020908@velum.net> <426E7441.5010101@php.net> <42727BBE.1070305@cain.sh>
In-Reply-To: <42727BBE.1070305@cain.sh>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] Modifications for ext/session/
From: sesser@php.net (Stefan Esser)

Hi,

> I would prefer to make the attacker grab a valid session ID from me 
> rather than simply allowing them to generate their own random one.  It 
> would simply mean the attacker would need a slightly more complex script 
> to automate attacks.  As well as applying a possible time frame the 
> attack is valid for.  Which isn't a bad thing IMO.

Sorry but I must comment on this argument again. I hear often, that 
requiring the attacker to use a valid session ID will give the whole 
attack a certain time frame.

Sorry but this argument forgets how a typical attack works:

1) give user a "fixed" session
2) wait a certain amount of time to check if he visited the site with 
this session
3) test the sesssion ID on the site...
4) wait again
5) repeat 3-4 until the user used the site...

So you see, that there is always a time frame. Even when the attacker 
uses a random one, because he can never know when his victim will visit 
the site with this session id....

So he has to visit the site at some point and check if the session was 
started and at this point he will start the session. If he does the 
visit too early he will create the session instead of the victim, if he 
visits too late, he will only end up in the expired session of the victim.

So in both cases the attacker has to visit the site f.e. every 30 
minutes so that the session id does not time out. So all you get from 
allowing fake session ID is that the attacker has to connect one time less.

Which proofs my point that the whole panic about fake session id forgets 
how the real attackers have to work anyway...

Stefan