myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Byrne <den...@dbyrne.net>
Subject Re: t:saveState server/client ... or request/session
Date Wed, 12 Oct 2005 19:34:30 GMT
Hmmm ... I was not aware of this secret gathering.  I'm 
dennisbyrne for sf.

---- Original message ----
>Date: Wed, 12 Oct 2005 15:19:04 -0400
>From: Mike Kienenberger <mkienenb@gmail.com>  
>Subject: Re: t:saveState server/client ... or 
request/session  
>To: MyFaces Discussion <users@myfaces.apache.org>
>
>I can add you as a member of jsf-comp if you think it might 
be easier
>to make it available there.   That'd give everyone who's 
interested a
>chance to take a look, as well as fix problems in a central 
area.  
>This is sort of a staging area for MyFaces ideas and 
projects, open to
>anyone who'd like to be involved.  Just send me your 
sourceforge id.
>
>http://sourceforge.net/projects/jsf-comp/
>
>On 10/12/05, Dennis Byrne <dennis@dbyrne.net> wrote:
>> Good, I'll just email it to your gmail account before I 
even
>> open the issue.
>>
>>
>> ---- Original message ----
>> >Date: Wed, 12 Oct 2005 14:51:38 -0400
>> >From: Mike Kienenberger <mkienenb@gmail.com>
>> >Subject: Re: t:saveState server/client ... or
>> request/session
>> >To: MyFaces Discussion <users@myfaces.apache.org>
>> >
>> >Yeah, that's a good point.   I'm going to enhance whatever
>> you come up
>> >with to add the ip address into the state and validation.
>> Maybe you
>> >can leave in a hook for "adding" other authentication info
>> into the
>> >mix.   Or I suppose I can create my own delegating
>> StateManager to do
>> >it.  Might be better that way.
>> >
>> >On 10/12/05, Dennis Byrne <dennis@dbyrne.net> wrote:
>> >> >Saving the key in each session might work.   The
>> environment
>> >> may
>> >> >preserve server-side sessions across restarts, 
depending
>> on
>> >> the
>> >> >configuration.
>> >>
>> >> Yes, and javax.crypto.spec.SecretKeySpec implements
>> >> Serializable.  There are of course risks w/ a key being
>> >> stored in serialized sessions.
>> >>
>> >> >I'd also like to recommend that the data is signed 
rather
>> >> than just
>> >> >encrypted.   For me, having a cryptologically-signed 
state
>> >> is more
>> >> >important than encrypting the state.    I'm not 
concerned
>> >> that the
>> >> >end-user can read the state (after all, most of the 
state
>> is
>> >> visible
>> >> >in another form already).   I just don't want the end-
user
>> >> to be able
>> >> >to modify it.
>> >>
>> >> For the short term , I'll just focus on encryption.  The
>> >> immediate problem I have is that I am using saveState 
for
>> >> conversations.  This lets an attacker post their own 
model.
>> >> It also lets people see the values of properties that I 
do
>> >> not intentionally render.  Encryption of course 
guarantees
>> >> confidentiality (but in this case, only between the 
server
>> >> and itself) while a signature guarantees integrity.
>> >>
>> >> You are right however that encryption is not enough.
>> >> Consider the following paranoid example.  Mike K. is an
>> admin
>> >> and Sean S. is not.  Sean however is on the same network
>> >> segment as Mike which means he can listen for Mike's 
state.
>> >> Sean can then post Mike's state, and because the key is
>> >> global, the app will gladly decode, decrypt and restore
>> >> Mike's priveledged view.  He can totally by-pass any
>> security
>> >> at the database and application levels.  Damn that 
Sean ;)
>> >>
>> >> Dennis Byrne
>> >>
>> Dennis Byrne
>>
Dennis Byrne

Mime
View raw message