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

[Nikolaos Giannopoulos]

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.


> 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.

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