-----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-----
