Thread: Re: [Phplib-users] store the IP in the session
Brought to you by:
nhruby,
richardarcher
Menu
▾
▴
phplib-users
|
From: Marko K. <M.K...@os...> - 2002-12-05 08:07:45
|
> Excuse me, but if I propose you to click on a link as > https://phplib.sourceforge.net/showoff.php3?PHPSESSID=1 ^^^^^^^^ yes of course this is still possible... :( > you click on it, you login, you place it in your bookmarks, can't I > steal it afterwards, forever and ever, as long as you use that bookmark? well, in case trans_sid is set to on and you're not restricting your users to work with cookies, yes. Sorry, I followed joe's advice to disable session-id transfer via url, so I wasn't aware of this, looks like. Marko |
|
From: Rob H. <rob...@ws...> - 2002-12-06 13:25:49
|
This is the beginning of something better. Buth auth should NEVER be done in a cascade fashion. The should ALWAYS be a control structure. Secondly, there need to be more insertion points. The concept that auth is a abstract class is a good one IMO. Elimination of local.inc would be a mistake because now, as long as the API remains backwards compatable, you can drop local.inc into a newer version of PHPLib and not loose and customization. One other thing, everyone please keep discussion on the list and not in private. There has evidently been a fair amount of off list work going on that when it hits the list causes much discussion. I appreciate that there are people that are working on certain modules and have control over them, but we need to make sure that the changes made to PHPLib make sense for and to the community. Rob Hutton Web Safe www.wsafe.com ********************************************************************** Introducing Symantec Client Security - Integrated Anti-Virus, Firewall, and Intrusion Detection for the Client. Learn more: http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271 > -----Original Message----- > From: Giancarlo [mailto:gia...@na...] > Sent: Thursday, December 05, 2002 12:05 PM > To: rob...@ws... > Subject: Re: [Phplib-users] store the IP in the session > > > I thought about auth. Yesterday I sent Joe this new start structure that > allows both, structured and,if not, default cascade. It also allows > calling the single action with start("authenticate"9, if specified. > > Gian > > Rob Hutton wrote: > >>-----Original Message----- > >>From: php...@li... > >>[mailto:php...@li...]On Behalf Of Giancarlo > >>Sent: Thursday, December 05, 2002 6:49 AM > >>To: phplib-users > >>Subject: Re: [Phplib-users] store the IP in the session > >> > >> > >>Kristian Koehntopp wrote: > >> > Somebody who does not use session cookies, but forces us to use > >> > GET parameters does not want to be secure, either. Again, we can > >> > code around that, but it is useless and bloats our code. > >> > > >> > >>Yes, but also we should explain very clearly, to ourselves first, that > >>using session cookies too, is prone to being forced into using GET... as > >>I am not sure yet there is a strong technical explaination. > >>So I'd add a $sticky_mode session variable to prevent ar allow > >>mode shifts. > >> > > > > That's a question of configuration. If you don't want it to fallback to > > get, then don't enable that. I think it should be defined clearer, > > something like $mode = array("cookie", "get", "post") (vs. the current > > $fallback_mode) because this would allow new modes to be added and a > > preference list built ($mode = array("cert", "cookie")) where cert is an > > extension of cookie that handles pki authentication. But you > can already > > prevent mode shifts. > > > > Secondly, if this is going into the current snapshot auth, Joe > and I have > > some very real problems with the unstructured approach. These > need to be > > addressed before further work is done. I will post the one I > modified to > > the patches area today. > > > > Rob Hutton > > Web Safe > > www.wsafe.com > > > > ********************************************************************** > > > > Introducing Symantec Client Security - Integrated Anti-Virus, > > Firewall, and Intrusion Detection for the Client. > > > > Learn more: > > http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271 > > > > > > > > |
|
From: Giancarlo <gia...@na...> - 2002-12-07 02:52:41
|
Rob Hutton wrote: > This is the beginning of something better. Buth auth should NEVER be done > in a cascade fashion. The should ALWAYS be a control structure. The API say that the checking of the input is to be done in the two auth_validatelogin() and auth_doregister() functions. Note that they are both in local.inc. These functions should return false if the input fields are not provided of wrong or false. Otherwise process the fields. The fields used to be named 'username' ans 'password' in the login form. 'username', pass1','pass2' in the register form. We only provide an example for the login suite, auth_validatelogin ansd loginform.ihml though The missin couple, auth_doregister() and registerform.ihtml that you used for your tests surely had the pwd name 'password' instead of 'pass1', so if you submitted had different names that pass1, and i guess you named the password field just 'password' as in the login form ;-) Anyway what I call cascade is not cascade, and the check_request() function I lately added to use as switch for a control structure, apart from being a 'pre-duplicate' of what (the tests on the input) has already to be done in the two local.inc's function, the only two places where a user was supposed to place his hands in all, for anything related to login and register Note that, in plus, this is placed inside the main class. and not in local.inc. Sorry, I won't change that 'cascade'. Gian Secondly, > there need to be more insertion points. The concept that auth is a abstract > class is a good one IMO. Elimination of local.inc would be a mistake > because now, as long as the API remains backwards compatable, you can drop > local.inc into a newer version of PHPLib and not loose and customization. > > One other thing, everyone please keep discussion on the list and not in > private. There has evidently been a fair amount of off list work going on > that when it hits the list causes much discussion. I appreciate that there > are people that are working on certain modules and have control over them, > but we need to make sure that the changes made to PHPLib make sense for and > to the community. > > Rob Hutton > Web Safe > www.wsafe.com > > ********************************************************************** > > Introducing Symantec Client Security - Integrated Anti-Virus, > Firewall, and Intrusion Detection for the Client. > > Learn more: > http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271 > > > >>-----Original Message----- >>From: Giancarlo [mailto:gia...@na...] >>Sent: Thursday, December 05, 2002 12:05 PM >>To: rob...@ws... >>Subject: Re: [Phplib-users] store the IP in the session >> >> >>I thought about auth. Yesterday I sent Joe this new start structure that >>allows both, structured and,if not, default cascade. It also allows >>calling the single action with start("authenticate"9, if specified. >> >>Gian >> >>Rob Hutton wrote: >> >>>>-----Original Message----- >>>>From: php...@li... >>>>[mailto:php...@li...]On Behalf Of Giancarlo >>>>Sent: Thursday, December 05, 2002 6:49 AM >>>>To: phplib-users >>>>Subject: Re: [Phplib-users] store the IP in the session >>>> >>>> >>>>Kristian Koehntopp wrote: >>>> >>>>>Somebody who does not use session cookies, but forces us to use >>>>>GET parameters does not want to be secure, either. Again, we can >>>>>code around that, but it is useless and bloats our code. >>>>> >>>> >>>>Yes, but also we should explain very clearly, to ourselves first, that >>>>using session cookies too, is prone to being forced into using GET... as >>>>I am not sure yet there is a strong technical explaination. >>>>So I'd add a $sticky_mode session variable to prevent ar allow >>>>mode shifts. >>>> >>> >>>That's a question of configuration. If you don't want it to fallback to >>>get, then don't enable that. I think it should be defined clearer, >>>something like $mode = array("cookie", "get", "post") (vs. the current >>>$fallback_mode) because this would allow new modes to be added and a >>>preference list built ($mode = array("cert", "cookie")) where cert is an >>>extension of cookie that handles pki authentication. But you >> >>can already >> >>>prevent mode shifts. >>> >>>Secondly, if this is going into the current snapshot auth, Joe >> >>and I have >> >>>some very real problems with the unstructured approach. These >> >>need to be >> >>>addressed before further work is done. I will post the one I >> >>modified to >> >>>the patches area today. >>> >>>Rob Hutton >>>Web Safe >>>www.wsafe.com >>> >>>********************************************************************** >>> >>>Introducing Symantec Client Security - Integrated Anti-Virus, >>>Firewall, and Intrusion Detection for the Client. >>> >>>Learn more: >>>http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271 >>> >>> >>> >> >> > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Phplib-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users > |
|
From: Rob H. <rob...@ws...> - 2002-12-06 13:30:37
|
> We are speaking about two different shifts then. I am speaking about
> shifts along the way, not initial fallback. Once a certain mode is
> started, the default or the fallback, LATER do not allow mode shifts. As
> if saying: "hey guy, I told you must have cookies, you HAD cookies, why
> now are you using anything else, if not because I let you do so? How can
> you pretend to be the same guy as before, and now you show me a
> photocopied ticket, while a moment agoI saw you had the original in your
> hand? We ae the cinema tenders, you know... and we've prevented false
> tickets at the entry, now we should prevent swawwing & reentering
> inside...If it makes any sense.
> G
>
OK, but if they are smart enough to sniff a cookie off of the wire, then
they are smart enough to set one. That's what we are trying to prevent,
correct? The movement from cookie to GET?
This is a policy decision of the site admin. If they want to not have mode
changes, then use cookie only. If you want to have gets, then use get only.
if (!session_start("cookie") || session_start("get")) solves the problem.
Having a structured approach with usable features is much more important
than trying to prevent the coder from doing something stupid. If they do,
then it is their fault.
Rob Hutton
Web Safe
www.wsafe.com
**********************************************************************
Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.
Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271
|
|
From: Giancarlo <gia...@na...> - 2002-12-06 23:07:58
|
> > OK, but if they are smart enough to sniff a cookie off of the wire, then I am always talking about unadvertely clicking on a link like https://www.www/www?PHPSESSID=1 somewhere you click on that link that brings your cookie enabled site where, in case I'll register or login or simple visit, someone can reenter in my place and start from the situation as when I left. > they are smart enough to set one. That's what we are trying to prevent, > correct? The movement from cookie to GET? Both, but most worry is from get to cookie. From less to more trust & persistance. Catching this, supposes first that a cookie header is sent anytime even there is a GET request, and not to interprete the presence of GET sid as 'non availability of cookies'. We have two type of tickens at the cine. One is for a isolated, more aseptic, gallery upstair. The other is for the more promiscuous platea down, all together, where there's a lot of germs and it's easier to catch an influenza ;-) You don't do well to your clients that should be lodged in area A to direct them down in area B. And you don't do well either when you let people coming from area B enter area A. Also the referer_check, in case the sid is in the url, is very useful. A must I think. There is a php.ini directive, session.referer_check = www.www it intervenes only when there is a referer. But we can block when there is no referer Bookmarks have no referer, as links in email messages. GET SIDs without a referer, should be checked. This would block a good deal. I don't like the idea that the session management I implement is so easy to spoof on the massive, by absolutely whoever wants, with just a browser. The link itself becomes a troian. It's message #280 by me on this subject. Dunno why everytime I restart this music, some patch reminded me ;-), I am tired . It's so easier to exploit this by anyone, than to explain it to the experts. I even don't care anymore. Forget this and don't worry. G |
|
From: Rob H. <rob...@ws...> - 2002-12-07 15:28:18
|
> > OK, but if they are smart enough to sniff a cookie off of the > wire, then > > I am always talking about unadvertely clicking on a link like > https://www.www/www?PHPSESSID=1 > somewhere you click on that link that brings your cookie enabled site > where, in case I'll register or login or simple visit, someone can > reenter in my place and start from the situation as when I left. This is a cross site scripting vulnerability inherent to the way HTTP works. There is nothing we can do to prevent this. If someone allows HTTP entry on their site, then that is the risk they take. This could easily enough occur with another security breach and a page replacement. This is an application question. > > > they are smart enough to set one. That's what we are trying > to prevent, > > correct? The movement from cookie to GET? > > Both, but most worry is from get to cookie. From less to more trust & > persistance. Catching this, supposes first that a cookie header is sent > anytime even there is a GET request, and not to interprete the presence > of GET sid as 'non availability of cookies'. > We have two type of tickens at the cine. One is for a isolated, more > aseptic, gallery upstair. The other is for the more promiscuous platea > down, all together, where there's a lot of germs and it's easier to > catch an influenza ;-) You don't do well to your clients that should be > lodged in area A to direct them down in area B. And you don't do well > either when you let people coming from area B enter area A. So have one auth that only supports GET, and one that only supports cookies. There is nothing to prevent this right now! > > Also the referer_check, in case the sid is in the url, is very useful. A > must I think. There is a php.ini directive, > > session.referer_check = www.www Referer is not set in the case of Javascript navigation, page refresh, typeing in a direct url, etc. etc. etc. > > it intervenes only when there is a referer. But we can block when there > is no referer > Bookmarks have no referer, as links in email messages. GET SIDs without > a referer, > should be checked. This would block a good deal. I don't like the idea > that the session management I implement is so easy to spoof on the > massive, by absolutely whoever wants, with just a browser. The link > itself becomes a troian. Yes, so use SSL. Problem solved. The CSX vulnerabilities are not solvable. They are inherent in the design of HTML. They require user dillagence to address to some extent, and non stupid programming on the others. PHPLib should not allow CSX in its own code. But we are talking about people writing programs whose job it is to make them secure. All it takes to avoid a CSX is to encode any HTTP traffic you get back. Then anything inside a link gets treated as text. If what you want is to protect from csx's, then write a filter function that all submitted URLs get run through. This does not effect cookies anyway. Here is an example: XYZ has written an app that does not do input filtering and someone enters javascript to read the session cookie and send it to them. They get it, creat the cookie, and now they can hijack the session. No matter how much code is written, without some method of identifying the remote user, either through a certificate or something. The best we can do right now is inform in the docs. If they don't read them, that's their fault. You are trying to solve a problem that has plagued tcp for years. If you open a session, and someone guesses the sequence number, then they can hijack the session. Fortunately, in the TCP world there is connection oriented information. In the HTTP world, there is no connection, just persistence. As in, you can make an object persist from connection to connection. The availability of a cert provides some amount of "connection" information. If the SSL session ID was reliable, then that would be a good identifier. Until there is, we will beat our head against the wall trying to fix a problem that is inherent in the protocol. > It's message #280 by me on this subject. Dunno why everytime I restart > this music, some patch reminded me ;-), I am tired . It's so easier to > exploit this by anyone, than to explain it to the experts. I even don't > care anymore. Forget this and don't worry. > > G > Rob Hutton Web Safe www.wsafe.com ********************************************************************** Introducing Symantec Client Security - Integrated Anti-Virus, Firewall, and Intrusion Detection for the Client. Learn more: http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271 |
|
From: Giancarlo <gia...@na...> - 2002-12-07 22:19:33
|
> This is a cross site scripting vulnerability inherent to the way HTTP works. There is no scripting involved here, it is a plain url. > There is nothing we can do to prevent this. If someone allows HTTP entry on > their site, You can prevent scripting by parsing quotes etc, because they are not allowed inside links. If a link is a danger, any wiki or annotation becomes a danger. Credentials in the url, if treated, should be sorta quaranteened or screened, and not alloweb do mixmax. That's way I propose 'unrepeatable' use-once sequences, made of a fixed part and a secretly preagreed rest. Dunno if amazon does so ;-) > then that is the risk they take. This could easily enough occur > with another security breach and a page replacement. This is an application > question. > > Referer is not set in the case of Javascript navigation, page refresh, > typeing in a direct url, etc. etc. etc. Ok, so why should I accept a GET sid without a referer? >>it intervenes only when there is a referer. But we can block when there >>is no referer > Yes, so use SSL. Problem solved. Again you forget links : https://aaa.com/?PHPSESSID=foo > Here is an example: > > XYZ has written an app that does not do input filtering and someone enters > javascript to read the session cookie and send it to them. They get it, > creat the cookie, and now they can hijack the session. No matter how much > code is written, without some method of identifying the remote user, either > through a certificate or something. That hasn't taken off in so many years now... > You are trying to solve a problem that has plagued tcp for years. If you > open a session, and someone guesses the sequence number, anyone can tell to use 'foo', with php4 session! > then they can > hijack the session. #281 Gian |
|
From: Rob H. <rob...@ws...> - 2002-12-09 13:34:55
|
> > > > This is a cross site scripting vulnerability inherent to the way HTTP > works. > > There is no scripting involved here, it is a plain url. > But where does the url come from. You were talking about clicking on a dangerous url which would steal the session id and send it somewhere. Which is a CSX and would require scripting. > > There is nothing we can do to prevent this. If someone allows HTTP > entry on > > their site, > > You can prevent scripting by parsing quotes etc, because they are not > allowed inside links. If a link is a danger, any wiki or annotation > becomes a danger. Credentials in the url, if treated, should be sorta > quaranteened or screened, and not alloweb do mixmax. That's way I > propose 'unrepeatable' use-once sequences, made of a fixed part and a > secretly preagreed rest. Dunno if amazon does so ;-) But as previously discussed, this is not effective in a connectionless environment where the time between connection may easily be in the order of 10 to 15 minutes. It would be easy for someone to hijack the session in that time. There also has to be a reuse window because multiple frames may be changed at the same time using the same ID. If the reuse time is say, 30 seconds, then someone else has 30 seconds to insert themselves into the session without the other person ever knowing it. Again, this is a false layer of security. > > > then that is the risk they take. This could easily enough occur > > with another security breach and a page replacement. This is an > application > > question. > > > > Referer is not set in the case of Javascript navigation, page refresh, > > typeing in a direct url, etc. etc. etc. > Because there are MANY sites that use Javascript navigation. > Ok, so why should I accept a GET sid without a referer? > > > >>it intervenes only when there is a referer. But we can block > when there > >>is no referer > > > Yes, so use SSL. Problem solved. > > Again you forget links : > > https://aaa.com/?PHPSESSID=foo No I didn't. If you are clicking on a link like this, then it has been generated using a CSX vulnerability. If you are receving a link like this, then the best that you can do at this point is store the last mode that the session was running in and not accept get if mode change protection is turned on. Maybe a sticky flag like you said. > > > > Here is an example: > > > > XYZ has written an app that does not do input filtering and someone > enters > > > > javascript to read the session cookie and send it to them. > They get it, > > creat the cookie, and now they can hijack the session. No matter how > much > > code is written, without some method of identifying the remote user, > either > > through a certificate or something. > > That hasn't taken off in so many years now... Then what are you trying to prevent? > > > > You are trying to solve a problem that has plagued tcp for years. > If you > > open a session, and someone guesses the sequence number, > > anyone can tell to use 'foo', with php4 session! Which is another reason that I argued against the movement toward just native PHP4 sessions. The phplib wrapper prevents this by default if you are running in cookie mode and doing things correctly. > > > then they can > > hijack the session. > > #281 > Gian > > > > Rob Hutton Web Safe www.wsafe.com ********************************************************************** Introducing Symantec Client Security - Integrated Anti-Virus, Firewall, and Intrusion Detection for the Client. Learn more: http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271 |
|
From: Giancarlo <gia...@na...> - 2002-12-11 09:25:55
|
It would be interesting to note how by_necessity_aware sites, eg: easydns, have solved the problem. I remember the guy was on this list in the early times. Gian |
|
From: Rob H. <rob...@ws...> - 2002-12-07 15:06:29
|
Correct, with a major exception. There is no reason why a session could not be transformed from one mode to another. The mode would just have to be stored in auth. Then a page_open would know how to restore the session, and a function such as auth->change_mode would make the change. The list simply specifies the ones you want to allow, and auth would pick the most secure that works. If you want to force a mode change, then no problem as long as it is one of the ones that you support. Rob Hutton Web Safe www.wsafe.com ********************************************************************** Introducing Symantec Client Security - Integrated Anti-Virus, Firewall, and Intrusion Detection for the Client. Learn more: http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271 > -----Original Message----- > From: Giancarlo [mailto:gia...@na...] > Sent: Friday, December 06, 2002 9:18 PM > To: rob...@ws... > Subject: Re: [Phplib-users] store the IP in the session > > > > $fallback_mode) because this would allow new modes to be added and a > > preference list built ($mode = array("cert", "cookie")) where cert is an > > Ok, then in that case you'd certainly want to be able to apply 'cert' > only froim a certain moment on, so be able to migrate your session and > user data from the previous type of session into this new one. And not > impose one choise at the start. > And you'd never let a 'cert' session to downgrade to 'cookie' while > maintaining the same privileges. OTH. > > Gian > > > > > > > > > > > > > > |
|
From: Giancarlo <gia...@na...> - 2002-12-09 00:58:51
|
>>>$fallback_mode) because this would allow new modes to be added and a
>>>preference list built ($mode = array("cert", "cookie")) where cert is
>>Ok, then in that case you'd certainly want to be able to apply 'cert'
>>only froim a certain moment on, so be able to migrate your session and
>>user data from the previous type of session into this new one. And not
>>impose one choise at the start.
>>And you'd never let a 'cert' session to downgrade to 'cookie' while
>>maintaining the same privileges. OTH.
It's somehow also the programmer responsib to see that mode is not
downgraded. You know, the annoying messages when entering/leaving secure
mode.
> Correct, with a major exception. There is no reason why a session could not
> be transformed from one mode to another. The mode would just have to be
> stored in auth. Then a page_open would know how to restore the session
> and a function such as auth->change_mode would make the change.
This the change_mode has to be done while restoring the session, which
happens before any auth exists. So auth has to be able to call a
function that saves the session data, create a new one of the type
wanted, restore the data. There's a patch from me that already does this
for session3, while I committed the $block_alien_sids check to
session.inc in the php-lib-stable cvs. With php4 I couldn't find a way
to do this using php4 session functions. Nor it seems Maxim did, as he
reinserted the known 'Header: 302 Moved there' or similar.
Better if the session has a new sid here, as it acquires a higer grade.
Going back to lower-level cookie/get, things are not much different.
I see in Maxim's that session_start can be executed twice. I wonder what
happens if session.use_only_cookies is set between the two.
The list simply
> specifies the ones you want to allow, and auth would pick the most secure
> that works. If you want to force a mode change, then no problem as long as
> it is one of the ones that you support.
|
|
From: Rob H. <rob...@ws...> - 2002-12-10 13:38:22
|
> -----Original Message----- > From: Giancarlo [mailto:gia...@na...] > Sent: Monday, December 09, 2002 5:05 PM > To: rob...@ws... > Subject: Re: [Phplib-users] store the IP in the session > > > > > > But where does the url come from. You were talking about clicking on a > > dangerous url which would steal the session id and send it somewhere. > > Didn't we aknowledge that a cookie-less, cookie-enabled client, by > clicking on a link as > https://www.xxx.yyy/?PHPSESSID=foo > will: a) get no cookie b)create a session 'foo' on the server, and a > file /tmp/sess_foo c) have trans_sid append ?PHPSESSID=foo to all th > elinks in the page d) expire at gc time, but be recreated again anytime > by clicking on the same link? And thus be a spoofable link 'ad aeternum'? > The cases when we have a GET sid, but no referer can be: > someone has copied on of URLs while @us, and added it to a message or a > web page or his bookmarks. In all cases either we have no referer, or > refere is out of our domain. We don't want to say anything, but silently > discard our SID and redirect him to the clean URL. If you are not running phplib, yes. If you are, no. In phplib, if the session doesn't exist, it does not automagicly create it. I'm not sure about php4 itself, I will look into that, but how php4 behaves does not dictate how phplib behaves. If the session does not exist, then the page_open should fail. But if it doesn't exist, who cares if we create one. It's empty? Best practices should certainly be that we don't allow things to be forces, I agree totally. > > > Which > > is a CSX and would require scripting. > > Scripting is required to modify a page's link to increase that > user-definable SID. Dunno if this would stay right iside the url string > (so that can be parsed out), or may stay elsewhere in the page. Dunno > much JS. > > > > But as previously discussed, this is not effective in a connectionless > > environment where the time between connection may easily be in > the order of > > 10 to 15 minutes. It would be easy for someone to hijack the session in > > that time. > > I will explain that two-part URL better. it is composed of two half, as > ?MySess=111111/aaaaaa > The 111111 is just our unpredictable md5 as before, and is the key of > the session record. The 'aaaaaa' part is never the same. Every link is > made different from the previous, the aaaaaa is taken from a list of > pregenerated ones. Each time is taken one, is marked as taken. Everytime > is used one, is marked as used. New ones are taken from those not yet > taken nor used. One can be taken-and used on the fly, so it does not > need to be 'taken' to become 'used'. > > Suppose that the random pregenerated list is: > aaaaaa > bbbbbb > cccccc > dddddd > > ;-) > > So in a page your links look like: > > page1.php?Mysess=111111/aaaaaa > > page2.php?MySess=111111/bbbbbb > > Page3.php?MySess=111111/cccccc > > and so on. > > To avoid locks, the pregenerated keys can be stored in a dedicate table, > with the name and id as keys as in active_sessions. > A page can also 'preask' an fair enough amount of keys for it's use, > mark them all 'taken', and free the unused ones before end,, to > quickify... There can be an asyncronous job that refills the fresh keys > when nearly ended, or use triggers. > > In practice only those present can know the links. And each is clickable > only once. The only way I can think this can be spoofed is when sent by > the person itself. The browser back can work if the cache settings are > correct. > > > > There also has to be a reuse window because multiple frames may > > be changed at the same time using the same ID. > > Each id is different > > Anyway this is just fantasy. It seems you are among the few that seem > concerned about the things I mentioned. I like the things you proposed > for session, I wonder how much are they possible with php4 propagation, > which is little hackable. Sure having a phased C routine do anything is > a lot faster, but this can be THE sensitive part of it all. > I think we should keep the PHP4 propagation (cookie/get) module as a > whole choice, and define a separate phplib 'propagation' module. In th > eand we have an auth to care about, php4 hasn't. This would repeche > pieces of the sessio class, as Maxim has started doing already, > otherwise there is no 'custom_propagation functions' for coding this in > PHP4. You can control the php4 Session ID though and override the php4 behavior. > > > 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