Dan Hardiker wrote: >>>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. >
Unfortunately, this info gets obscured by many major (aol) proxy farms as well. > > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
