views:

160

answers:

4

Hi,

I need to send an ajax POST request to my server.

I'll need to make sure that the request originated from the script itself, and not from a user writing the request him/her self. Is there any secure way to do this? Can the script sign or encode the POST request, later to be decrypted by the server's private key? and can I somehow prevent the user from encrypting using my public key?

I'm not doing this just for filtering purposes - so plain old server-side validation just won't do.

A: 

You can't use public key cryptography in pure JS, because the private key (used for signing data) will be exposed. Generally speaking, what you're trying to do is impossible.

Matthew Flaschen
That's totally wrong. Assuming you did implement AES or something in javascript, then it would be entirely possible to encrypt data to send back to the server: you use the public key to crypt it, and then only the server can decrypt it, using the private key.Of course, it would be a useless exercise. It wouldn't protect against user forgeries, and it would be far simpler to use HTTPS to protect the data in transit anyways.
Marc B
@Marc B. First of all, AES is a symmetric key cipher, not a asymmetric one (you can use a symmetric key cipher as /part/ of a public key cryptosystem, but you still need a asymmetric cipher like RSA). Second, the OP asked, "Can the script sign or encode the POST request", and elaborated "i need to know that im sending the request". Despite the mistaken reference to "the server's private key", he is clearly asking how to let the client /sign/ data, not how to /encrypt/ it.
Matthew Flaschen
Yes, but he also says "decrypted by the server's private key". Signing or encrypting, either way, it IS possible from javascript, but again, trivial to bypass and forge.
Marc B
+5  A: 

Anything you do in Javascript can be seen and analyzed, as it's happening on the client side. So encrypting information securely client side is pretty much impossible. That leaves the server as the only point where you can and need to do validation.

Also, why would you care if an input comes from your script or is hand-crafted by a user? If the input is valid and allowed as defined by your rules, it shouldn't make any difference.


For this kind of situation, when in doubt, you need to see the importance of client/server separation. Your server is your app, it's the one and only critical component that you need to take care of. Every input is generally untrusted, every output must be exactly what you intend to disclose.

The HTML/JS interface you're handing to the user is just a help for the human to communicate with your server, but that doesn't mean it's trustworthy or securable once it has left your server.

deceze
+2  A: 

I'll need to make sure that the request originated from the script itself, and not from a user writing the request him/her self.

From the point of view of your server 'the script' and 'a user' are indistinguishable. What you are asking for is fundamentally impossible.

Andrew Strong
+1 Very nicely put.
deceze
+2  A: 

The other answers are correct: this is fundamentally impossible. Probably the best you can do from a pragmatic point of view is to look into really nasty ways to obfuscate your JavaScript to discourage people who might try to look at it, but you can be assured that someone motivated can work around this without too much effort. http://en.wikipedia.org/wiki/Obfuscated_code

Scott Wolchok