Thread: [Phplib-users] store the IP in the session
Brought to you by:
nhruby,
richardarcher
Menu
▾
▴
phplib-users
|
From: Giancarlo <gia...@na...> - 2002-12-04 08:00:58
|
I've read on php-dev that Oghaki had added, by himself, a test on a particular Header line (X-something) in the http request,that, in case the client is behind a proxy, would hold the IP of the original requester. That is not 100% sure to be there, but it can still cover a good part of those requests and is better that nothing. Gian |
|
From: Rob H. <rob...@ws...> - 2002-12-04 14:04:41
|
Actually it is not implemented in most circumstances and does not address NAT at all, which is a major issue. 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: php...@li... > [mailto:php...@li...]On Behalf Of Giancarlo > Sent: Wednesday, December 04, 2002 3:01 AM > To: phplib-users > Subject: [Phplib-users] store the IP in the session > > > I've read on php-dev that Oghaki had added, by himself, a test on a > particular Header line (X-something) in the http request,that, in case > the client is behind a proxy, would hold the IP of the original > requester. That is not 100% sure to be there, but it can still cover a > good part of those requests and is better that nothing. > > > Gian > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Microsoft Visual Studio.NET > comprehensive development tool, built to increase your > productivity. Try a free online hosted session at: > http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en > _______________________________________________ > Phplib-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users > > |
|
From: Giancarlo <gia...@na...> - 2002-12-04 15:09:19
|
Rob Hutton wrote: > Actually it is not implemented in most circumstances and does not address > NAT at all, which is a major issue. True. It just can cover a bit more cases that the REMOTE_ADDR Anyway, seen that Kristian is around, I wanted to elaboarte that One_time_password idea. This is a URL only system. The url is something like ?PHPSESSID=11111-aaaaa where '11111' is our traditional md5 32 byte cookie, that stays constant, while 'aaaaa' is another 32 byte part, that always changes. How is the 'aaaa' part taken? On session startup, a fair number of 32 byte random hashes is generated, and saved in the session. The url-rewriting function ($sess->url() ?) appends to each hyperlink one different hash, taken from the session array whith these pregenerated ones, and flags it as 'shown'. Upon requesting one of these links, the session fuunction checks that the 'aaaa' part is among the ones flagged as shown. If it is, it flags it as 'used', otherwise no way. No cookie, only GET, and no possibility to guess or steal the second half. A lot of CPU on 'refilling' the array once exhausted, though. How does it sound? Gian |
|
From: Kristian K. <kr...@ko...> - 2002-12-04 15:42:55
|
On Wed, Dec 04, 2002 at 04:09:15PM +0100, Giancarlo wrote:
> No cookie, only GET, and no possibility to guess or steal the second
> half. A lot of CPU on 'refilling' the array once exhausted, though.
You do not need different hashes on different URLs, or at least
I cannot see why you should. Instead the session can have an
internal sequence number, which is appended to the SID in a
hashed form. So you do
$validator = md5($sess->id . $sess->seq . $sess->magic);
and append "{$sess->id}-$validator" to each sid in a URL. Also, you
increment $sess->seq in page_open() as soon as you instantiated
$sess.
Using the saved $sess->seq from the session, you can validate
the session id by precalculating the validator and compare it to
the validator you received.
This will protect the session against replay attacks, and will
also prevent insertion of requests from an attacker into a
sequence of requests from a legitimate user, because the
attacker cannot predict the validator without knowledge of the
proper $sess->seq AND knowledge of the $sess->magic.
It will also make sessions very fragile, no more back buttons at
all. I do not recommend this for any production environments.
Use SSL instead. Saves you the pain of the implementation,
protects against more attacks and is easier to deploy.
Kristian
|
|
From: Marko K. <M.K...@os...> - 2002-12-04 16:16:07
|
Hi Kristian, good to see that you are still watching your baby phplib! :) > increment $sess->seq in page_open() as soon as you instantiated wahhh, and this would also cause problems in frame-based sites which have pages which do not call page_close() at the end. We once had discussion about this. That would require to shift the generation of the new hash in page_close instead, being less secure again... I'd also support SSL instead, that would make much easier phplib-wise. All these concerns about securing the session would be handed over to the SSL part. But on the other hand one knows that into SSL one could break in as well... There was another thread about this some weeks ago. But probably one could never make phplib sessioning as secure as SSL is right from the start... I guess. Why not to finish all these IP discussions then? Let's simply trigger the user to use SSL for safer sessions, which is fairly easy to do if you've got your own secure apache running. These auth things seem to be quite settled already. Shouldn't we focus more now on a new phplib4 cvs release which could be based on the snapshot on sf and deploy that in a user-friendly manner? Marko |
|
From: Giancarlo <gia...@na...> - 2002-12-04 18:16:13
|
> Why not to finish all these IP discussions then? Let's simply trigger the > user to use SSL for safer sessions, which is fairly easy to do if you've Excuse me, but if I propose you to click on a link as https://phplib.sourceforge.net/showoff.php3?PHPSESSID=1 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? The typical illiterate snooper exploit is just this. Gian |
|
From: Giancarlo <gia...@na...> - 2002-12-04 18:33:44
|
Giancarlo wrote: > Excuse me, but if I propose you to click on a link as > https://phplib.sourceforge.net/showoff.php3?PHPSESSID=1 ^^^^^^^ Notice that is using SSl. So the idea to mark the session somehow, to prevent opening starting user-chosen, unexistent id, is good. The ide of the IP i'd let implement to those who want. Now, even if we accept only id created by us, one can have php(4/lib) create it, and offer that in the URL. It will work only once though, which is better yet. BUT, if when we crete the session, we remember the 'mode' at that moment (get/cookie), then this will be possible only when both A and B have cookies disabled. Which restricts further and further, because the traansmission, in that standard illiterate exploit, must pass through GET in any case. I know the solution is sheating the hull. I question how much this is a valid reason for not plugging the holes anyway. G |
|
From: Kristian K. <kr...@ko...> - 2002-12-05 09:08:40
|
On Wed, Dec 04, 2002 at 07:33:44PM +0100, Giancarlo wrote: > Giancarlo wrote: > >Excuse me, but if I propose you to click on a link as > >https://phplib.sourceforge.net/showoff.php3?PHPSESSID=1 > ^^^^^^^ > Notice that is using SSl. > > So the idea to mark the session somehow, to prevent opening starting > user-chosen, unexistent id, is good. > The ide of the IP i'd let implement to those who want. Somebody who does not use SSL does not want to be secure. You could code around that, but you would end up reimplementing SSL at the user level, which is silly. 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. If you want to implement a secure site, offer SSL and cookie mode. If your users do come in not using SSL, offer them a link to your SSL site. If your users do come in not using cookies, offer them a link to a page that explains why this is a bad thing to do and how they can change that. Also install a proper P3P policy. If they choose not to use the help you offer, it is their risk, they take it against our recommendation and their better knowledge, and we cannot help them. We really should not bloat our code for them. Kristian |
|
From: Giancarlo <gia...@na...> - 2002-12-05 11:48:30
|
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. Gian |
|
From: Rob H. <rob...@ws...> - 2002-12-05 14:57:17
|
> -----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-05 17:19:27
|
>>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.
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 is
it than now you bear a low-grade photocopied ticket, while a moment agoI
saw you had the original in your hand? From the series We are the
cinema tenders, you know... and we've prevented false
tickets at the entry, now we should prevent swapping tickets inside &
reentering ...If it makes any sense. kindof pindaric may seem, but...
G
|
|
From: Giancarlo <gia...@na...> - 2002-12-05 17:42:02
|
> 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. Yes, I had the doubt yesterday that there was some expectation on that auth. But that has absolutely nothing to do with this sessio problem. Last night I sent jos the last auth.inc, wich now can handle thre different situation. It can be callaed without a $request value, the default, as before, and it will first try to act on return by a check_request() function, or a passed funcion name. Otherwise will fall cascade. I think you can place the (try) register before login, to prevent loggin in when someone submit for register an existing username/pass/ pair. BTW, back to session I put back php 4.2.1, tried both the new Maxim's and the old session4 by Joe, and both do not workk with php 4.0.6 https://sourceforge.net/tracker/download.php?group_id=31885&atid=403613&file_id=36932&aid=561500 |
|
From: Giancarlo <gia...@na...> - 2002-12-05 20:47:41
|
> BTW, back to session I put back php 4.2.1, tried both the new Maxim's > and the old session4 by Joe, and both do not workk with php 4.0.6 This is because the superglobal _SESSION started to exist sometime after 4.06. I wonder if we can pass a check for something, and in case it results not supported create and use an alternative $GLOBALS["_SESSION"] as-if... sounds horrible eh? G |
|
From: Maxim D. <max...@bo...> - 2002-12-05 09:25:16
|
Giancarlo wrote: G> So the idea to mark the session somehow, to prevent opening starting G> user-chosen, unexistent id, is good. G> The ide of the IP i'd let implement to those who want. So, I suppose the question on IP-bound sessions is closed. We won't bind a session to IP, because it adds a layer of complexity and does not do what it was intended for in many cases. However, we of course can prevent starting a new session with the user-provided session id. I guess, a boolean marker in the session would be enough (it reminds me of secure_auto_init and $sess->in in Session3 ...). -- Best regards, Maxim Derkachev mailto:max...@bo... IT manager, Symbol-Plus Publishing Ltd. phone: +7 (812) 324-53-53 www.books.ru, www.symbol.ru |
|
From: Giancarlo <gia...@na...> - 2002-12-05 11:36:20
|
Maxim Derkachev wrote: > user-provided session id. I guess, a boolean marker in the session I called it $allow_alien_sids ;-) in the php3 session.inc, you call it $forgery_check... Gian |
|
From: Matt W. <li...@ye...> - 2002-12-04 19:32:08
|
On Wednesday 04 December 2002 18:16, Giancarlo wrote: > > Why not to finish all these IP discussions then? Let's simply trigger= the > > user to use SSL for safer sessions, which is fairly easy to do if you= 've > > Excuse me, but if I propose you to click on a link as > https://phplib.sourceforge.net/showoff.php3?PHPSESSID=3D1 > > 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= ? > > The typical illiterate snooper exploit is just this. But that would be user error. If someone was stupid enought to do that ma= ybe=20 they deserve whatever happens to them Excuse my ignorance on this but wouldn't a way round it to use per sessio= n=20 er.. sessions. So as soon as the browser closed the session ended. Assumi= ng=20 of course that all reference to the session was removed from wherever it = was=20 stored on the server. matt |
|
From: Giancarlo <gia...@na...> - 2002-12-04 21:01:30
|
>>Excuse me, but if I propose you to click on a link as >>https://phplib.sourceforge.net/showoff.php3?PHPSESSID=1 >> >>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? >> >>The typical illiterate snooper exploit is just this. > > > But that would be user error. If someone was stupid enought to do that maybe > they deserve whatever happens to them Do you check all the links before clicking them? If all app servers had that, can you imagine the billions of troyan bookmarks? The fact that even expired can reborn same same, is of much worry, and the check_for_existance by Maxim fixes that so ++ Gian |
|
From: Rob H. <rob...@ws...> - 2002-12-04 22:51:47
|
Connections are transiant, so there is no way of knowing when the browser closed. This is the reason for timeout on auth and session. They become invalid after X time. 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: php...@li... > [mailto:php...@li...]On Behalf Of Matt > Williams > Sent: Wednesday, December 04, 2002 2:31 PM > To: phplib-users list > Subject: Re: [Phplib-users] store the IP in the session > > > On Wednesday 04 December 2002 18:16, Giancarlo wrote: > > > > Why not to finish all these IP discussions then? Let's simply > trigger the > > > user to use SSL for safer sessions, which is fairly easy to > do if you've > > > > Excuse me, but if I propose you to click on a link as > > https://phplib.sourceforge.net/showoff.php3?PHPSESSID=1 > > > > 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? > > > > The typical illiterate snooper exploit is just this. > > But that would be user error. If someone was stupid enought to do > that maybe > they deserve whatever happens to them > > Excuse my ignorance on this but wouldn't a way round it to use > per session > er.. sessions. So as soon as the browser closed the session > ended. Assuming > of course that all reference to the session was removed from > wherever it was > stored on the server. > > matt > > > ------------------------------------------------------- > This SF.net email is sponsored by: Microsoft Visual Studio.NET > comprehensive development tool, built to increase your > productivity. Try a free online hosted session at: > http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en > _______________________________________________ > Phplib-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users > |
|
From: Rob H. <rob...@ws...> - 2002-12-04 18:56:17
|
> Hi Kristian, good to see that you are still watching your baby phplib! :) > > > increment $sess->seq in page_open() as soon as you instantiated > wahhh, and this would also cause problems in frame-based sites which have > pages which do not call page_close() at the end. We once had discussion > about this. That would require to shift the generation of the new hash in > page_close instead, being less secure again... This could be easily addressed by maintaining a list of unique, non-incremental ids that are valid for a certain period of time, exactly the way IP does it. The scheme wouldn't even have to be blocking, and could allow multiple frames to use the same ID as long as it was within the lifetime of the list. The problem is that this does nothing to tie the session to a certain machine. The only way to do this is with public key authentication. Like SecureID does, and hopefully DNSSec will do also in the future. Or, if it is a higher security environment now, so like Kristian says and get a key from a PKI authority. I am talking about easy to use and cheap stuff that does not require the user to do anything. > > I'd also support SSL instead, that would make much easier phplib-wise. All > these concerns about securing the session would be handed over to the SSL > part. But on the other hand one knows that into SSL one could break in as > well... There was another thread about this some weeks ago. But probably > one could never make phplib sessioning as secure as SSL is right from the > start... I guess. Without some sort of universal PKI scheme, you are correct. There is just no reliable way to tie to a specific person/machine. > > Why not to finish all these IP discussions then? Let's simply trigger the > user to use SSL for safer sessions, which is fairly easy to do if you've > got your own secure apache running. > > These auth things seem to be quite settled already. Shouldn't we focus > more now on a new phplib4 cvs release which could be based on the snapshot > on sf and deploy that in a user-friendly manner? > > Marko > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Microsoft Visual Studio.NET > comprehensive development tool, built to increase your > productivity. Try a free online hosted session at: > http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en > _______________________________________________ > Phplib-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users > 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-04 21:46:05
|
>> The problem is that this does nothing to tie the session to a certain >> machine. I have a magic word for this. It is 'responsability'. When you mention this word... PKI really points out the fact that the sysadmin really has a responsability, you know? For now is holiday... ;-) Gian |
|
From: Rob H. <rob...@ws...> - 2002-12-04 22:49:57
|
> > Rob Hutton wrote: > > This could be easily addressed by maintaining a list of unique, > > non-incremental ids that are valid for a certain period of > time, exactly the > > way IP does it. > > You mean a single overall list, server wide, not a per session one? No, it would be a list per session. The problem is that if you have frames, then you will get a different id per frame, and at any time, one of those frames may resubmit, with whatever the value is at the time, so you have to maintain a list of acceptable ids so that you don't break frames. There may be multiple submissions from different frames with the same unique ID, or you could have multiple submissions from different frames with different IDs. But you don't want them to be available forever, so there has to be an expirations on them. > > > The scheme wouldn't even have to be blocking, and could > > allow multiple frames to use the same ID as long as it was within the > > lifetime of the list. > > > > The blocking/non blocking I was thinking about... By non-blocking you > mean 'shared', or 'that can be used again'? In reality if you use the > same validator on multiple links, you block them, because only one can > be clicked. I don't think you can flag some as 'usable more the once', > otherwise the security evaporates. Unless when you reuse one of these, > you mark as 'used' all the still unused ones, and regenerate them again > in that page. A lot of work. Blocking means that only one process can have a particular session open at a time. So, there is a switch on the session record which is something like locked, if locked, then you wait X time. When X has passed, you try again. You go through that Y times. Then you fail. > > > > The problem is that this does nothing to tie the session to a certain > > machine. > > But that would be great way forward anyway. Imagine, no more > cookie burden. You still have the problem with cookies as you may have a machine where the same person has multiple sessions open. There is always going to have to be a way to tie the session ID to a particular browser session, even if has been authenticated and cannot be hijacked. > > > The only way to do this is with public key authentication. > > > > 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 |
×
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