锐客网

  1. 首页 > 睿知 > it技术 > >

java劣质代码 java恶意代码( 六 )

IT技术代码


清单 15. 返回可变对象的副本
public Exposed getExposedObj(){
return new Exposed(exposedObj.getId(),exposedObj.getName());
}
或者 ， 您的代码也可以返回 Exposed 对象的克隆 。
检查本机方法
本机方法是一种 Java 方法，其实现是用另一种编程语言编写的，如 C 或 C++ 。有些开发人员实现本机方法，这是因为 Java 语言即使使用即时（just-in-time）编译器也比许多编译过的语言要慢 。其它人需要使用本机代码是为了在 JVM 以外实现特定于平台的功能 。
影响
使用本机代码时，请小心，因为对这些代码进行验证是不可能的，而且本机代码可能潜在地允许 applet 绕过通常的安全性管理器（Security Manager）和 Java 对设备访问的控制 。
建议
如果非得使用本机方法，那么请检查这些方法以确定：
它们返回什么
它们获取什么作为参数
它们是否绕过安全性检查
它们是否是 public、private 等等
它们是否含有绕过包边界从而绕过包保护的方法调用
结束语
编写安全 Java 代码是十分困难的 ， 但本文描述了一些可行的实践来帮您编写安全 Java 代码 。这些建议并不能解决您的所有安全性问题，但它们将减少暴露数目 。最佳软件安全性实践可以帮助确保软件正常运行 。安全至关重要和高可靠系统设计者总是花费大量精力来分析和跟踪软件行为 。只有通过将安全性作为至关紧要的系统特性来对待 — 并且从一开始就将它构建到应用程序中，我们才可以避免亡羊补牢似的、修修补补的安全性方法 。
参考资料
请通过单击文章顶部或底部的讨论来参加本文的论坛 。
了解关于 Java 安全性 API 的更多知识 。
developerWorks 安全专题上通常含有有关计算机安全性的优秀资源 。
Larry Koved、 Anthony J. Nadalin、Don Neal 和 Tim Lawson 合作编写的 “The evolution of Java security”（developerWorks，1998 年）对 Java 语言的安全性模型早期开发进行了深入探讨 。
Sing Li 在他的 Java 安全性系列文章（由两部分组成的）（developerWorks， 2001 年 2 月）中向开发人员显示：尽管社区可能不得不重新考虑 Java 2 中的安全性设计 ， 还是出现了只对开发人员有帮助，可以满足他们的需求的一致的进展：
第一部分
第二部分
John Viega、Tom Mutdosch、 Gary McGraw 和 Ed Felten 合著的 “Statically scanning Java code for security vulnerabilities” （IEEE Software，2000 年 9 月）介绍了一种 Java 工具，可以使用该工具来检查您的 Java 代码中的安全性漏洞 。
G. McGraw 和 E. Felten 合作编写的 Securing Java: Getting Down to Business with Mobile Code（John Wiley 和 Sons，1998 年）深入涵盖了 Java 安全性 。（文档是 PDF 格式的 。）
定期检查 IBM 研究 Java 安全页面以便 IBM 在安全性领域的创新有重要发展时能够跟踪这一创新 。
如果您的 Java 代码运行在 S/390 系统上，那么您将需要查阅 S/390 Java 安全页面以获取额外的信息 。
关于作者
Bijaya Nanda Sahu 是就职于印度 IBM Global Services 的软件工程师 。他从事过各种因特网技术和框架（J2EE、WSBCC、JADE）、 WebSphere 相关技术、UML 和 OOAD 方面的工作 。目前，他从事因特网银行安全性问题方面的工作 ， 重点在 WebSphere Application Server 和 Portal Server 上 。可以通过 bijaya.sahu@in.ibm.com 和他联系
【转】如何保护Java代码以下从技术角度就常见的保护措施 和常用工具来看看如何有效保护java代码：1. 将java包装成exe特点：将jar包装成可执行文件，便于使用，但对java程序没有任何保护 。不要以为生成了exe就和普通可执行文件效果一样了 。这些包装成exe的程序运行时都会将jar文件释放到临时目录 ， 很容易获取 。常用的工具有exe4j、jsmooth、NativeJ等等 。jsmooth生成的exe运行时临时目录在exe所在目录中或是用户临时目录 中；exe4j生成的exe运行时临时目录在用户临时目录中；NativeJ生成的exe直接用winrar打开 ， 然后用zip格式修复成一个jar文件 ， 就得到了原文件 。如果只是为了使用和发布方便，不需要保护java代码，使用这些工具是很好的选择 。2. java混淆器特点：使用一种或多种处理方式将class文件、java源代码进行混淆处理后生成新的class ， 使混淆后的代码不易被反编译，而反编译后的代码难以阅 读和理解 。这类混淆器工具很多，而且也很有成效 。缺点：虽然混淆的代码反编译后不易读懂，但对于有经验的人或是多花些时间，还是能找到或计算出你代码中隐藏的敏感内容，而且在很多应用中不是全部代码都能混淆的 ， 往往一些关键的库、类名、方法名、变量名等因使用要求的限制反而还不能混淆 。3. 隔离java程序到服务端特点：把java程序放到服务端，让用户不能访问到class文件和相关配套文件，客户端只通过接口访问 。这种方式在客户/服务模式的应用中能较好地保护java代码 。缺点是：必须是客户/服务模式，这种特点限制了此种方式的使用范围；客户端因为逻辑的暴露始终是较为薄弱的环节，所以访问接口时一般都需要安全性认证 。4. java加密保护特点：自定义ClassLoader ， 将class文件和相关文件加密，运行时由此ClassLoader解密相关文件并装载类 ， 要起到保护作用必须自定 义本地代码执行器将自定义ClassLoader和加密解密的相关类和配套文件也保护起来 。此种方式能很有效地保护java代码 。缺点：可以通过替换JRE包中与类装载相关的java类或虚拟机动态库截获java字节码 。jar2exe属于这类工具 。5. 提前编译技术(AOT)特点：将java代码静态编译成本地机器码，脱离通用JRE 。此种方式能够非常有效地保护java代码，且程序启动比通用JVM快一点 。具有代表性的是GNU的gcj，可以做到对java代码完全提前编译，但gcj存在诸多局限性，如：对JRE 5不能完整支持、不支持JRE 6及以后的版本 。由于java平台的复杂性，做到能及时支持最新java版本和JRE的完全提前编译是非常困难的 ， 所以这类工具往往采取灵活方式，该用即时编译的地方还是 要用 ， 成为提前编译和即时编译的混合体 。缺点：由于与通用JRE的差异和java运用中的复杂性，并非java程序中的所有jar都能得到完全的保护；只能使用此种工具提供的一个运行环境，如果工具更新滞后或你需要特定版本的JRE，有可能得不到此种工具的支持 。Excelsior JET属于这类工具 。6. 使用jni方式保护特点：将敏感的方法和数据通过jni方式处理 。此种方式和“隔离java程序到服务端”有些类似，可以看作把需要保护的代码和数据“隔离”到动态库中，不同的是可以在单机程序中运用 。缺点和上述“隔离java程序到服务端”类似 。7. 不脱离JRE的综合方式保护特点：非提前编译，不脱离JRE ， 采用多种软保护方式，从多方面防止java程序被窃取 。此种方式由于采取了多种保护措施 ， 比如自定义执行器和装载器、加密、JNI、安全性检测、生成可执行文件等等，使保护力度大大增强，同样能够非常有效地保护java代码 。缺点：由于jar文件存在方式的改变和java运用中的复杂性，并非java程序中的所有jar都能得到完全的保护；很有可能并不支持所有的JRE版本 。JXMaker属于此类工具 。8. 用加密锁硬件保护特点：使用与硬件相关的专用程序将java虚拟机启动程序加壳，将虚拟机配套文件和java程序加密，启动的是加壳程序 ， 由加壳程序建立一个与硬件相关的 受保护的运行环境，为了加强安全性可以和加密锁内植入的程序互动 。此种方式与以上“不脱离JRE的综合方式保护”相似 ， 只是使用了专用硬件设备，也能很好地保护java代码 。缺点：有人认为加密锁用户使用上不太方便 ， 且每个安装需要附带一个 。从以上描述中我们可以看出：1. 各种保护方式都有其优缺点，应根据实际选用2. 要更好地保护java代码应该使用综合的保护措施3. 单机环境中要真正有效保护java代码 ， 必须要有本地代码程序配合当然，安全都是相对的，一方面看你的保护措施和使用的工具能达到的程度，一方面看黑客的意愿和能力，不能只从技术上保护知识产权 。总之，在java 代码保护方面可以采取各种可能的方式，不可拘泥于那些条条框框 。

推荐阅读


上一篇：喇叭双开关怎么连接电视机，双喇叭并联还是串联

下一篇：sap水晶，sap水晶报表教程