[Advanced-java] Sensitive Data -> StringgetParameter(String ) Alternative

[Martin Cooper]

> -----Original Message-----
> From: Nikolaos Giannopoulos [mailto:nikolaos@solmar.ca]
> Sent: Monday, May 05, 2003 8:06 AM
> To: Martin Cooper
> Cc: advanced-java@lists.xcf.berkeley.edu
> Subject: RE: [Advanced-java] Sensitive Data -> 
> StringgetParameter(String
> ) Alternative
> 
> 
> Martin,
> 
> Thanks for the excellent feedback... comments inline...
> 
> 
> > -----Original Message-----
> > From: Martin Cooper [mailto:martin.cooper@tumbleweed.com]
> > Sent: Friday, May 02, 2003 2:06 PM
> >
> >
> > I don't believe this will do what you want. When the 
> container parses the
> > request, it's almost certainly going to build up a map of 
> name/value pairs
> > for the parameters, one of which will correspond to your credit
> > card number.
> 
> I agree but... see below...
> 
> 
> > Using toCharArray() will ensure that *your* code doesn't 
> have the card
> > number in a string, but the container will still have it.
> 
> Sure.  And to solve the immediate problem at hand in our 
> application we can
> all agree that this will help somewhat for *my* code - 
> especially in cases
> wherein the payment gateway is down and data is queued.
> 
> 
> > I think the only way you can get around this is to use a POST
> > that uses the
> > multipart/form-data encoding, and then parse the entire 
> request yourself
> > after calling request.getInputStream().
> 
> Can "multipart/form-data encoding" be POSTed over HTTP using 
> a standard Html
> Form POST in a browser OR using JSP?  I don't think so but I 
> could be wrong.

Yes, of course. All you need to do is set the 'enctype' attribute of the
<form> element to "multipart/form-data". This is what you would do if you
needed an <input type="file"> element in your form.

> 
> 
> > Actually, the latest version (meaning HEAD in CVS, not yet 
> released) of
> > Jakarta Commons FileUpload would probably help you a lot with
> > this.
> 
> Same comment as previous.  I see where your going with this 
> but unless any
> solution can be easily integrated to a browser 
> HTML/CSS/JavaScript OR JSP
> mechanism its just not going to help very much i.e. a 
> solution that offers
> "more" security at the cost of nobody using it is more secure 
> but with very
> little OR zero value.
> 
> 
> > It's conceivable that you could get away with parsing a regular POST
> > yourself, but that would depend entirely on exactly when 
> your container
> > decides to parse the request. That being the case, it certainly
> > wouldn't be portable, and I wouldn't recommend this approach.
> 
> And now for a different angle:  A high traffic web server / 
> servlet engine
> that hangs onto request/response data is not going to scale 
> very well will
> it? i.e. I haven't examined how web servers or servlet 
> engines handle their
> request data but I would imagine that the mechanism would be "discard
> request/response data as fast as possible in order to acheive greater
> scalability".
> 
> Of course "discard" is a loaded word with respect to servlet 
> engines as
> server memory, max application memory settings, server load, 
> and garbage
> collection algorithms all will contribute to how long it 
> truly takes for
> this data to be discarded from physical memory.  Once again I 
> could be wrong
> here but this was my initial reasoning for not worrying so much about
> request/response data in comparison to having data retained 
> in my app for an
> hour or a couple hours.

You're right. I glossed over the part of your original post where you were
talking about avoiding long-term retention as a string, and was really
referring to the retention by the container for the duration of processing
the request.

--
Martin Cooper


> 
> In the end, I totally welcome any solution that will make 
> things more secure
> as long as it doesn't create a greater hassle for the 
> customer e.g. Java
> applets and plug-ins are out for numerous reasons as history 
> has already
> shown i.e. Security considerations must always be balanced 
> against other
> considerations and unfortunately for e-commerce ease of use 
> is a big one to
> balance against.
> 
> Thanks,
> 
> --Nikolaos
> 
> 
>