>> Well, more worrisome would be if a bad guy tricks you into clicking on >> a link or simply sends you an image in an email that makes a request >> to my server with a valid-looking session id. Then if you go to this >> site (that > > I've debunked that scenario already a few times. The net > result is that this class of attacks is impossible to > prevent. > > The assumption in your scenario and the following is this: > > The attacker has access to a script X which calls > session_start(). > > My scenario: > > 1.) Attacker A accesses X and stores the SID which PHP assigns to > him. > > 2.) A crafts a link containing SID and sends it to victim V. > > 3.) A keeps SID alive by repeatedly accessing X using SID. > > 4.) V opens link and authenticates. > > 5.) A's script notices (4). A can overtake V's session.
Ive extended the session handling so that upon session start, it takes a snapshot of the browser string (and maybe a couple of other javascript-retrieved variables about the user's os, eg: the resolution) and build up as much of a picture of the client as possible. Then store this with the session id, and each time its loaded, check that the system hasnt changed. Ive found that (although all the data can be faked) that the browser string alone causes alot of grief - especially as IE's browser string is changed by many plugin programs. Just a thought. -- Dan Hardiker [[EMAIL PROTECTED]] ADAM Software & Systems Engineer First Creative Ltd -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
