每个Java开发人员都必须避免的9个安全错误

Checkmarx CxSAST是功能强大的源代码分析（SCA）解决方案，旨在从根本上识别，跟踪和修复技术和逻辑安全缺陷：源代码。 在这里查看 ！

自从1995年中期引入Java以来​​，它已经走了很长一段路。 它的跨平台特性使其成为客户端Web编程的基准。 但是由于网络犯罪和黑客行为由于其广泛的使用和分布而达到流行的程度，因此安全的Java开发需求已成为当务之急。

卡巴斯基实验室最近的一份报告称， Java是受到攻击最多的编程语言，全球范围内越来越多的黑客事件被举报。 Java的易感性很大程度上归因于其分段问题。 并非所有开发人员都在使用最新版本（Java 9），这基本上意味着并非总是应用最新的安全更新。

应用程序安全领域内越来越多的共识是，高代码完整性是确保应用程序健壮并不受顶级黑客技术攻击的最佳方法。 以下文章基于OWASP Java项目松散地包含9条建议，这是一项全面的工作，旨在帮助Java和J2EE开发人员生成可靠的应用程序。

每个Java开发人员都必须避免的9种编码应用程序错误做法

AppSec弊端1 –不限制对类和变量的访问

Java中公开的类，方法或变量基本上是对坏蛋的公开邀请。 确保所有这些默认情况下都设置为私有。 这将自动提高应用程序代码的健壮性，并阻塞潜在的攻击途径。 应该使用访问器来限制可访问性，并且应明确记录非私有事物。

AppSec Malpractice 2 –取决于初始化

开发人员应该意识到，构造函数不是必须实例化Java对象的事实。 分配未初始化对象的备用方法的存在是必须解决的安全问题。 理想的解决方案是对类进行编程，以使对象在执行任何操作之前先验证初始化。

可以通过执行以下步骤来实现：

• 所有变量都应设为私有。 外部代码应该只能通过安全的get和set方法访问这些变量。
• 每个对象都应添加初始化的私有布尔变量。
• 在执行任何操作之前，应使用所有非构造方法来验证初始化是否为true。
• 如果要实现静态初始化程序，请确保所有静态变量都是私有变量，并使用classInitialized。 就像上面提到的那样，静态初始化器（或构造器）在执行任何操作之前必须确保classInitialized为true。

AppSec Malpractice 3 –未完成课程

许多Java开发人员忘记使类（或方法）成为最终的。 这是一种不当行为，有可能使黑客以恶意方式扩展该类。 声明该类为非公共类并依赖于包范围限制以确保安全性可能会造成高昂的代价。 您必须使所有类都最终定型，并在确实需要时记录未定型的类。

AppSec弊端4 –依赖包装范围

Java编程语言中中等严重性的另一个问题是使用软件包。 这些软件包将类，方法和变量组合在一起，以便于访问，从而有助于开发过程。 但是，黑客可能会在您的程序包中引入流氓类，从而使他们能够访问和修改其中的数据。

因此，建议假定软件包未关闭且可能不安全。

AppSec弊端5 –尽量减少使用内部类的使用

传统的做法是将所有特权代码放入内部类中 ，这已被证明是不安全的。 Java字节码基本上没有内部类的概念，而内部类基本上只提供包级的安全性机制。 更糟糕的是，即使内部类被声明为私有的，它也可以访问外部类的字段。

内部类可以减少Java应用程序代码的大小和复杂性，可以说使它的错误更少，效率更高。 但是可以通过将字节代码注入到程序包中来利用这些类。 最好的方法是不要完全使用内部类，但是如果这样做，请确保将它们定义为私有类，就像外部类一样。

AppSec弊端6 –硬编码

Java开发人员犯下的最常见的安全错误之一就是对敏感信息的硬编码。 此编程错误涉及在代码内插入敏感密码，用户ID，PIN和其他个人数据。 敏感信息应存储在开发树中受保护的目录中。

AppSec错误做法7 –允许将敏感数据回显到UI

