File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Servlets and the fly likes Crypto and hidden fields. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "Crypto and hidden fields." Watch "Crypto and hidden fields." New topic

Crypto and hidden fields.

Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

First I'll say: Yes, this is Servlets related - at least the first part...

We have a setup where we have 'n' http domains that all must process their e-commerce stuff through '1' https (SSL protected) domain. In order to bounce between the servers, we're doing the fairly simple trick of outputing a form (on the http side) that uses javascript to POST itself to the https side.

SO... that hidden field called "theAmountOfMoneyYouOweUs" is completely visible and 'hackable' by anyone with the least amount of browser know-how. Just turn of javascript and create your own form submission.

I thought to do something like the following:

I can concatentate all the parameters I need into a big tokenized String, encrypt it on the http side with the public key. Then on the https side, I use the private key to decrypt the received String, and tokenize and pull out the pieces again. I could also use symmetric enc (one private key).

1) Is this just stupid? What other ways can I solve this problem of wanting to protect/obscure form post data between domains? (this is why I've posted this to Servlets.. perhaps someone can point out the obvious answer I've missed).

Here's where it gets past Servlets a bit...

2) I've never done crypto before, and I'm becoming completely overwhelmed with the amount of effort it seems to take to get the simplest thing to work. I've been able to generate my public and private RSA keys.

Now.. I should be able to use those keys in a Cipher... but I can't get an RSA Cipher.
The 'signer' works fine (I took this from a tutorial on digital signatures) but the cipher throws Cannot find any provider supporting RSA

Apparently I need a differenet provider than the one that comes baked-in to JDK1.4 . I've been to, and then they start advising about security policies, and how to install the JCE provider. ARGH!

Does anyone know of a JDK1.4 built-in encryption algorithm that I can use to generate public/private keys, and the Cipher, and anything else I'd possibly need to encrypt/decrypt a simple String?

It doesn't have to be made of a titanium/steel alloy, it really just has to discourage the slightly bright, but essentially lazy.
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

I forgot to post, the RawRSAKey class above just reads in the file and returns the decoded chunks...
Lasse Koskela

Joined: Jan 23, 2002
Posts: 11962
Have you checked out the almanac?

Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Colin Fletcher
Ranch Hand

Joined: Sep 10, 2004
Posts: 200
Mike, Wouldn't it be easier and more secure to implement a central database/repository ?

So 'n' applications create a 'transaction' in the central database and retrieve an identifier. The Servlet's and JSP use the key in the form and post to the secure site.

SCJP 1.4 SCWCD 1.4
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

Lasse, Thanks! I had forgotten about the Almanac. Code there allowed me to figure out which Cipher algorithms were available.

Colin ... yes, it probably would be. I was hoping to avoid the use of a database though. I was going for 'small as possible' on the ecommerce app (which is currently two JSP pages and 5 classes).

The 'n' apps already have their own database. So to use a database as the "data rendezvous", I have two choices: Do 'n' apps connect to 2 databases each ? (their own, plus the e-commerce database?) or... Does the e-commerce connect to 'n' databases? I think I'd lean towards the last option.
Colin Fletcher
Ranch Hand

Joined: Sep 10, 2004
Posts: 200
I hear what you are saying. I would be more inclined to have an Web Service in front of the ecommerce payment component. The details of the transaction could be sent back via the service and stored, with cross reference information.

So a two stage payment process with web services...

life cycle:

application 'n' - use web service create transaction
web service returns transaction identifier
application 'n' calls common ecommerce application component to process with transaction identifier
ecommerce application returns pertinent details via the web service

The thought of having the amount to pay embedded in a page which the user has access to doesn't sit well with me... :-)
I agree. Here's the link:
subject: Crypto and hidden fields.
It's not a secret anymore!