How do I know that malware on the client computer does not modify data transmitted to my webapp?

Question

I am working on a web application and have had an idea of a new feature I would like to add. The feature includes getting data from the user on their open system and receiving it on my server. For the sake of concept I am assuming my server is 100% secure and is guarded by a million level 80 warlocks and my dachshund dog Kevin. So our side cannot be compromised and is totally secure for this question.

The user goes to say a library and uses the computer there. From that computer they request a a webpage from our server. Then in this webpage they enter some data. This data then gets sent to my server and processed. My concern is how can I verify what the user typed in from the keyboard using their fingers is what really was sent to my server.

Lets say I user HTTPS to serve my content, so theoretically this data cannot be read/modified while in transit. But what if on that public library machine the previous day fricken Todd compromised the computer by putting some malicious code inside of the web browser which secretly and discretely changes the data sent to the server. So our user types in the word 'PNEUMONOULTRAMICROSCOPICSILICOVOLCANOCONIOSIS' and sees this being typed in on the screen. He then presses send, but when he does this the malicious code in the browser modifies the data to change the data to be 'ToddIsAwesome' and shows the user their message has been sent with the data he thinks was sent, but actually the data has been modified and the server gets data from the user, but it is not the data the user wanted to send. Is there techniques to verify this sort of thing? The user does not have to send the data from a website, it can also be installed software on a computer. My main concern is to get the data the user intended to send and to detect if modification has occurred from the moment the user types something in to the moment the server receives the request.

Answer 1

Short answer is: You can't.

All your server see is what the computer at the library sends. What programs or processes on that computer that generated the data is impossible for you to know. From the servers perspective, it might as well have been a pidgeon with a telegraph as your legitimate user.

The fact that the user entered a password does not mitigate this. Two factor autenthication with a cellphone does not mitigate this. Malware on the computer could hook into the browser and modify the HTTP requests after the password(s) has been entered.

There is one small thing you can do, though. Have the user digitally sign part of the message on another computer than the library computer, and then enter that digital signature into the webapp on the library computer. This could be his cellphone or a product such as a digipass. Since that computer is out of reach from any malware on the library computer, it is safe. The backside is that the user will have to enter the message he is signing on that device - not very practical for long messages. I have seen banks use this for signing the amount in a transfer, but not the account it is transfered to because that would be to user unfriendly.

That is only a partial solution that is only worth the effort for really high value targets such as bank. The easier solution is just to teach your users to not to do sensitive transactions from a public computer.

Answer 2

There really is no way to be validate the input if the user's computer is compromised. There are just too many variables.

When your browser submits a form it looks something like this before it's encrypted and sent to the server:

POST /login.php HTTP/1.1
Host: www.example.com
User-Agent: mycoolbrowser
Content-Length: 34
Content-Type: application/x-www-form-urlencoded

username=Bob&password=bobspassword

Nothing complicated. There is nothing here that the browser can't fabricate. And if Todd has compromised the computer, he can do what he wants. He can even replace the browser with a look-alike that does what he wants. For example, if I use Google Chrome, he could replace it with Chromium, add his malicious code (relatively easy since it's open source) and change the icon.

Now, if Todd forgets to change the User-Agent string and the user claims to be using Google Chrome you might detect the disparity. Or if the form only allows numeric input and the browser sends words you might detect the disparity. Or if the form input box has been validated client side to contain 45 characters, and the browser sends 13 characters you might detect disparity.

Come to think of it, Todd doesn't even have to compromise the browser directly; he could simply activate a browser plugin that reads the html, detects form input and changes it.

There are really just too many variables. You may be able to detect something in very specific scenarios, but there is really nothing you can do in the general case. There is no such thing as client side security.