Re: advice needed - secure transfer of client details

[Alex Russell <alex () dojotoolkit org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 29 October 2004 3:18 am, Tim James wrote:
> 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 ?

So long as the code in question is running in a memory space which you 
do not control (e.g., the client browser), you're hosed. You cannot 
trust ANYTHING coming from the client unless YOU both generated and 
can independently confirm it.

> I have some ideas but none are totally satisfactory.

I doubt you will come up with anything that is fully satisfactory. But 
coming back to the app in question, what's the point of gathering all 
this information? What is the security target and how does gaterhing 
this information assist in reaching that target? A better question to 
solve from your side might be to come up with a different mechanism 
that reaches the same security target though a more trustable 
mechanism.

> 1) Encrypt the data
> This shifts the problem to one of key management.

Again, not sure this helps you keep the client from "lying" about the 
data it's sending. Over-the-wire crypto only buys you the assurance 
that what you sent is indeed the same thing that left the client, not 
that what the client sent is in actuality correct.

> 2) Checksum the applet

Not sure this helps you. The client can just as easily download the 
"right" one and then reply with the correct checksum, regardless of 
what code is actually running on the client.

> 3) Keep the details on the server in the first place
> and supply some token from the client which cannot be
> impersonated

This is more promising, but where are you getting the data from in the 
first place and what's its role in all of this? Again, what's your 
security target and how does this interaction help you get there?

I.e.: what does it buy you?

Ask that at every step and you'll be well down the road to a design 
that maximizes your security bang for your buck.

Regards

- -- 
Alex Russell
alex () dojotoolkit org
alex () netWindows org F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBhoUqoV0dQ6uSmkYRAvjuAJ9uFSGI1zVQTK0PCnAm4gC+pdYr2gCgrvyC
N2Gn5ceB9BTdBWtTCtWNSOA=
=bi2u
-----END PGP SIGNATURE-----