Security and information passing

[Thom Burnett <th...@gmail.com>]

What are the options within Struts (version 1)  for passing information from
one request to the next on a multi-page struts application?

I can pass some information as request parameters and hidden inputs on forms
but that's not acceptable for credit card numbers, passwords, etc.
What are the other options and how do they work?

How, if at all, do people manage a single sign on to pages when a user needs
to sign in.
If there are some URLs with discussion on the topics, let me know.

RE: Re: Security and information passing

[Bruno Melloni <Br...@wnco.com>]

Also, if you are dealing with credit card numbers, make sure you study
up on PCI regulations.  There are specific rules about how much of the
number you may keep short-term and long-term, what strength of
encryption is required, etc.  And pretty severe penalties for your
company if you fail to follow the rules.

-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Laurie Harper
Sent: Tuesday, May 08, 2007 12:27 PM
To: user@struts.apache.org
Subject: Re: Security and information passing

Thom Burnett wrote:
> What are the options within Struts (version 1)  for passing 
> information from one request to the next on a multi-page struts 
> application?
> 
> I can pass some information as request parameters and hidden inputs on

> forms but that's not acceptable for credit card numbers, passwords, 
> etc.
> What are the other options and how do they work?

The options are about the same as in any web application; there's
nothing Struts-specific here.

1) put sensitive data into the session; make sure you force a secure
transport (HTTPS) to prevent session spoofing

2) store sensitive data into your database or other persistent store,
passing a row key or other identifying information so you can retrieve
it on the next request; of course, you then need to treat that row key
or whatever as sensitive data, and apply one of the other options for
that

2) include sensitive data as (one or more) hidden inputs on each form,
but encrypt the data; include a hash/checksum of the encrypted data to
help detect tampering

There may be other approaches I'm not thinking of right now as well :-)

> How, if at all, do people manage a single sign on to pages when a user

> needs to sign in.

That's a bit vague... There are countless ways to handle authentication
in a Java web application; it all depends on your requirements. Single
Sign On for a single web app is obviously trivial ;-) so it depends on
what your authentication scheme need to interoperate with, to start
with.

L.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Security and information passing

[Laurie Harper <la...@holoweb.net>]

Thom Burnett wrote:
> What are the options within Struts (version 1)  for passing information 
> from
> one request to the next on a multi-page struts application?
> 
> I can pass some information as request parameters and hidden inputs on 
> forms
> but that's not acceptable for credit card numbers, passwords, etc.
> What are the other options and how do they work?

The options are about the same as in any web application; there's 
nothing Struts-specific here.

1) put sensitive data into the session; make sure you force a secure 
transport (HTTPS) to prevent session spoofing

2) store sensitive data into your database or other persistent store, 
passing a row key or other identifying information so you can retrieve 
it on the next request; of course, you then need to treat that row key 
or whatever as sensitive data, and apply one of the other options for that

2) include sensitive data as (one or more) hidden inputs on each form, 
but encrypt the data; include a hash/checksum of the encrypted data to 
help detect tampering

There may be other approaches I'm not thinking of right now as well :-)

> How, if at all, do people manage a single sign on to pages when a user 
> needs
> to sign in.

That's a bit vague... There are countless ways to handle authentication 
in a Java web application; it all depends on your requirements. Single 
Sign On for a single web app is obviously trivial ;-) so it depends on 
what your authentication scheme need to interoperate with, to start with.

L.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org