Thread: [Phplib-users] Re: latest snapshot
Brought to you by:
nhruby,
richardarcher
Menu
▾
▴
phplib-users
|
From: Marko K. <M.K...@os...> - 2002-11-04 08:56:09
|
Hi, shouldn't we in general use the $_POST, $_GET vars from now on, instead of the old $HTTP_* variables? The latter one don't seem to be recommended for further use and if a new phplib4 is created one should use right away the proper superglobals. Marko |
|
From: Chris J. <ch...@ch...> - 2002-11-04 21:02:26
|
On Mon, Nov 04, 2002 at 09:55:23AM +0100, Marko Kaening wrote:
> shouldn't we in general use the $_POST, $_GET vars from now on, instead of
> the old $HTTP_* variables? The latter one don't seem to be recommended for
> further use and if a new phplib4 is created one should use right away the
> proper superglobals.
Agreed. There may be a few people out there still using PHP3, but I
honestly think we need to focus on supporting PHP4.
--
..chris
|
|
From: Giancarlo <gia...@na...> - 2002-11-05 08:18:21
|
I particularly like the fact that snapshot is compatible with the traditi= onal=20 session.inc. As we were speaking about credit card etc, I'd like tomention that in usi= ng=20 any authentication, the control over the session propagation becomes vita= l to=20 security, and php4 ofeers zero control on that. I am sure that session.in= c=20 could acquire some speed by the builtin serializations for the data=20 representation, and the save handlers could be quick, but I'd like a more= =20 controlled propagation in general. One of the things I think everyone really needs is the possibility to shi= ft=20 =66rom a less secure get/trans-sid propagation method, to a more secure=20 only_cookies propagation, reissuing a new session of the latter type and=20 migration all the old session values in it. This means that once authed y= ou=20 get a new session, possibly of the stronger type. BEcause the fact that anyone can be driven into 'get' mode and accept any= =20 users-choice-unpredictable sid... Gian Il 09:55, luned=EC 4 novembre 2002, Marko Kaening ha scritto: > Hi, > > shouldn't we in general use the $_POST, $_GET vars from now on, instead= of > the old $HTTP_* variables? The latter one don't seem to be recommended = for > further use and if a new phplib4 is created one should use right away t= he > proper superglobals. > > Marko > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ApacheCon, November 18-21 in > Las Vegas (supported by COMDEX), the only Apache event to be > fully supported by the ASF. http://www.apachecon.com > _______________________________________________ > Phplib-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users |
|
From: Rob H. <rob...@ws...> - 2002-11-05 12:50:30
|
Can't you shift modes now by having two sessions, one with get, one with only cookies, and two auths in local.inc? BTW, why would you use get in the first place unless the browser is not accepting cookies. If that is the case, then you can't use cookies anyway? Thanks, Rob Hutton Web Safe www.wsafe.com > -----Original Message----- > From: php...@li... > [mailto:php...@li...]On Behalf Of Giancarlo > Sent: Tuesday, November 05, 2002 3:13 AM > To: Marko Kaening; Joe Stewart > Cc: phplib-users list > Subject: Re: [Phplib-users] Re: latest snapshot > > > I particularly like the fact that snapshot is compatible with the > traditional > session.inc. > As we were speaking about credit card etc, I'd like tomention > that in using > any authentication, the control over the session propagation > becomes vital to > security, and php4 ofeers zero control on that. I am sure that > session.inc > could acquire some speed by the builtin serializations for the data > representation, and the save handlers could be quick, but I'd like a more > controlled propagation in general. > One of the things I think everyone really needs is the > possibility to shift > from a less secure get/trans-sid propagation method, to a more secure > only_cookies propagation, reissuing a new session of the latter type and > migration all the old session values in it. This means that once > authed you > get a new session, possibly of the stronger type. > BEcause the fact that anyone can be driven into 'get' mode and accept any > users-choice-unpredictable sid... > > |
|
From: Giancarlo <gia...@na...> - 2002-11-05 18:48:40
|
Il 13:52, marted=EC 5 novembre 2002, Rob Hutton ha scritto: > Can't you shift modes now by having two sessions, one with get, one wit= h > only cookies, and two auths in local.inc? =20 > BTW, why would you use get in > the first place unless the browser is not accepting cookies. If that i= s > the case, then you can't use cookies anyway? with php4 you can force get mode and an id of your own choice by simply=20 opening an url with your-choice sid in it. Must be not a cookie already a= t=20 your browser. And php4 doesn't really tell me when this session is a just-new-issued on= e or=20 a preexistent one. I can nnever be sure when my session is fresh,=20 uninitialized. If you want to block anything (eg: registration submission) by requiring = that=20 the client has previously obtained a session from you, you can't. And with php4 I couldn't obtain to reissue a second session after a firs= t=20 one. If you want to ignore sessions provided in the url that were not previous= ly=20 issued by yourself, you cant. There can exists sharable sessions, user ca= n=20 choose his 'unpredictable' session id. Cookie-enableb client, but vergin = on=20 our cookies, can be forced into accepting any sid from the URL get method= =2E I want to open as much as possible the public access, to anyone with or=20 without cookies. But for the authed access I want to have a strictier pol= icy. Gian |
|
From: Richard A. <rh...@ju...> - 2002-11-06 11:08:27
|
At 9:13 +0100 5/11/02, Giancarlo wrote: >One of the things I think everyone really needs is the possibility to shift >from a less secure get/trans-sid propagation method, to a more secure >only_cookies propagation Giancarlo, Please remind me again... why is passing the session ID in a cookie more secure than passing it in a GET string? Is this simply due to bugs and illogic in the PHPLIB and/or PHP session ID allocation? ...Richard. |
|
From: Rob H. <rob...@ws...> - 2002-11-06 21:16:41
|
I'm not Gian but... If you allow the session ID to be passed in as a string, then someone can hijack a session by simply passing the session ID in the get string. A cookie is much harder to insert, and since they are session cookies, they can't easily be viewed or replicated... Thanks, Rob Hutton Web Safe www.wsafe.com > -----Original Message----- > From: php...@li... > [mailto:php...@li...]On Behalf Of Richard > Archer > Sent: Wednesday, November 06, 2002 5:58 AM > To: php...@li... > Subject: Re: [Phplib-users] Re: latest snapshot > > > At 9:13 +0100 5/11/02, Giancarlo wrote: > > >One of the things I think everyone really needs is the > possibility to shift > >from a less secure get/trans-sid propagation method, to a more secure > >only_cookies propagation > > > Giancarlo, > > Please remind me again... why is passing the session ID in a cookie > more secure than passing it in a GET string? Is this simply due to > bugs and illogic in the PHPLIB and/or PHP session ID allocation? > > ...Richard. > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phplib-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users > > |
|
From: Giancarlo <gia...@na...> - 2002-11-06 21:46:59
|
> If you allow the session ID to be passed in as a string, then someone can > hijack a session by simply passing the session ID in the get string. A > cookie is much harder to insert, and since they are session cookies, they > can't easily be viewed or replicated... the requested url passes in cleartext, even with SSL, while msg headers (cookies) and bodies are encrypted. Gian |
|
From: Michael C. <mdc...@mi...> - 2002-11-07 16:14:34
|
On Wed, Nov 06, 2002 at 10:41:56PM +0100, Giancarlo wrote: > the requested url passes in cleartext, even with SSL If that were the case, we could do name-based virtual hosting with ssl. When you use SSL, the entire connection is encrypted. If you want to see this in action, use the openssl command on a unix machine (with openssl installed) to connect to a web server: % openssl s_client -connect www.hotmail.com:443 {bunch of information about the certificate and connection} HEAD / HTTP/1.0 HTTP/1.1 302 Redirected Server: Microsoft-IIS/5.0 Date: Thu, 07 Nov 2002 16:11:40 GMT Location: https://lc1.law5.hotmail.passport.com/cgi-bin/login read:errno=0 % Note that the "HEAD / HTTP/1.0" is the request, and "/" is the URL. Michael -- Michael Darrin Chaney mdc...@mi... http://www.michaelchaney.com/ |
|
From: Giancarlo <gia...@na...> - 2002-11-07 19:44:11
|
Il 17:23, gioved=EC 7 novembre 2002, Michael Chaney ha scritto: > On Wed, Nov 06, 2002 at 10:41:56PM +0100, Giancarlo wrote: > > the requested url passes in cleartext, even with SSL yes encrypted, thought not |
|
From: Richard A. <rh...@ju...> - 2002-11-06 22:33:14
|
At 16:19 -0500 6/11/02, Rob Hutton wrote: > If you allow the session ID to be passed in as a string, then someone can >hijack a session by simply passing the session ID in the get string. A >cookie is much harder to insert, and since they are session cookies, they >can't easily be viewed or replicated... OK. It is trivial to insert a cookie once you know the values. You can edit your cookie file with a text editor or use curl to pass in the cookie on the command line. So, session ID discovery is really the key here. If physical access is available, concealing the session ID is meaningless because the perp can sit at that machine and continue the existing session just as easily as they could copy down the session ID from screen or run a memory scanning utility to find it. Without physical access to the user's machine, session hijacking requires sniffing the traffic to determine the session ID... in which case the GET string and the cookie would both be displayed as plain as day. However I would assume that if security is any sort of an issue then the session would be running over SSL in which case it is not a trivial matter to obtain either the GET string or the cookie and in this case I can't see why one should be preferred over another. But I must admit I've never studied this area in great depth. ...Richard. |
|
From: Rob H. <rob...@ws...> - 2002-11-07 03:04:10
|
Not quite that simple. Session cookies are never written to the hard drive and are not viewable from the cookie window. The only way I can think of looking at them is by running the browser in a VM debugger and looking at the trace. Even then I am not sure that you could find it because it might be scattered in the stack. It would be much easier to sit between the server and web site to do something, which is where https comes in. Also, I asked a couple of questions on the Mozilla list, and to their knowledge, you would have to write some code to insert a session cookie into memory or attack the server directly without a browser (like with curl). Either way is more trouble that simply entering a uid as a get variable, and is the safest way I see of doing it. Thanks, Rob Hutton Web Safe www.wsafe.com > -----Original Message----- > From: php...@li... > [mailto:php...@li...]On Behalf Of Richard > Archer > Sent: Wednesday, November 06, 2002 5:33 PM > To: php...@li... > Subject: RE: [Phplib-users] Re: latest snapshot > > > At 16:19 -0500 6/11/02, Rob Hutton wrote: > > > If you allow the session ID to be passed in as a string, then > someone can > >hijack a session by simply passing the session ID in the get string. A > >cookie is much harder to insert, and since they are session cookies, they > >can't easily be viewed or replicated... > > OK. It is trivial to insert a cookie once you know the values. You > can edit your cookie file with a text editor or use curl to pass in > the cookie on the command line. > > So, session ID discovery is really the key here. > > If physical access is available, concealing the session ID is > meaningless because the perp can sit at that machine and continue > the existing session just as easily as they could copy down the > session ID from screen or run a memory scanning utility to find it. > > Without physical access to the user's machine, session hijacking > requires sniffing the traffic to determine the session ID... in > which case the GET string and the cookie would both be displayed > as plain as day. > > However I would assume that if security is any sort of an issue > then the session would be running over SSL in which case it is not > a trivial matter to obtain either the GET string or the cookie and > in this case I can't see why one should be preferred over another. > > But I must admit I've never studied this area in great depth. > > ...Richard. > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phplib-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users > |
|
From: Rob H. <rob...@ws...> - 2002-11-07 03:10:20
|
Sorry, entering a session ID as a get variable, not uid. I'm getting ahead of myself!!! > -----Original Message----- > From: php...@li... > [mailto:php...@li...]On Behalf Of Rob Hutton > Sent: Wednesday, November 06, 2002 10:07 PM > To: Richard Archer; php...@li... > Subject: RE: [Phplib-users] Re: latest snapshot > > > Not quite that simple. Session cookies are never written to the hard > drive and are not viewable from the cookie window. The only way > I can think > of looking at them is by running the browser in a VM debugger and > looking at > the trace. Even then I am not sure that you could find it > because it might > be scattered in the stack. > It would be much easier to sit between the server and web site to do > something, which is where https comes in. > Also, I asked a couple of questions on the Mozilla list, and to their > knowledge, you would have to write some code to insert a session > cookie into > memory or attack the server directly without a browser (like with curl). > Either way is more trouble that simply entering a uid as a get > variable, and > is the safest way I see of doing it. > > Thanks, > Rob Hutton > Web Safe > www.wsafe.com > > > -----Original Message----- > > From: php...@li... > > [mailto:php...@li...]On Behalf Of Richard > > Archer > > Sent: Wednesday, November 06, 2002 5:33 PM > > To: php...@li... > > Subject: RE: [Phplib-users] Re: latest snapshot > > > > > > At 16:19 -0500 6/11/02, Rob Hutton wrote: > > > > > If you allow the session ID to be passed in as a string, then > > someone can > > >hijack a session by simply passing the session ID in the get string. A > > >cookie is much harder to insert, and since they are session > cookies, they > > >can't easily be viewed or replicated... > > > > OK. It is trivial to insert a cookie once you know the values. You > > can edit your cookie file with a text editor or use curl to pass in > > the cookie on the command line. > > > > So, session ID discovery is really the key here. > > > > If physical access is available, concealing the session ID is > > meaningless because the perp can sit at that machine and continue > > the existing session just as easily as they could copy down the > > session ID from screen or run a memory scanning utility to find it. > > > > Without physical access to the user's machine, session hijacking > > requires sniffing the traffic to determine the session ID... in > > which case the GET string and the cookie would both be displayed > > as plain as day. > > > > However I would assume that if security is any sort of an issue > > then the session would be running over SSL in which case it is not > > a trivial matter to obtain either the GET string or the cookie and > > in this case I can't see why one should be preferred over another. > > > > But I must admit I've never studied this area in great depth. > > > > ...Richard. > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: See the NEW Palm > > Tungsten T handheld. Power & Color in a compact size! > > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > > _______________________________________________ > > Phplib-users mailing list > > Php...@li... > > https://lists.sourceforge.net/lists/listinfo/phplib-users > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Phplib-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users > > |
|
From: Richard A. <rh...@ju...> - 2002-11-07 04:00:06
|
At 22:07 -0500 6/11/02, Rob Hutton wrote: > Not quite that simple. Session cookies are never written to the hard >drive and are not viewable from the cookie window. The only way I can think >of looking at them is by running the browser in a VM debugger and looking at >the trace. Even then I am not sure that you could find it because it might >be scattered in the stack. Might be. Or you might be able to run a memory search tool, search for the cookie name and see the value right next to it. Finding the cookie name is trivial... just load the site on another computer with "prompt" for cookies and it'll tell you. > It would be much easier to sit between the server and web site to do >something, which is where https comes in. Yup. If you want even a veneer of security, run the session over SSL. > Also, I asked a couple of questions on the Mozilla list, and to their >knowledge, you would have to write some code to insert a session cookie into >memory or attack the server directly without a browser (like with curl). No need to insert a session cookie into the browser's runtime state. Quit the browser, add a permanent cookie to your cookie jar with a text editor, start the browser, load the URL. There is no inherent difference between a permanent cookie and a session cookie except that the browser caches them differently. >Either way is more trouble that simply entering a [session] id as a >get variable, and is the safest way I see of doing it. Yes, but if you have an attacker willing to try the non-trivial task of session hijacking, presumably they have a reason driving them to do so. In which case making it just a little harder might be giving yourself and the user a false sense of security. The only drawback I can see of GET strings is that perhaps the Session ID can be obtained by reading the target's screen (i.e. with a telescope through a window, with a hidden camera etc). I see this as only a minimal drawback over the cookie approach, and if session hijacking is of concern, cookies are IMHO not an adequate security mechanism in themselves. Perhaps changing the session ID on each page view would be a better approach. Wouldn't be too hard to implement either, I expect. ...R. |
|
From: Rob H. <rob...@ws...> - 2002-11-07 04:26:39
|
Interesting idea about changing the session ID. I don't see any kind of session_replicate and if you change the id manually, you loose everything. I would think this could get to be a serious amount of overhead on the server, too. Anyway, here is the relevant paragraph from the PHP manual: *** Sessions rely on the session ID, meaning one can 'steal' a session, by stealing the session ID. This can be made harder, by using a cookie specifically a session cookie, but does not in any way make it impossible and still relies on the user closing all browser windows, to expire the session cookie. Besides that, even session cookies can be sniffed on a network or logged by a proxyserver. *** So, the trick is some end user responsibility (close all windows) across SSL and strong session IDs. Maybe a disclaimer should be added. Also, should the length of the session ID be extended? Someone in the manual suggested storing the IP of the remote machine in the session and refusing to start it if the session request comes from somewhere else. Problem is, inconsistent browser support, implementation, and proxy server farms. Maybe in "SUPER DUPER SECURITY MODE". Other responses in line. > > Might be. Or you might be able to run a memory search tool, search for > the cookie name and see the value right next to it. Finding the cookie > name is trivial... just load the site on another computer with "prompt" > for cookies and it'll tell you. But this requires physical access. It would be easier in most environments to do it across the net. Plus, it's the old rule of turn you screen saver on with a password so that someone does not come up to your machine and use it while you are not there. This is a physical security issue. > > > Yup. If you want even a veneer of security, run the session over SSL. Except SSL isn't that hard to crack ;-) > > > No need to insert a session cookie into the browser's runtime state. > Quit the browser, add a permanent cookie to your cookie jar with a text > editor, start the browser, load the URL. There is no inherent > difference between a permanent cookie and a session cookie except that > the browser caches them differently. So the cookie lifetime should be checked to make sure it is 0. Will add to my mods to auth. > > > The only drawback I can see of GET strings is that perhaps the Session > ID can be obtained by reading the target's screen (i.e. with a > telescope through a window, with a hidden camera etc). I see this as > only a minimal drawback over the cookie approach, and if session > hijacking is of concern, cookies are IMHO not an adequate security > mechanism in themselves. Or the age old shoulder surfer. That's how a lot of passwords are compromised to this day. If it is on the screen, someone can walk up behind the user and see it, write it down, etc. Most stuff like this is much more intimate than a telescope. You'd be surprised how many "high" security areas that I have gotten into during physical audits by pushing around a 50 gallon trash can on wheels with some cleaning supplies on the outside. I had someone let me in to a Level 3 (top) security government contractor by telling them I was new and had not gotten a badge yet. |
|
From: Richard A. <rh...@ju...> - 2002-11-07 04:51:56
|
At 23:29 -0500 6/11/02, Rob Hutton wrote: >Interesting idea about changing the session ID. I don't see any kind of >session_replicate and if you change the id manually, you loose everything. >I would think this could get to be a serious amount of overhead on the >server, too. I would not expect any significant additional overhead on the server. You just need to generate a new session ID and change the database query which stores the session so that it updates the session ID when it stores the session variables. I wouldn't think there'd be more than about 10 lines of extra code in PHPLIB. Might be an interesting option to add sometime... have to make it optional via a local.inc switch! >Someone in the manual suggested storing the IP of the remote machine in the >session and refusing to start it if the session request comes from somewhere Yeah, well that's a bogus suggestion because you'll break things for so many people your site will become useless. >> Yup. If you want even a veneer of security, run the session over SSL. > >Except SSL isn't that hard to crack ;-) First time I've heard that... I would have thought cracking SSL connections in anything resembling real time without military-grade hardware would be big news. Got any pointers to how that's done? >> No need to insert a session cookie into the browser's runtime state. >> Quit the browser, add a permanent cookie to your cookie jar with a text >> editor, start the browser, load the URL. There is no inherent >> difference between a permanent cookie and a session cookie except that >> the browser caches them differently. > >So the cookie lifetime should be checked to make sure it is 0. Will add to >my mods to auth. Except you don't get told what the cookie lifetime is. All you get back from the browser is the cookie name and value. ...R. |
|
From: Rob H. <rob...@ws...> - 2002-11-07 05:20:02
|
> I would not expect any significant additional overhead on the server.
> You just need to generate a new session ID and change the database
> query which stores the session so that it updates the session ID when
> it stores the session variables. I wouldn't think there'd be more than
> about 10 lines of extra code in PHPLIB. Might be an interesting option
> to add sometime... have to make it optional via a local.inc switch!
>
Not with PHP4 sessions. PHP itself controls the session ID.
>
> First time I've heard that... I would have thought cracking SSL
> connections in anything resembling real time without military-grade
> hardware would be big news. Got any pointers to how that's done?
There is a fairly easy MITM attack of up to version 2, which there is a lot
of still out there (anyone heard of IIS?). I will try to drag out my docs,
I can't lay quick hands on them and it is time for a couple of hours of
rest. Basically there was a weakness in the key exchange protocol that
allowed you to insert yourself into the stream anytime is you had recorded
the initial handshake.
>
>
> Except you don't get told what the cookie lifetime is. All you get back
> from the browser is the cookie name and value.
Right. Guess that is a problem.
What about incrementing a separate random that gets changed in pageopen.
Call it sesscheck
start session
if ($_COOKIE['sesscheck'] != $_SESSION['sesscheck'] {
//bomb out because we are being hijacked.
}
$sesscheck = md5(uniqid(rand(),1));
set_cookie($sesscheck)
$sess->register('sesscheck');
This would have a similar effect to changing the session id every time!!!!
>
> ...R.
>
>
|
|
From: Marko K. <M.K...@os...> - 2002-11-07 08:12:40
|
> start session
> if ($_COOKIE['sesscheck'] != $_SESSION['sesscheck'] {
> //bomb out because we are being hijacked.
> }
> $sesscheck = md5(uniqid(rand(),1));
> set_cookie($sesscheck)
> $sess->register('sesscheck');
>
> This would have a similar effect to changing the session id every time!!!!
Looks nice!
But what happens if you're working with frames?!?
Up to now it's possible to work with frames, though it's not very handy.
You just use page_close() in only one frame. But with this scheme you
could will run into severe problems, since at the end of the page the
session wouldn't become saved, although the cookie would be saved already.
Perhaps it would be wiser to issue the set_cookie only in page_close!
Marko
|
|
From: Giancarlo <gia...@na...> - 2002-11-07 08:16:57
|
> What about incrementing a separate random that gets changed in pageopen.
> Call it sesscheck
>
> start session
> if ($_COOKIE['sesscheck'] != $_SESSION['sesscheck'] {
> //bomb out because we are being hijacked.
> }
> $sesscheck = md5(uniqid(rand(),1));
> set_cookie($sesscheck)
> $sess->register('sesscheck');
If we could know the moment whenn our session is a fresh new one, we could
save the mode (get/cookie), and block that client from changing his mode
along the way. Every passage/steal of cookie/GET supposes changing its mode
along the way.
If we trust cookies is because they are not allowed be passed. If a client
chances propagation we can be almost sure that the client itself has changed,
or it means that someone has enabled/disabled his cookies midway, which
should equate a change in client.
We should be able to decide where and when accept these alien sids. In some
cases they are useful though, but allowing them anywhere is not safe.
Gian
|
|
From: Giancarlo <gia...@na...> - 2002-11-07 08:10:37
|
Il 05:44, gioved=EC 7 novembre 2002, Richard Archer ha scritto: > At 23:29 -0500 6/11/02, Rob Hutton wrote: > >Interesting idea about changing the session ID.=20 Yes, because if anyone did know, or suggest us, a known session id to ent= er=20 an unauthed session, once we are authed that sid is discarded, so the=20 'knowing suggestor' cannot folow us there. And when we reissue the session, this would be the right moment for chang= ing=20 the session type if we want, let's say from a file mudule, to a custom=20 db_module, so once logged in our session sits more secure into the db. This would be a good compromise bethween speed and open access (everyone = can=20 use the session features, even with cookies disabled, full speed because = php4=20 native),, nad once logged in things get more tight, at a slight performan= ce=20 cost, but maximum safety=20 |
|
From: Giancarlo <gia...@na...> - 2002-11-07 08:44:56
|
> The only drawback I can see of GET strings is that perhaps the Session > ID can be obtained by reading the target's screen (i.e. with a > telescope through a window, with a hidden camera etc). I see this as This is true if we don't take into consideration the fact that any, user-fantasy id can be provided by proposing a link with the sid in it. And it will be created. Where is the randomicity and 'non-guessability' if anyone (cookie free) can impose on anyone else his known sid as ?Example=Session=1 There are books and treaties about random cookie/token creation. Human fantasy is not an enough valid device for generating random tokens! This is not Posix/MIT/cookie/whatever compliant. This is an illogic bestiality Gian |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X