Hi Tim, everyone.
Interesting problem.
I suppose you could send a password with the encrypted data,
from your client to the server.
On receiving the data from the client, check the validity of
the password at the server end.
If the password check fails, then assume that the data may
have become corrupted as well.
Or you could also use various forms of 'proprietory dynamic
encryption', and send an 'encryption method key' with the
data, to tell the server which decryption method to use, on
receipt of the data. You are not actually sending the
encryption/decryption key itself, but a hint to the server
as to which methods (there could be several proprietory
methods) need to be used to decrypt the data).
An encryption key could be anything you want to use really.
For each field in the input data, a unique code number could
be used, stored on the server side, to identify the
decryption method required.
The Java applet could randomly choose from a pre-defined
list, which encryption method it uses for each field at the
client end, and build the appropriate 5-part encryption key
to send to the server.
Eg. if there are five input fields, then the encryption key
might be something like this:
De25hM:yTm90:A3GhpWm:Kx48qBz:Sn7U9vI
When the server receives the above key, it should be able to
parse the string into 5 seperate sub-keys, one for each
field, then apply the different server decryption methods
for each input field, and it's client-sided encrypted data.
HTH - Keith Roberts
Have you considered using VPN between the client and
server, if this is going via the internet?
http://www.karsites.net/
On Fri, 29 Oct 2004, Tim James wrote:
To: webappsec@securityfocus.com
From: Tim James <jimtames@yahoo.com>
Subject: advice needed - secure transfer of client details
Hi all,
This is a brain teaser. I have an application to
review which supplies details from the client's
workstation (derived from files on disk, hostname, IP
address). It currently implements a Java applet whose
job is to obtain these details and send them up to the
server in an ordinary HTTP POST.
This sends alarm bells ringing for me. I have
developed a simple attack whereby I can replace the
applet at will with my own code, which can send
different details for workstation ID, hostname, IP
address. This falsifies the audit trail from this
point on and the server is none the wiser.
So, the general problem is this :-
How can a client communicate details that are only
known to the client, up to a server, in a way that
cannot be tampered with ? Why should a server trust
the supplied values ? The data for the workstation
next to me is known by everyone - why can't I create
an applet to reproduce those details, and hence
impersonate that workstation ?
I have some ideas but none are totally satisfactory.
1) Encrypt the data
This shifts the problem to one of key management.
2) Checksum the applet
3) Keep the details on the server in the first place
and supply some token from the client which cannot be
impersonated
I would *really* appreciate a different perspective on
this problem because I'm kind of stalled.....
Thanks a lot
Tim
Send instant messages to your online friends http://uk.messenger.yahoo.com
