Java Web应用程序是否值得混淆？

Question

在Java Web应用程序中混淆代码是否值得？为什么？

- janetsmith

---

也许我们需要混淆来保护我们的代码，以免被网络主机窃取，不是吗？ - Rajat Gupta

Answer 1

不会。代码存储在服务器上，外部用户（希望如此）无法访问。如果您认为值得保护（最小的）知识产权，可以模糊JavaScript。

最好的方法是确保您的服务器安全性达到标准，并且您没有开放对应用程序目录的访问权限（无论如何都不应该发生这种情况）。

- Luke Schafer

---

很高兴我们只需要担心外部用户。翻白眼 - NotMe

词语选择不太恰当，也许 :) - Luke Schafer

Answer 2

我认为不需要。

混淆有两个主要用途：

1. 保护嵌入在代码中的访问控制“秘密”（例如密码）；
2. 防止他人窃取您的“知识产权”。

问题在于，混淆只能挫败半心半意的反向工程尝试。严肃的尝试总是会成功。反混淆一个混淆后的JAR文件并不难，而且有很多工具可以做到这一点。

对于上述用例，比混淆更好的选择是：

1. 不要在代码中嵌入秘密；
2. 以下二者之一或两者兼而有之：
   • 保护您的Web服务器，使黑客无法接触代码；
   • 不要发布您认为有价值的IP代码，或者如果您这样做，请仅将代码发送给已签署法律约束力的合同/许可协议的人，以保护您的IP权利。

- Stephen C

---

你可以反编译混淆过的JAR文件。实际上，它与“普通”的JAR文件是一样的。但是它几乎无法阅读... - Antoine Claval

它足够易读，对于一个有一定技能的决心坚定的黑客来说，他可以准确地弄清楚它的功能和实现方式。 - Stephen C

#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

@Antoine：那不是Java。 Java反编译器不会在输出中随意添加一层奇怪的C预处理器的垃圾代码。 - Stephen C

@Antoine Claval：真的吗？这是我生命中见过的最简单的事情（除了JVM字节码）http://pastebin.com/LNP22xT2 - L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳

也许我们需要混淆来保护我们的代码，以免被网络主机窃取，不是吗？ - Rajat Gupta

Answer 3

唯一需要混淆Java Web应用程序的情况是将代码提供给客户在其服务器上运行。否则，这只是浪费时间和增加复杂性。

混淆的目的是使得别人更难反编译您的字节码并从中获取有用的代码。要做到这一点，他们必须能够访问您的类文件，这仅在您将它们交付给客户时才存在，而不是在远程访问时存在。

- Yishai

---

也许我们需要混淆来保护我们的代码，以免被网络主机窃取，不是吗？ - Rajat Gupta

@user01，要保护托管代码，有更好、更重要的安全措施需要采取。如果你对第三方托管服务商担心到这个程度，老实说，你应该自己进行主机托管。 - Yishai

谢谢。所以你的意思是我不应该对此持怀疑态度，这是一个信任的问题，对吗？另外，你能否提示或指出其他必须采取的安全措施以保护安全？ - Rajat Gupta

@user01，这真的是另一个StackExchange网站（security.stackexchange.com）的话题。但在这种情况下，如果目标是获取源代码，那么入侵正在运行的生产服务器来窃取源代码是最不可能发生的情况之一。这样的攻击者的真正目标是您的源代码控制存储库。 - Yishai

Answer 4

值得对Java Web应用程序进行混淆吗？

这要看情况。

如果您将Web应用程序授权安装在客户站点上，并且不希望客户通过反编译来重用您的代码，则值得进行混淆。

如果您提供Web应用程序服务，并且只能从您处获得安装，则我认为不值得。更好的做法是增强网络安全性。

- OscarRyz

---

混淆并不能防止客户反编译您的代码。即使他们无法完全成功地将其反编译为可用的Java源代码，他们可能仍然可以找出您试图隐藏在代码中的任何秘密。 - Stephen C

