Tim,
This is pretty much *THE* problem in application security, so this is
somewhat of an unsolved problem.
However, here's my advice: [it may be a bit scattered, this is a
braindump]
1. What's the potential loss ($) of someone tampering and sending false
data?
2. What's the chance of someone actually doing it?
3. Take #1 and #2, that's your probably loss by doing nothing. If that's
negligible, then you probably don't want to do anything. (Are the CEO or
high-level managers the only ones running this? Then they can probably
falsify the data anyway by some other means, so what are you
protecting?)
I'll assume that it's a real danger, big losses, by people you do NOT
trust already.
The real question boils down to: "How can you have A trust that B runs
program X to get output Y?"
I think .NET allows for code signing. That might be one approach.
Another would be to ActiveX it up and install an .exe on the client's
box. (Java apps are trivial to decompile).
Here's a more realistic one:
Use something like:
<applet src="whatever">
<param name="key" value="abc"/>
...
Have the applet read the data from the client's box and hash it with
"abc" as the salt. Make sure that "abc" is a random string that changes
each time the page is loaded. You can save the "abc" value on the server
(session variable).
Then, you return back to the server:
DATA (ip, hostname, whatever)
MD5(DATA + "abc")
And make sure you get a response within, say, 10 seconds.
You could do some fancy signing + timestamping on the client, but I
don't think that'll get you much.
You could dynamically rewrite the applet bytecode to include a "secret"
that the client would have to decompile to learn, and then re-encrypt.
You could then just set a timer (they won't likely be able to do that
very quickly).
Finally, you KNOW their (external) IP address. They can't fake that. Use
that as leverage. It's sometimes easier to audit after the fact.
Alright, sorry this was such a mess-- I'm sure I could come up with
something more legible if I had more time to go through it all. If
you're looking to *really* get into this, I'd suggest the Blackat
training course "Network Application Design & Secure Implementation"
(http://www.blackhat.com/html/bh-usa-04/train-bh-usa-04-dm.html) next
time it's given.
Hope that helps,
Mike
-----Original Message-----
From: Tim James [mailto:jimtames@yahoo.com]
Sent: Friday, October 29, 2004 6:18 AM
To: webappsec@securityfocus.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
