WebApp Sec mailing list archives
Re: advice needed - secure transfer of client details
From: Peter Conrad <conrad () tivano de>
Date: Mon, 1 Nov 2004 16:30:22 +0100
Hi, Am Freitag, 29. Oktober 2004 12:18 schrieb Tim James:
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?
Use encryption. However, I don't think the above is the question you want to have answered. From what you said before, I suppose the real question is How can I authenticate the client properly? Which is much more difficult to answer.
Why should a server trust the supplied values?
It shouldn't, of course.
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 ?
Assuming that, as you say, all data for the workstation next to you is known by everyone, you're lost. In other words, if you know all the required bits, you can *always* create an applet to impersonate the workstation next to you.
I have some ideas but none are totally satisfactory. 1) Encrypt the data This shifts the problem to one of key management.
Encryption is only useful for protecting the communication between client and server. It does not prevent modification or sniffing of data before it is encrypted.
2) Checksum the applet
Doesn't work because if you can subvert the applet's code you can also subvert the integrity protecting code.
3) Keep the details on the server in the first place and supply some token from the client which cannot be impersonated
As I said above, as long as all data from the workstation next to you is publicly known, anyone can impersonate it. So in order to find a solution to the problem, you must introduce some kind of secret. Since you're speaking of "applets" and "HTTP" I suppose your users can access the machine using a web browser. Which means you cannot store the secret anywhere on the machine, because any location that can be accessed by an applet can also be accessed by the browser directly. Maybe a better option would be to authenticate the people using the application instead of the workstations used by the people. People can keep secrets in their heads (as long as they're not unneccessarily complicated, like more than four digits or so... ;-). Bye, Peter -- Peter Conrad Tel: +49 6102 / 80 99 072 [ t]ivano Software GmbH Fax: +49 6102 / 80 99 071 Bahnhofstr. 18 http://www.tivano.de/ 63263 Neu-Isenburg Germany
Current thread:
- advice needed - secure transfer of client details Tim James (Oct 29)
- New Whitepaper - "Second-order Code Injection Attacks" WebAppSecurity [Technicalinfo.net] (Nov 01)
- Re: advice needed - secure transfer of client details Peter Conrad (Nov 01)
- Re: advice needed - secure transfer of client details Ido Rosen (Nov 01)
- Re: advice needed - secure transfer of client details focus (Nov 01)
- Re: advice needed - secure transfer of client details GuidoZ (Nov 01)
- Re: advice needed - secure transfer of client details Alex Russell (Nov 01)
- Re: advice needed - secure transfer of client details Richard Moore (Nov 05)
- <Possible follow-ups>
- RE: advice needed - secure transfer of client details Michael Silk (Nov 01)
- RE: advice needed - secure transfer of client details Scovetta, Michael V (Nov 01)
- RE: advice needed - secure transfer of client details Glenn_Everhart (Nov 05)
- re: advice needed - secure transfer of client details Tim James (Nov 05)