Is there a way to verify that the client code used is the one specified by the server?

Question

In the previous question, I asked about the weaknesses in my concept of security level ... It relies on JavaScript cryptography functions, and thanks to the answers it is now strikingly clear that everything that is done in Javascript can be manipulated and cannot be trusted ...

Now the problem is that I still have to use them, even if I rely on SSL for the transfer ...

So, I want to ask - is there a way that the server can verify that the site is using the "correct" javascript from the server?

Everything that comes to my mind (for example, hashing, etc.) can be clearly faked ... and the server does not seem to be able to find out what is happening on the client side after it sent some data to it, expept over HTTP headers (-> cookie exchange and more)

Answer 1

The server cannot verify this.

All interactions between Javascript and the server come directly from Javascript.
This way, malicious Javascript can do everything your benign Javascript can do.

Using SSL, you can make it difficult or impossible for malicious Javascript to enter your page in the first place (as long as you trust the browser and its add-ons), but as soon as it fixes on your page, re hosed.

Basically, if an attacker has physical (or scripted) access to the browser, you can no longer trust anything.

Answer 2

This issue has nothing to do with javascript. It is simply not possible for any server application (network or otherwise) to ensure that processing on the client machine is performed by known / trusted code. Using javascript in web applications makes the wrong intervention, but you will have the same problem if you distribute the compiled code.

All that the server receives from the client is data, and there is no way to guarantee that it is your expected client code that sends this data. Any piece of data that you could use to identify your expected customer can be created just as easily with the replacement customer.

If you are concerned about replacing client code with a man-in-the-middle attack, downloading javascript via https is your best bet. However, there is nothing to protect you from directly substituting client code on the client machine itself.

Answer 3

Never assume that customers are using client software that you have written. This is an impossible problem, and any solutions you develop will only slow down and not prevent attacks.

You may be able to authenticate users, but you can never authenticate reliably what software they use. The consequence of this is to never trust the data that customers provide. Some attacks, such as Cross-Site Request Forgery (CSRF), require us not to trust that an authenticated user is even designed to provide data.