Re: T5: secure state storage on the client

[Howard Lewis Ship <hl...@gmail.com>]

I've been thinking about this as well.

I think the most secure approach will be to store the serialized data
in a temporary (embedded or flat file) database on the server, and
send just a short, opaque identifier to the client. This has the added
benefit of storing significantly less data on the client side (which
might allow the use of GET for forms that do no modify externally
persistent state).

Certainly, "salting" the identifier with a session id, or other value
that uniquely identifies the user, will be important.

I can see two different "stores" for this data; one for unidentified
visitors that "salts" with the user's IP address, the other that
"salts" with the session id.

Clustering issues will make this more complex.

On 1/20/07, Kent Tong <ke...@cpttm.org.mo> wrote:
> Hi,
>
> In T5 every form stores a bunch of data on the client in a hidden field. It
> is mainly serialized action commands to be executed on form submission to
> restore the states of the form components (eg, element name). This is
> very convenient and can relieve the component user (eg, the page) from
> the task of maintaining the state. This is similar to the "view state" in
> ASP.NET. However, it is a serious security issue as a hacker may modify it
> to execute any existing code on the server that implements the command
> interface.
>
> One may sign the view state using a key generated in the app. However, a hacker
> may inject it into any other context (different component, different component
> context, different user) without modifying it. So, we have to relate this
> view state to the same component & context (the action URL in the form) and
> to the same user (the session). Therefore, we may sign the view state+the
> complete URL using the session ID.
>
> As the session will expire in time, this should fight against replay attacks.
>
> However, the cost is that whenever we display a form, we will use a session.
>
> Any idea?
>
> --
> Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>


-- 
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

Re: T5: secure state storage on the client

[Kent Tong <ke...@cpttm.org.mo>]

Howard Lewis Ship <hlship <at> gmail.com> writes:

> I think the most secure approach will be to store the serialized data
> in a temporary (embedded or flat file) database on the server, and
> send just a short, opaque identifier to the client.

This sounds more secure. However, I am not sure if it is really more
secure (than storing data signed by a server key on the client). Any
example showing otherwise?

> This has the added
> benefit of storing significantly less data on the client side (which
> might allow the use of GET for forms that do no modify externally
> persistent state).

OK. However, a view state is most likely only used once almost immediately
(when the form is submitted), unless the user uses the back button. 
>From this view point, storing it in a file or DB doesn't sound like 
the best approach.

> Certainly, "salting" the identifier with a session id, or other value
> that uniquely identifies the user, will be important.
> 
> I can see two different "stores" for this data; one for unidentified
> visitors that "salts" with the user's IP address, the other that
> "salts" with the session id.

I understand the desire to avoid creating a session. However, it is
just a session without any data in it. Do you know of any reference
suggesting that this may be a performance problem? As there is no
data in it, it won't affect performance in a cluster.

The use of IP is not foolproof, eg, people using a proxy or NAT. We'll
also need to time out the items in store to make sure the state is
time limited. This is more troublesome for those using a proxy. Using
IP for this purpose is like creating a fake session. If there is a
real session for us to use, not why just use it?
 
> Clustering issues will make this more complex.

Right. Here is a summary so far:

1) Signed data on client, salted with session id, signed by server key.
2) Data on server, salted with session id.
3) Data on server, salted with IP.

                             1)                     2)              3)
-----------------------------------------------------------------------------
A) Security                  Less secure than 2)?   Secure          Not secure
B) Can use GET               N                      Y               Y
C) Bandwidth use             Higher                 Lower           Lower
D) Disk space use            Lower                  Higher          Higher
E) Need a session (no data)  Y                      Y               N
F) need to time out and      N                      Y               Y
   delete items in server 
   side stores





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

Re: T5: secure state storage on the client

[Massimo Lusetti <ml...@gmail.com>]

On 1/20/07, Howard Lewis Ship <hl...@gmail.com> wrote:

> I've been thinking about this as well.
>
> I think the most secure approach will be to store the serialized data
> in a temporary (embedded or flat file) database on the server, and
> send just a short, opaque identifier to the client. This has the added
> benefit of storing significantly less data on the client side (which
> might allow the use of GET for forms that do no modify externally
> persistent state).
>
> Certainly, "salting" the identifier with a session id, or other value
> that uniquely identifies the user, will be important.
>
> I can see two different "stores" for this data; one for unidentified
> visitors that "salts" with the user's IP address, the other that
> "salts" with the session id.
>
> Clustering issues will make this more complex.

Please don't force the use of a session.

-- 
Massimo
http://meridio.blogspot.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org