java.io软件包没有方法来确保对敏感数据的保护。 默认情况下，JDK附带的keytool应用程序回显用户输入。 Java开发人员应确保为所有击键（通常为“ *”）显示固定的字符。 例如，可以在Swing GUI应用程序中使用javax.swing.JPasswordField 。

AppSec错误做法8-不注意类别的可克隆性

Java中可用的克隆机制可以使黑客创建您定义的类的新实例。 可以执行此操作而无需任何构造的执行。 安全的Java开发基本上就是将对象变成非克隆对象。 这可以通过以下代码来实现：

如果您想走克隆路线，可以通过使用final关键字来实现压倒性的免疫力。 LOC看起来像下面的代码片段：

AppSec Malpractice No.9 –过度进行序列化和反序列化

Java具有使对象序列化的机制（反之亦然）。 通常在“关闭” Java虚拟机（JVM）时用于保存对象。 但这是不安全的做法，因为攻击者随后可以访问对象的内部并非法获取私有/敏感属性。 writeobject方法可用于防止序列化。

开发人员不应序列化敏感数据，因为那样的话，它将不受Java虚拟机（JVM）的控制。 如果没有解决方法，则应对数据进行加密。

反序列化也是如此，反序列化用于从字节流构造对象。 恶意攻击者可以尝试模仿合法类，并使用此技术来实例化对象的状态。 可以使用类似于writeobject的技术来防止反序列化。 如下所示，此安全方法称为readobject 。

安全SDLC和静态代码分析（SCA）

不幸的是，即使是最安全的开发准则和规则也不足以确保Java应用程序代码完美无缺。 开发人员的错误以及开发期间对代码进行的众多更改最终导致应用程序代码中的漏洞和漏洞。 但是组织应该能够尽快检测到这些。

当今市场上有各种各样的应用程序安全解决方案可用，每种解决方案都具有其独特的功能和优势。 但是理想的解决方案应该提供全面的功能集，并应集成到软件开发生命周期（SDLC）的所有阶段中，如果可能的话，可以实现自动测试以获得最佳结果。

属于静态应用程序安全测试（SAST）方法论的静态代码分析（SCA）就是这样一种解决方案。 这种技术的好处很多。 它们包括：

• 创建安全的SDLC（sSDLC） –通过将扫描解决方案集成到开发的所有阶段，甚至可以在构建完成之前就扫描应用程序代码。 测试源代码可以及早缓解漏洞，并显着加快开发过程。
• 多功能性 – SCA可以无缝地融合到几乎任何开发环境和模型中。 这可以是传统的Waterfall方法或持续集成（CICD）模型。由于其快速的扫描速度和准确的结果，该测试解决方案在敏捷和DevOps环境中也有效。
• 最佳的缓解性能 – SCA具有独特的功能，可以向开发人员显示代码中所检测到的漏洞的确切位置，从而可以快速有效地进行修复。 该安全解决方案还扫描具有广泛框架兼容性的多种编程和脚本语言。
• 范围广泛的漏洞 – SCA涵盖了广泛的问题–从应用程序层漏洞一直到编码漏洞。 甚至可以进行高级分析。 例如，可以通过扫描源代码来检测业务逻辑缺陷。 这为组织和开发人员提供了全面的安全解决方案。
• 投资回报（ROI） –总结起来，早期漏洞检测可以大大缩短补救时间并加快开发速度。 这有助于避免延迟，并最大程度地减少了占用大量资源的维护程序的需求。 换句话说，组织可以节省大量时间和金钱。

当开发人员和安全部门齐头并进并采取上述步骤时，就可以实现Java应用程序的安全性。 尽管开发人员可以并且应该实践安全的编码并生成具有高度完整性的代码，但CISO和安全人员应实施正确的解决方案，以尽早消除漏洞和漏洞。

只有有关各方的积极主动的方法才能帮助组织创建安全的应用程序。

Checkmarx CxSAST是功能强大的源代码分析（SCA）解决方案，旨在从根本上识别，跟踪和修复技术和逻辑安全缺陷：源代码。 在这里查看 ！

翻译自: https://www.javacodegeeks.com/2015/05/9-security-mistakes-every-java-developer-must-avoid.html