在 Log4j 漏洞导致近一半的全球企业网络成为攻击目标之前，Java 应用程序就已经为黑客提供了大量机会。毕竟，要保护的组件太多了——服务器端逻辑、客户端逻辑、数据存储、数据传输、API 等等，项目或系统引入诸多第三方组件包，这些包缺少有效的安全性评估。
事实上，44% 的 Java 应用程序存在严重漏洞，而 .NET 应用程序的这一比例为 23%。幸运的是，大多数漏洞都有相同的根本原因。但在你修复它们之前，你必须找到它们。要找到它们，你必须知道你在寻找什么。考虑到这一点，以下是我们列出的七大 Java 安全陷阱 - 以及您应该如何处理它们：
1、XXE 攻击。
当网络对手利用可扩展标记语言 (XML) 解析器读取您服务器上的任意文件时，就会发生这种情况。然后，他们可以部署 XML 外部实体 (XXE) 来检索用户信息、配置文件甚至是云环境的凭据。大多数 Java XML 解析器默认启用 XXE 要求，因此您应该主动禁用这些以避免 XXE 攻击。
2、不安全的反序列化。
在序列化过程中，编程语言中的对象被转换为可以保存到数据库或通过网络传输的格式。在反序列化期间，会发生相反的情况：序列化的对象是从文件或网络中读取的，因此您可以将其转换回对象。
然而，黑客会以不安全的反序列化形式寻找漏洞，从而可以操纵序列化对象发起身份验证绕过、拒绝服务或任意代码执行攻击。
为防止这种情况，您需要及时更新补丁。您还应该确保您的第三方代码符合您的防御标准，因为许多不安全的反序列化导致的漏洞是通过依赖项引入的。
3、远程代码执行。
黑客在你的机器上执行他们的代码时提交远程代码执行 (RCE)，通常是通过命令注入漏洞——用户输入直接链接到系统命令的 RCE。您的应用程序无法区分用户输入的位置和系统命令的位置，因此它将用户输入作为代码执行。这允许黑客在机器上执行任意命令。
您最好的对策是提出一个有效的许可名单，这将确保稳健的输入验证。
4、SQL注入。
广义上讲，当应用程序无法正确区分不受信任的用户数据和合法/有效代码时，就会出现注入。在操作系统命令中，这会导致命令注入。
在结构化查询语言 (SQL) 注入的情况下，攻击者会注入数据来操纵 SQL 命令。如果应用程序无法正确验证用户输入，攻击者将插入为 SQL 语言指定的字符，以破坏查询逻辑并执行任意 SQL 代码。他们可以利用受损的查询结构来修改或窃取数据和/或在操作系统中执行任意命令。
这就是为什么您必须利用参数化语句来使 SQL 注入几乎不可能的原因，方法是预编译 SQL 语句，以便您严格提供要插入到语句中以执行它的参数（或变量/输入）。
5、NoSQL 注入。
“Not only SQL” (NoSQL) 数据库不使用 SQL 语言。在 NoSQL 注入期间，黑客会将数据注入数据库语言的逻辑中，以启用身份验证绕过和 RCE。MongoDB、Couchbase、Cassandra、HBase 和其他 NoSQL 数据库容易受到这些攻击。
NoSQL 查询语法是特定于数据库的，查询通常是用应用程序的编程语言编写的。因此，您必须使用特定于数据库的方法来阻止 NoSQL 注入。我们在此处提供了有关保护各个主要数据库的更详细的指导。
6、LDAP 注入。
轻量级目录访问协议 (LDAP) 使开发人员能够查询有关系统用户和设备的目录服务。但是，当应用程序在这些查询中允许不受信任的输入时，黑客可以提交精心设计的输入以绕过身份验证并篡改存储在目录中的数据。同样，参数化查询在这里仍然有效地预防。
7、日志注入。
安全团队依靠系统日志来检测网络中的恶意活动。但是攻击者意识到了这一点，并且会在攻击期间经常更改日志文件以掩盖他们的踪迹。通过典型的日志注入，他们会欺骗应用程序在您的日志文件中写入虚假条目。
例如，他们可能会寻找不清理写入日志的输入中的换行符的应用程序，以引入他们自己的换行符并插入新的应用程序日志条目。或者，他们会将恶意 HTML 注入日志条目，从而对监督日志的管理员的浏览器发起跨站点脚本 (XSS) 攻击。
为避免这种情况，您需要通过在每个日志条目前加上时间戳、进程 ID、主机名和其他形式的元数据来区分真实日志条目和假日志条目。在应用零信任原则时，您应该将日志文件内容视为不受信任的输入，直到您完全验证了它的访问和操作。
Java 安全陷阱列表几乎不包含在这七个中，因为计划发布一本电子书，其中详细总结了 29 个最常见的漏洞。 当团队意识到他们的 Java 应用程序中存在可能暴露他们的东西时，他们就更接近于发现并消除使他们容易受到攻击的问题。
