struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Al Sutton <>
Subject Re: [s2] Whats the most strutsy way of doing....
Date Fri, 27 Jun 2008 16:41:53 GMT
Hi Jeromy,

Thanks for the comments.

I'm trying to steer away from javascript for the solution in order to 
maximise browser compatibility (this app may be used on older mobile 

I'm hoping that AES encryption isn't cracked ;), and by the inclusion of 
some random noise in the properties list it should reduce the chances of 
a simple brute force attack by increasing the length of the encrypted 
data and not making the plain text obvious.

I can understand the problems with your plugin, My architecture stores 
only the userId in the session and gets the user from the database as 
needed (due to the back end being JPA/Hibernate and the user having 
ManyToOne and OneToMany relationships I can't simply store the user in 
the session). The system I'm going to implement will decrypt the data 
from the cookie, verify it as valid, and then populate the session with 
the neccessary information, all of which will be serializable objects 
(Long, String, etc.)

Thanks again,


Jeromy Evans wrote:
> Al Sutton wrote:
>> Dave,
>> I'm completely agree it's a great idea and useful thing to do, but 
>> the problem is what to put into the cookie and how to map it to the 
>> user.
>> My current favourite is encrypt the properties you want to store 
>> (using AES for speed and JCE support), then decrypt and inject when 
>> needed. Cookies should be considered limited to 4K (due to the joys 
>> of RFC2109 Section 6.3), so as long as the data fits joy shall be 
>> mine :).
>> Al.
> Hi Al,
> Just another variation I use where the useragent requires javascript:
> authenticate the user and generate a token; the token doesn't contain 
> any sensitive data;
> the token is saved in a cookie and included in all requests (as 
> cookie, header or param)
> an s2 interceptor checks the token is matched to an authenticated 
> user. it injects relevant details to actions
>       (eg. a store maps tokens to users; server-side manages expiry, 
> concurrent logins etc)
> It's not as fast as encoding login information in the cookie but it 
> can't be broken.  I use the same method to sign XHR requests.
> If the user has checked the "remember me" box the javascript gets the 
> token from the cookie and resumes using it.  The server it knows not 
> to invalidate that token.
> Vulnerabilities:
>  - The token should be unguessable to minimize forged requests;
>  - as javascript is inscecure, tokens can be stolen from the cookie 
> (eg. by an advertisement, XSS)
> I wrote the above as an S2 plugin. The only problem with releasing it 
> as a plugin is that the "service that checks tokens" can't be 
> Xwork'@Inject'ed into the interceptor (rather it has to be injected 
> via spring or guice) due to its potential external dependencies (eg. 
> an EntityManager).  The same plugin also allows me to apply roles to 
> action methods (jsr-250).
> cheers,
> Jeromy Evans
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message