[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44.0611241714010.15226-100000@ns2261.ovh.net>
Date: Fri, 24 Nov 2006 17:24:38 +0100 (CET)
From: John GALLET <john.gallet@...adoo.fr>
To: bugtraq@...urityfocus.com
Subject: Re: Cracking String Encryption in Java Obfuscated Bytecode
Hi,
>1) If you are deploying Java on the server you are protected by so many
>layers, code obfuscation is not critical
If you want to distribute your app without people getting access to the
code itself, being on client or server is not relevant. Whatever the
reason for wanting to do so.
> 2) If you are deploying Java Applets for enterprise applications, you
> are nuts. They are inherently insecure and Java applets have a long
> history of critical problems.
So have cookies and javascript based web applications. Yet cookies are
used everywhere for anything/everything and "ajax" is the new big boy in
town. It is not because something is insecure that people don't use it in
the real world, not the perfect secure one.
You would be amazed of how many times I heard "it's useless to check again
the data on the [php|java|asp|perl] side, we already did it in JS" or "why
add a java middle-tier server side, we can obfuscate the jar file and have
the client PC talk directly to the database" (yeah sure, I'll make a
public, unencrypted, access for you guys).
>From a security *threat* point of view, I agree that we could/should more
of these issues.
> > With the continuous move towards bytecode type of languages (with java
> > and .NET being the prime examples)
Same goes with PHP BTW.
JG
Powered by blists - more mailing lists