4

I'm being forced to send data via GET (query string) to another server.

For example: http://myserver.com/blah?data=%7B%22date%22%3A%222011-03-01T23%3A46%3A43.707Z%22%2C%22str%22%3A%22test%20string%22%2C%22arr%22%3A%5B%22a%22%2C%22b%22%2C%22c%22%5D%7D 

It's a JSON encoded string. However, anyone with half a brain can see that and decode it to get the underlying data.

  1. I understand that the query string is limited in length
  2. I don't have a choice about using GET vs PUT/POST

Is there a way for me to encode a lot of data in a much shorter string that can be decrypted from the server? (using javascript)

I suppose HTTPS doesn't actually resolve this since the data is in the uri?

john
  • 33,520
  • 12
  • 45
  • 62
  • 1
    I'm not sure I understand the requirements, but: PUT/POST don't make any difference in terms of security: it just means somebody would look in a different place to see it. And HTTPS encrypts the connection, not just the response. – Ken Mar 02 '11 at 00:00
  • I cannot send a PUT/POST request due to same-domain policy on ajax requests. I'm limited to using a GET request to send data to my server encoded in the query string. – john Mar 02 '11 at 02:32

3 Answers3

3

HTTPS resolves it -- even the data in the HTTP header (including the URI) is protected, since the whole connection happens over an SSL channel.

There is one exception: the host name will be exposed if the client uses a proxy, since it is transmitted in the clear in the CONNECT request.

jsalvata
  • 2,155
  • 15
  • 32
  • +1, with caveats. Supporting info: http://stackoverflow.com/questions/323200/is-a-https-query-string-secure | http://stackoverflow.com/questions/190771/how-secure-is-sending-sensitive-data-over-https The info is safe in one sense, and not in a couple of others. – T.J. Crowder Mar 02 '11 at 00:06
2

Given your constraints, the only option I see is to use a public key / private key pair, like PGP does, where the public key is used to encrypt data (which you'd then send via GET), and the private key is used to decrypt it. At that point you'd probably have left JSON behind (although you could certainly set up the data as JSON, then encrypt it, and send the result as a Base64-encoded string or something). Note that this doesn't protect you from false messages (as the public key is, well, public), but it does mean that people couldn't read the data in transit without the private key.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
0
Community
  • 1
  • 1
codecraft
  • 1,163
  • 9
  • 11