0

I am posting client side data to server in the following format.

$.ajax({
    type: 'post',
    url: 'rest/server',
    data: JSON.stringify(frmData),
    contentType: "application/json; charset=utf-8",
    success: function (data) {
        ...
    }
});

How and what are the best options to either encrypt/decrypt or generate key value pair when send to server(java) in order to avoid posting data which is not supposed to be sent? E.g. if form element contains values pertains to user, that user could send other values to server to post.

HTTPS/SSL is not an option for me for the time being.

Artjom B.
  • 61,146
  • 24
  • 125
  • 222
Jacob
  • 14,463
  • 65
  • 207
  • 320

3 Answers3

1

Herr K collects some JavaScript encryption methods here. There is no best, you would need to select one based on interoperability with Java, but forge probably provides a matching functionality to Java using RSA with an appropriate padding scheme. As I see it this would only protect against a passive "attacker" who cannot manipulate requests.

So you generate a public/private key pair with the method of your choice and embed the public key in your client code. Then you would encrypt using the public key on the client and decrypt with the private key on the server.

You will need to set the contentType to text/plain.

To receive an encrypted response from the server this should be extended a little bit. Since an asymmetric cipher like RSA is needed, the client only has a public key and the server a private key, the server can only sign a message with RSA, but not encrypt it. So the client will need to generate an AES key and send it to the server and the server will use this key to respond securely. By securely, I mean that the message will be confidential, but maybe not authentic. So some type of MAC should be added.

To extend it further, on the first message the client generates the AES key and encrypts the actual message with this key and additionally encrypts the AES key with RSA (this is called hybrid encryption). The server responds with a message encrypted using AES. For the rest of the session only AES is used. RSA is only used at the beginning of the session to establish the session key. This is handmade SSL without using the SSL capabilities of the browser.

Community
  • 1
  • 1
Artjom B.
  • 61,146
  • 24
  • 125
  • 222
  • So I cannot use `application/json` or `text/plain` is the only option? – Jacob Nov 26 '14 at 16:29
  • Since you're sending encrypted data, it doesn't make sense to declare it as json. You can of course send "{data: encrypt(mydata)}" which makes it a json string again. – Artjom B. Nov 26 '14 at 16:32
  • I have another question, are there any sample available for this? I mean encrypt from client and decrypt in server(Java). – Jacob Nov 26 '14 at 16:33
  • 1
    I suggest you try to find a tutorial with RSA for Java (use one that uses padding) and try to recreate it. When you're confident that encryption and decryption works, do the same thing in JavaScript for the same scheme (and padding) and then knock your head at the encodings. – Artjom B. Nov 26 '14 at 16:41
  • Thanks. To understand your point further, the following steps would be fine? Encrypt in Java and send to client and Decrypt and display in JSON format and reverse for post when submit to server, correct? – Jacob Nov 26 '14 at 16:48
  • No. As I understand your question, you want to post data from the client to the server. So you need to encrypt on the client in JavaScript and decrypt on the server in Java. The other way around would only be possible if you would first establish a symmetric session key. – Artjom B. Nov 26 '14 at 16:50
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/65706/discussion-between-polppan-and-artjom-b). – Jacob Nov 26 '14 at 16:52
1

I wonder if you are talking about trying to prevent people manipulating locked or hidden form fields before they press the submit button?

It is very easy to change hidden input values such as ids using tools like firebug, plus people can see your API from your javascript code. Even with obfuscation, there is no 100% way to prevent against this type of manipulation. Data encryption/decryption implemented at the communications level will not stop manipulation of things at browser/client level (like hidden fields).

The key point is, if you dont want the data to be modified, you shouldn't be sending it to the client in the first place. You cannot rely on hidden input values to stay the same when you receive them back again. It is sometimes more convenient to use hidden input fields to keep track of state, but when security is more important, you should use server side sessions.

If you want to detect that some value was purposely altered, you could use a hashing signature.

It is hard to say what is best for you without a more detailed example of what data you are talking about and the context.

Phil
  • 1,996
  • 1
  • 19
  • 26
1

Some points of interest:

  1. when you send data over http protocol it might be tracked down by third-party users
  2. sending a signed / hashed / encrypted data over the network is the preffered way to secure your data against potential sniffers
  3. javascript runs on your client's browser and therefor exposed to the user
  4. when encrypting data in javascript, any user with good understaing in javascript can read your code and build some other function to decrypt back your data
  5. when using a random key to sign the data, the key itself should be post to the server.. it can be tracked down
  6. when the key is generated by the server it should be send to the user.. it can be track down in that scenario either
  7. any key that you store on the clien side (cookies, local storage etc) can be hacked
  8. every hacker which dealing with brute-force operations can hack short passwords (event 'stong ones') in a matter of minutes

don't want to use RSA? a potential solution:

send a secret key to your user by an e-mail and make the user insert that key inside an input field (masked as a password).. don't save that key anywhere inside your code - just sign the data and post it to your server.. it is REALLY NOT RECOMMENDED but it is the only reasonable solution i found for that kind of a question

ymz
  • 6,602
  • 1
  • 20
  • 39
  • Why would the user deliberately disclose the information that is sent by manipulating the encryption code? I'm not sure you've got the attack scenario right. – Artjom B. Nov 27 '14 at 00:19
  • a user = **hacker**. can read the code, build a reversed method, sniff other users http requests and decrypt them – ymz Nov 27 '14 at 00:24
  • Sniffing alone doesn't get you anywhere as a hacker. Malicious code has to be injected into the website when other users request it. – Artjom B. Nov 27 '14 at 00:26