It’s a Dangerous World: Adding Security - Stripes...and Java Web Development is Fun Again - page 303

A Note About Encryption Keys

By default, Stripes generates a random encryption key to
encrypt values. These values are not decryptable when you
restart the web application or if your application is deployed in
a cluster of nodes.

To make encrypted values reusable across restarts and clus-
ter nodes, you must set a specific encryption key, as explained
Section A.3 , Stripes.EncryptionKey , on page 377 .

Encrypting Parameters
Loading model objects from ID parameters, whether it's with a custom
type converter or with the magic of Stripersist, is pretty cool. Unfortu-
nately, it's also a security issue. When you see a URL such as this:

/ContactList.action?view=&contact=2

you don't have to be a world-class hacker to figure out that this shows
the information of contact ID 2 . It's tempting to resubmit the request
with different values for the contact ID.

Such parameters can be encrypted to prevent users from submitting
random values. The encrypted=true attribute of @Validate does the work:

@Validate(encrypted= true )
private Contact contact;

Now, the contact parameter will be encrypted, as follows:

/ContactList.action?view=&contact=HaAi8A_XHzs%3D

If the user tries to submit a random value, Stripes detects that it is not
a correctly encrypted value and does not bind the parameter.

A little later, in Section 14.5 , Showing Users Their Data, Not Other Peo-
ple's, on page 319 , we'll see how we continue letting users manually
enter values for parameters while still preventing them from seeing data
that is not their own.

14.4 Ensuring the User Is Logged In

Although the webmail application starts at the Login page and requires
the user to log in before entering, we still need to prevent users who are