七个常见的Java应用安全陷阱及应对，原来如此简单

　　Java应用程序已经成为黑客经常攻击的目标，毕竟，它涉及的组件太多：服务器端逻辑、客户端逻辑、数据存储、数据传输、API及其他组件，确保所有组件安全无疑困难重重。实际上，23%的.NET应用程序存在严重漏洞，而44%的Java应用程序存在严重漏洞。
　　Java应用安全方面的挑战有很多，不过，本文列举了七个较常见的典型安全陷阱，如果企业安全团队意识到Java应用程序中可能存在漏洞，先试着从这几个方面着手开展工作，可能会更容易、更快捷发现并消除问题。  XXE攻击
　　如果网络攻击者利用可扩展标记语言(XML)解析器读取服务器上的任意文件，会出现这种攻击。随后他们可以部署XML外部实体(XXE)，以检索获取用户信息、配置文件甚至云环境的凭证。大多数Java XML解析器默认启用XXE要求，因此企业安全人员应该主动禁用XXE以避免XXE攻击。  不安全的反序列化
　　在序列化过程中，编程语言中的对象被转换成可以保存到数据库或通过网络传输的格式。反序列化过程中则出现相反的情况，即序列化的对象从文件或网络中读取，因此可以将其转回成对象。然而，黑客会寻找不安全的反序列化漏洞，以便可以操纵序列化对象，发起身份验证绕过、拒绝服务或任意代码执行等攻击。为防止出现这种情况，安全人员需要打上最新补丁，并确保第三方代码符合防御标准，因为许多不安全的反序列化漏洞通过依赖项引入。  远程代码执行
　　黑客经常在受害者的机器上执行远程代码(RCE)，常常通过命令注入漏洞来实现：用户输入直接与系统命令相关联。因为应用程序无法区分用户输入和系统命令，所以会将用户输入作为代码来执行，这让黑客得以在机器上执行任意命令。最有效的对策是列出一份有效的许可名单，这将确保形成稳健的输入验证机制。  SQL注入
　　笼统地讲，当应用程序无法正确区分不受信任的用户数据和合法/有效代码时，就会出现注入。在操作系统命令中，这会导致命令注入。以结构化查询语言(SQL)注入为例，攻击者注入数据以操纵SQL命令。如果应用程序无法正确验证用户输入，攻击者将会插入为SQL语言指定的字符，以破坏查询逻辑，并执行任意SQL代码。他们可以利用受感染的查询结构来篡改或窃取数据，及/或在操作系统中执行任意命令。为此可以预编译SQL语句，以便严格提供插入到语句来执行的参数(或变量/输入)。  NoSQL注入
　　NoSQL数据库不使用SQL语言。在NoSQL注入期间，黑客会将数据注入到数据库语言逻辑中，以启用身份验证绕过和RCE。MongoDB、Couchbase、Cassandra、HBase及其他NoSQL数据库容易受到这类攻击。NoSQL查询语法针对特定的数据库，查询常常用应用程序的编程语言来编写。因此，必须采用针对特定数据库的方法来阻止NoSQL注入。  LDAP注入
　　轻量级目录访问协议(LDAP)使开发人员能够查询有关系统用户和设备的目录服务。但是当应用程序在这些查询中允许不受信任的输入时，黑客可以提交精心设计的输入，以绕过身份验证，并篡改存储在目录中的数据。设置参数化查询在这里同样会起到有效的预防作用。  日志注入
　　安全团队依靠系统日志来检测网络中的恶意活动。攻击者也意识到这一点，会在攻击期间篡改日志文件以掩饰行踪，通过典型的日志注入，他们可以诱骗应用程序在日志文件中写入虚假条目。比如，攻击者可能会寻找那些不清理写入到日志输入内容中换行符的应用程序，引入自己的换行符，并插入新的应用程序日志条目。或者将恶意HTML注入到日志条目中，对监管日志的管理员的浏览器发起跨站点脚本(XSS)攻击。
　　为避免出现这种情况，企业安全人员需要在每个日志条目前加上时间戳、进程ID、主机名及其他形式的元数据，以此区分真实日志条目和虚假日志条目。在采用零信任原则时，应该将日志文件内容视为不受信任的输入，除非输入完全通过了验证，否则不能允许访问和操作。