Hey Marcus, You are definitely right. I took the wrong example. Here's a better one: User A has the right to see the details of a customer named Harry with the database id 5. Typically he clicks a link to the details page which contains the encryped id value as paramter. The details page takes an id as parameter, queries the database for the customer with the given id and renders its details to html. The user details are cached in the session for faster response time if user A requests this customer again. Stripes encrypts the id 5 of customer Harry to tqFUzKpKj6g=. User A copies this id into his clipboard because he is very l33t :-). Then the admin revokes his right to view the details of customer Harry and forces User to relogin(so the cache gets cleared). User A won't see the link to the details of customer Harry anymore. So the server does not write out the id 5 anymore. Now the l33t User A takes another details link and replaces the encrypted id with the one from his clipboard. And he will see the details of customer Harry. This is because the server accepts a parameter which he did not write out. This one is taken from the release notes of stripes 1.5.1:
Transparent encryption of ActionBean property values. You can now use @Validate(encrypted=true) to cause ActionBean property values to be encrypted before being written to a page in a link or form input. This is meant for cases where you want to send a value back to the server with assurance that it is the same value that was written by the server. According to this statement, User A should not be able to see the details of customer Harry and stripes should throw an exception telling that the input was not written out by the server. In this case, generating a different encryption key for each session would solve the problem. Hope I explained better this time, Richard PS:I know that I can prevent User A to see the details of customer Harry with a proper query but thats no the point here. On Wed, May 13, 2009 at 3:27 PM, M.C.S. <[email protected]> wrote: > Hi Richard, > > Richard Hauswald schrieb: >> Accoring to the docs, the same passphrase is used to encrypt/decrypt >> values. So a user A will share the same key with user B(with different >> htpp sessions). If user A gets an encrypted value(eg by sniffing) from >> user B, eg a database id, he can send it to stripes and stripes will >> decrypt it. This is IMHO a security problem. >> > the session id can be sniffed, too. Changing the encryption key for > every new session won't solve the problem. Using a secure network > connection will be necessary. > > Regards, > Marcus > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > production scanning environment may not be a perfect world - but thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > _______________________________________________ > Stripes-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/stripes-users > ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Stripes-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-users