也许我们需要混淆来保护我们的代码不被网络主机窃取，对吧？ - Rajat Gupta

Answer 5

我想补充一点，你需要有一个好的理由，因为混淆会使调试更加困难。

- daveb

---

也许我们需要混淆来保护我们的代码甚至整个业务，以防止网络主机窃取，不是吗？ - Rajat Gupta

Answer 6

你可能会发现Do you obfuscate your commercial Java code?的回答是相关的。

- Thorbjørn Ravn Andersen

Answer 7

绝对是的。

如果您的开发过程正确，只有二进制文件和一些支持文件（例如标记和样式表）需要在服务器上。在任何生产环境中，没有不混淆二进制文件的好理由。

这里的其他人说这样做会给员工带来问题。唯一应该知道或关心您的二进制文件内容的人是开发人员 - 他们拥有源代码，因此不应该担心浏览已编译的对象。

我唯一能想到的任何人没有访问源代码却对二进制文件内容感兴趣的原因是反向工程 - 除非他们没有访问源代码。这意味着他们没有获得该代码的授权，或者您已经失去了它，这意味着您的源代码控制系统要么很糟糕，要么完全丢失。那是一个完全不同的谈话。

我还没有听到任何实际的例子表明服务器端混淆会导致开发或管理困难。

- 3Dave

Answer 8

混淆你的服务器端代码是个好主意吗？我会毫不犹豫地回答YES。

事实上，最终用户只是可能有恶意计划的群体之一。往往内部员工，无论他们是业务用户、支持人员等，也可能有自己的计划...或者成为无意识的 帮凶。

如果您处理任何需要密码访问的信息，那么您有一个责任，利用您可以使用的每个工具来保护这些信息。

这包括保护它免受外部和内部人员的侵害。由于内部人员过度访问，公司经常失去数据和知识产权。无论这些人员是故意窃取信息还是仅仅因为黑客攻击而失去了对他们的计算机的控制都是无关紧要的。

所以，再次强调，其中一步是混淆代码，希望获取二进制文件的人更难弄清楚你的应用程序如何工作。当然，你应该采取更多措施来保护它所在的服务器；不仅仅是生产环境，而且要一直延伸到源代码控制。

- NotMe

---

在人们实际犯罪之前，你正在将他们定罪。虽然许多入侵企图来自内部来源，但混淆代码并不是给予员工太多权限的正确解决方案。混淆更有可能令合法管理者感到恼怒，而且不能防止恶意内部人员引起骚乱。如果您不希望任何人阅读您的文件，请使用操作系统的文件系统访问控制，并允许人们执行但不读取可执行文件。 - Lie Ryan

@Lie Ryan：混淆只是工具箱中的一种工具。ACL也很关键，但事实上，非开发人员也能够访问代码；混淆至少提供了一些防御。至于在他们犯罪之前将其定罪...我宁愿在发现“值得信赖”的人已经植入代码、复制代码和/或数据等之前，消除任何诱惑和/或能力。但是，嘿，如果你想相信企业间谍不存在，那就更有力量吧。天哪，几个星期前我见过一个拥有竞争对手源代码副本的家伙。不知道他是怎么得到的。 - NotMe

当然，最不容易让你被监禁的版本是：等待该公司发布工作，申请并得到这份工作。然后自己拷贝那些东西。最后辞职。 - NotMe

@ChrisLively：如果你非常担心编译后的文件安全问题，在Linux/Unix的安全方案（八进制位）中，是否可以轻松地允许用户“执行”程序而不允许他/她实际“读取”程序？如果你的非开发人员账户没有“读取”程序的能力，你就不需要因为混淆而给开发团队带来麻烦。我相信这在ACL中也是可能的。他们只会看到一个文件，他们可以执行它，但他们不能在文本/十六进制编辑器中打开它或复制它。 - Lie Ryan

也许我们需要混淆来保护我们的代码，以免被网络主机窃取，不是吗？ - Rajat Gupta