Is it worth to obfuscate java web application? and why?
+7
A:
No. The code is stored on the server where external users (hopefully) don't have access to it. You may want to obfuscate the JavaScript if you feel it's worth the (minimal) IP protection.
The best thing is so make sure your server security is up to scratch and you don't have open access to your application directories (which shouldn't happen anyway).
Luke Schafer
2009-09-14 02:45:58
Glad external users are the only ones we have to worry about. *eye roll*
Chris Lively
2010-06-21 16:21:58
Poor choice of words, maybe :)
Luke Schafer
2010-06-21 21:44:45
+2
A:
I would add that you should have a good justification, because obfuscation will make debugging harder.
daveb
2009-09-14 02:48:24
+2
A:
The only scenario where you would obfuscate a java web application is if you gave the code to your customers to run on their servers. Otherwise, it is just a waste of time and an extra complexity.
Obfuscation is for the purpose of making it harder for someone to decompile your byte code and get useful code out of it. To do this, they have to have access to your class files, something that only exists when you deliver them to your customers, not when they access it remotely.
Yishai
2009-09-14 02:49:21
+2
A:
IMO, no.
There are two main use-cases for obfuscation:
- to protect access control "secrets" (e.g. passwords) embedded in the code, and
- to protect against someone stealing your "intellectual property".
The problem is that obfuscation only foils half-hearted attempts at reverse engineering. A serious attempt will always succeed. It is really not that hard to decompile an obfuscated JAR file, and there are lots of tools around for doing it.
For the use-cases above, better alternatives to obfuscation are:
- just don't embed secrets in the code, and
- one or both of the following:
- secure your webservers so that hackers cannot get at the code, and
- don't ship the code that you consider to be valuable IP, or if you do, then only ship code to people who have signed a legally binding contract / license agreement that guards your IP rights.
Stephen C
2009-09-14 03:25:31
sure. You can decompile a obfuscated JAR. In fact it's the same thing as a "normal" jar. But it's barrely readable...
Antoine Claval
2009-09-14 09:26:07
It is sufficiently readable for a determined hacker with a modicum of skill to be able to figure out exactly what it does, and how it does it.
Stephen C
2009-09-14 09:53:52
#include<stdio.h> #define __(a) goto a; #define ___(a) putchar(a); #define _(a,b) ___(a) __(b); main() { _:__(t)a:_('r',g)b:_('$',p) c:_('l',f)d:_(' ',s)e:_('a',s) f:_('o',q)g:_('l',h)h:_('d',n) i:_('e',w)j:_('e',x)k:_('\n',z) l:_('H',l)m:_('X',i)n:_('!',k) o:_('z',q)p:_('q',b)q:_(',',d) r:_('i',l)s:_('w',v)t:_('H',j) u:_('a',a)v:_('o',a)w:_(')',k) x:_('l',c)y:_('\t',g)z:___(0x0)}
Antoine Claval
2009-09-14 15:15:50
@Antoine: that's not Java. A Java decompiler won't gratuitously add a layer of bizarre C preprocessor crap to its output.
Stephen C
2009-09-14 22:32:27
@Antoine Claval: Really? That was the easiest thing I've ever seen in my life (except for JVM bytecode) http://pastebin.com/LNP22xT2
Longpoke
2010-06-21 19:26:23
+2
A:
You might find the answers to http://stackoverflow.com/questions/12088/do-you-obfuscate-your-commercial-java-code relevant.
Thorbjørn Ravn Andersen
2009-09-14 05:20:46
+1
A:
Is it worth to obfuscate java web application?
It depends
and why?
If you're licensing your web-app to be installed on your customer's site and you don't want your customer to reuse your code by decompiling it*, then it is.
If you're serving your web-app and the installation is available only from you, I would say it is not worth it. Better would be to increase your net security.
* see Stephen C comment
OscarRyz
2009-11-06 21:29:51
Obfuscation won't prevent a customer from decompiling your code. Even if they are not entirely successful in decompiling to useable Java source code, they can probably figure out any secret that you are trying to hide in the code.
Stephen C
2010-06-21 07:14:56
A:
we are deploying our software at customer site and we dont want to give chance to the customer to check our code. so i want to know how to obfuscate the web application.
vijaya
2009-11-19 11:06:00
You don't seem to be very proud of your code >:) BTW, how does this answer the question?
Pascal Thivent
2009-11-19 11:17:10
A:
Has anyone implemented to use-case related to client side code? can you tell me the process for doing it or any tool for it. I tried the usecase with proguard for a spring webapp which proved to be of very less use.
kmkswamy
2010-06-21 06:56:21
A:
Is it a good idea to obfuscate your server side code? I'd give an unqualified YES.
The reality is that the end user is only one group which might have nefarious plans. All too often internal employees, whether they are business users, support staff, etc, might also have their own plans.. or made unwitting accomplices.
If you deal with ANY information which requires a password to access, then you have a duty to leverage every tool at your disposal in order to safeguard that information.
This includes protecting it against both external and internal people. Companies lose both data and intellectual property all of the time due to internal people with too much access. Whether those people purposely stole the information or simply lost control of their computers due to hacker attacks is immaterial.
So, again, yes one step is to obfuscate in the hopes of whoever acquires the binaries has a harder time in figuring out how your application works. Of course, you should go a lot further by securing the servers it lives on; and not just production, but all the way back to source control.
Chris Lively
2010-06-21 16:06:37
You're criminalizing people before they actually do any crimes. While it's true that a lot of intrusion attempts comes from internal source, obfuscating code is the wrong solution to giving employees too much access. The obfuscation is more likely to annoy legitimate administration and will *not* prevent malicious internals from causing havocs. If you don't want anyone to read your files, use the OS's filesystem access control and allow people to execute but not read the executable.
Lie Ryan
2010-06-21 16:22:32
@Lie Ryan: Obfuscation is only one tool in the belt. ACL's are also critical, but the fact is that a non-dev is going to be able to get to the code; obfuscation will provide at least some defense. As far as criminalizing them before they do a crime.. I'd rather remove any temptation and/or ability PRIOR to finding out that a "trusted" person has planted code, copied code and/or data, etc. But, hey, if you want to believe that corporate espionage doesn't exist then more power to you. Heck, a couple weeks ago I met with a guy who had a copy of his competitors source code. Wonder how he got it.
Chris Lively
2010-06-21 17:19:20
@Chris, most likely from the source control repository or a developer's laptop. I highly doubt they decompiled the byte-code gleaned from a production web-app. At least, it seems like an unlikely vector for an attack.
Yishai
2010-06-21 19:07:26
@Yishai: Try this. Go to a company, find out who their network admin is. Offer him $5k US for a copy of their local website, tell him you don't even need the data. Within a couple days you will almost certainly have it, zipped up, ready to go.
Chris Lively
2010-06-21 20:29:43
Of course, the least likely to get you jailed version is: Wait for a job to be posted by the company in question, apply for it, get the job. Copy the stuff yourself. Quit.
Chris Lively
2010-06-21 20:31:35
Here's an interesting read: http://www.infoworld.com/d/security-central/how-spot-and-stop-corporate-spy-393
Chris Lively
2010-06-21 20:35:17
@ChrisLively: If you're so worried about the security of your compiled file, in Linux/Unix security scheme (octal bit), it is possible/trivial to allow a user to "execute" a program without allowing him/her to actually "read" the program? If your non-devs accounts have no capability to "read" your program you don't need to make life difficult for the devteam due to the obfuscation. I'm sure this was possible in ACL as well. All they will see is a file, and they can execute it, but they can't open it in a text/hex editor or copy it.
Lie Ryan
2010-06-21 21:18:27
@ChrisLively: as has been pointed out, the one you should better be aware of is the developer team, who has full access to the code in source form in the repository. Unlike day-to-day administrators who doesn't need to mess with the source and whose read privilege you can revoke without reducing their effectiveness, you can't really revoke a devteam's privilege to read the repository (since otherwise the devs won't be able to work).
Lie Ryan
2010-06-21 21:23:13
@Lie Ryan how does obfuscation of a compiled binary make life difficult for developers? They're the only ones that should be looking at code, anyway, and they've got the source. The only people that will be inconvenienced by an obfuscated binary are those that don't have access to the source.
David Lively
2010-06-21 21:36:40
@David Lively, obfuscated java is much harder to debug when an issue happens in production, since the stack trace is not mappable to the actual source code. There are some ways around that, but it makes life difficult.
Yishai
2010-06-22 00:43:38
@Chris Lively, the alternative outcome of that experiment involves arrest, jail time and some issues with future work prospects. But my overall point is if you can pay a sys-admin to send over the byte-code you can pay someone with access to the source repository for the code. Obfuscation hasn't necessarily bought you anything.
Yishai
2010-06-22 00:50:16
@Yishai: Yes, you can get it from a dev as well; but by obfuscating, you've just limited the pool of people with access. And there are other ways to monitor dev stations.
Chris Lively
2010-06-22 02:51:45
@Chris: The problem is an internal employee having too much access; the solution is to limit their access. Obfuscation is a shot in the wrong direction.
Lie Ryan
2010-06-22 12:19:12
@Lie Ryan: There are Internal and External threats. This helps with one aspect -> that of too much access has been acquired. Also, flipping that security bit does nothing to protect the files from people whose responsibility it is to control that very bit.
Chris Lively
2010-06-22 14:33:36
@Chris: and why is that situation any worst than people whose job is to run the obfuscator on the program? why would you give an untrusted person the privilege to set the "read" bits? likewise, why would you let an untrusted person to obfuscate the program?
Lie Ryan
2010-06-22 15:36:03
A:
Absolutely yes.
If your development process is correct, only binaries and some support files (markup and stylesheets, for instance) need to be on the server. There's no good reason to not obfuscate binaries in any production environment.
Others here have said that doing so creates problems for staff. The only people that should be aware of or concerned about the contents of your binaries are developers - and they have the source, so they shouldn't be concerned about poking around compiled objects.
The only reason I can see that anyone that doesn't have access to the source would be interested in the contents of binary would be reverse engineering - and no one on your staff should have any interest in reverse engineering your own product, unless they don't have access to the source. That means they either aren't cleared for that code, or you've lost it, which means your source control system either sucks or is missing entirely. That is a completely different conversation.
I've yet to hear any practical examples of server-side obfuscation causing development or administrative difficulties.
David Lively
2010-06-21 21:42:39