Re: Sensitive information in applet source code


"Thomas Hawtin" <usenet@xxxxxxxxxxxxxxxxx> wrote in message
news:431327a6$0$1282$ed2619ec@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Mogens Heller Jensen wrote:
>>
>> I have made an applet which works as a simple FTP client. Its purpose is
>> to upload files to a server (located at the applet's origin) when the
>> files are too large for HTTP upload.
>>
>> The applet is signed and everything, and it works perfectly.
>
> Is that necessary for an upload. IIRC, there will be a control connection
> plus a connection from client to server for data (although there are
> different modes).

?
Could any of these be used to transfer a file from the client to the server?
I do not see how this should be possible.

The reason FTP is used when a simple HTTP transfer could have been done is
that the file sizes range from 200 MB and up - and when IIS receives a file
via HTTP is stores the entire file in RAM until it is fully received. This
would be a disastrous situation if a couple of people did this
simultaneously.

>
>> However, one last problem remains to be solved: Where do I store the
>> login and password used to log in to the FTP server? Right now they are
>> hard-coded into the source file, but it is very easy to use a decompiler
>> on the .class file to see every string in the source.
>
> Or just: find . -name "*.class" -exec strings {} \; | more
>

Yes, we can agree that it is easy to learn what strings the .class-file
contains.

>> I have heard about bytecode obfuscators, but to my knowledge they only
>> make it harder to read the code, they do not actually add any security.
>
> Quite. Security by obscurity is no security. You don't even need to look
> at the code, just monitor the TCP packets. The login for the FTP server
> should be dealt with in the same way as if you were using HTTP.
>

Security by obscurity not secure, exactly my point.

Nice point though about the TCP packets not being encrypted in any way - you
could argue that securing (if it was possible) the login and password would
serve no purpose since a packet sniffer could be used to monitor the
unencrypted communication between the applet and the server.

I think the solution will be to obfuscate the code, since this will make it
a bit harder for script-kiddies to learn the login and password. If a real
cracker wanted to compromise the system he would know how to do it anyway.

Thanks for the input!

-Mogens


.

Relevant Pages

  • Re: File Upload - Security Issues
    ... You want to upload a file for what reason and ... these viruses have less chance of being able to execute (even if succeeded ... :> file and what pitfalls you see re: security might be helpful on this ... :>: files to an IIS server that doesn't have MS Office actually installed? ...
    (microsoft.public.scripting.vbscript)
  • Re: File Upload - Security Issues
    ... uploaded and the user could upload any or all of these in theory. ... There is no one product that can give you 100% security, ... > Code doesn't execute in local memory space unless remote user has rights ... > You don't have MS Office installed on the server. ...
    (microsoft.public.scripting.vbscript)
  • Re: File Upload - Security Issues
    ... You want to upload a file for what reason and you do ... file and what pitfalls you see re: security might be helpful on this end?! ... files to an IIS server that doesn't have MS Office actually installed? ... 2* Upon submit this is submitted to an ASP page that then (using the XML ...
    (microsoft.public.scripting.vbscript)
  • Re: Advice request: Backdoor hack on Windows Small Business Server
    ... Microsoft MVP (Windows Security) ... > traffic back and forth on the server stopped. ... >> probably still running hidden FTP software somewhere, ... >> notification of the file change, so checking the log for every day is ...
    (microsoft.public.windows.server.security)
  • Re: zfs: allocating allocated segment
    ... Two days ago i uploaded a file via ftp to the server and the server is crashing. ... Now i try to import the zfs-pool with a recent 8.0-current but with the same result. ... The original crash was beeing a ftp upload. ...
    (freebsd-current)