So a web app grabs data from a server with ajax. I'm interested to know whether there is some cryptography wizardy that would make sure the data came from that server. For example, someone can edit their hosts file and use a different server for the domain and pass different data to the web app without modifying it.

I'm thinking on something like this:

data_to_send // stringified json
integrity_code = getCode(data_to_send); //generates a code from the string.

The server outputs data_to_send and integrity_code

Then the client 
if (checkCode(data_to_send, integrity_code))
  //all fine

I'm a total newbie to cryptography, but the idea is to have some secret algorithm on the server which no one can see and public algorithm on the client that determines if data is integral. Can something like that be done?

  • 3
    SSL/TLS does just that. Feb 8 '17 at 23:44
  • if someone wants to interact with a different site, there's easier ways of doing that than manipulating your app's host usage, i don't understand the concern.
    – dandavis
    Feb 9 '17 at 20:10

The simplest solution is to implement TLS encryption and use it when querying the server. TLS traffic between the server and the other server hosting your webapp is going to be encrypted and the authority of the server properly validated. Having SSL/TLS installed however, does not automatically mean your app is using it, you still have to change the endpoint URLs from http:// to https:// in your ajax requests.

Edit: pragmatically I recommend letsencrpyt if using linux, it's no more than 5 minutes to be installed for apache or nginx.

  • I can second using the EFF's project, let's encrypt (letsencrypt.org). I used it on my server, which I host multiple sites on, and it was VERY easy to setup. My blog for validation DotNetRussell.com it's pretty good too. I got an A- on SSLLabs ssllabs.com/ssltest/analyze.html?d=dotnetrussell.com not bad for a raspberry pi lol Feb 9 '17 at 0:07
  • I'm already using Letsencrypt. But will SSL ensure the data comes from the server, even when user changed the domain in hosts file and serving the request from his own server, which also has SSL? Feb 9 '17 at 0:40
  • CA's prove the authority of the server reliably as they have no access to your local hosts files. Certs are issued for a specific domain which in public DNS points to your IP. Feb 9 '17 at 11:31

If the user of your system is motivated to subvert the client side of your system, then there's little you can do. Digital Rights Management (DRM) systems try to do something similar, with limited success.

If going down this path can be avoided, it should be.

  • This doesn't really have anything to do with DRM. A client can ensure it is communicating with the server it thinks it is through the use of TLS.
    – Luke Park
    Feb 8 '17 at 23:46
  • 2
    How come it isn't to do with DRM? The requester is explicitly saying that he wants to protect against situations where the end user could change /etc/hosts file and point to another server and his application should be protected against that. Feb 9 '17 at 1:03
  • You should probably read up on how TLS works. Even if the user changed their hosts file to a different server, that server wouldn't be able to act as the original because it doesn't have the private key of the original server.
    – Luke Park
    Feb 9 '17 at 1:06
  • Yes, this is exactly what I meant. To make it harder to reverse engineer it. Feb 9 '17 at 1:11
  • 1
    @LukePark you should realize that if the user changes /etc/hosts file, and trusts his/her own CA, you can easily impersonate any website. Done all the time. Feb 9 '17 at 1:18

As mentioned in another answer, TLS (HTTPS) includes authentication, which is intended to provide the sort of guarantee you're looking for. There are also a variety of other cryptographic tools for the more general problem; GPG is a common signing tool for email, for example.

However, while your gut instinct to not trust that the server you're querying is the right one is correct, you haven't taken it far enough. You should generally assume that any code that runs on the client can be subverted entirely - so if an attacker wants to, they can just change the code so it doesn't make any requests at all, and just uses some hard-coded values that they want.

In client-server models like web apps and online games, the way to prevent this is to always verify actions on the server. You can still do calculations on the client, but never consider them to be trusted; everything has to be verified by the server before it's considered truth. I don't know what your app is doing specifically, but to provide an example from ecommerce, you can't just trust the client to tell you that they've paid for something; the server needs to do the payment processing (or send it off to an external trusted service to do that), and only then do you proceed with shipping them their item.

  • Yes I'm aware of it. But now I thought, this is not the solution to what I want. Chrome extensions can have permissions to read and change data on websites I guess it also includes encrypted websites. Someone could make an extension that would change the ajax data. But if I encrypted the message on the server and decrypted on the client, it would be much harder to do and would require modification of source code, am I right? I just want to prevent scenarios where the response could be tampered without even touching the source code. Feb 9 '17 at 1:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.