转载

JavaEE中遗漏的10个最重要的安全控制

英文原文： The 10 Most Important Security Controls Missing in JavaEE

JavaEE 有一些超赞的内置安全机制，但它们远远不能覆盖应用程序要面临的所有威胁。很多常见攻击，例如跨站点脚本攻击（XSS）、SQL 注入、跨站点伪造请求（CSRF），以及 XML 外部实体（XXE）丝毫没有涵盖。你可以阻止 web 应用程序和 web 服务暴露于这些攻击，但这需要一定量的工作和测试。幸运的是，Open Web Application Security Project（OWASP）公布了“10 大最关键的 web 应用程序安全风险”的报告。

让我们来看看这些关键的风险如何应用于 JavaEE 的 web 应用程序和 web 服务：

1. 注入

注入发生在开发人员获取不可信的信息，例如 request.getParameter（），request.getCookie（），或 request.getHeader（），并在命令接口中使用它的任何时候。例如，SQL 注入在你连接不可信的数据到常规 SQL 查询，如“SELECT * FROM users WHERE username=‘“ + request.getParameter (“user”) + “‘ AND password=‘“ + request.getParameter (“pass”) = “‘“时发生。开发人员应该使用 PreparedStatement 来防止攻击者改变查询的含义和接管数据库主机。还有许多其他类型的注入，如 Command 注入、LDAP 注入以及 Expression Language (EL) 注入，所有这些都极度危险，因此在发送数据到这些解释器的时候要格外小心。

2. 损坏的验证和会话管理

JavaEE 支持身份验证和会话管理，但这里有很多容易出错的地方。你必须确保所有经过验证流量都通过 SSL，没有例外。如果你曾经暴露 JSESSIONID，那么它就可被用来在你不知情的情况下劫持用户会话。你应该旋转 JSESSIONID，在用户进行身份验证以防止会话固定攻击（Session Fixation attack）的时候。你应该避免使用 response.encodeURL（），因为它会添加用户的 JSESSIONID 到 URL，使得更容易被披露或被盗。

3. 跨站点脚本攻击（XSS）

XSS 发生在当 JavaEE 开发人员从 HTTP 请求获取不可信的信息，并把它放到 HTTP 响应中，而没有适当的上下文输出编码的时候。攻击者可以利用这个行为将他们的脚本注入网站，然后在这个网站上劫持会话和窃取数据。为了防止这些攻击，开发人员需要执行敏感的上下文输出编码。如果你把数据转换成 HTML，使用&#xx;格式。请务必括号 HTML 属性，因为有很多不同字符而不带括号的属性会被终止。如果你把不可信的数据放到 JavaScript，URL 或 CSS 中，那么对于每一个你都应该使用相应的转义方法。并且在和嵌套上下文，如一个用 Javascript 写的在 HTML 属性中的 URL 打交道时，要非常小心。你可能会想要编码库，例如 OWASP ESAPI 的帮助。

4. 不安全的直接对象引用

任何时候应用程序暴露了一个内部标识符，例如数据库密钥，文件名，或 hashmap 索引，攻击者就可以尝试操纵这些标识符来访问未经授权的数据。例如，如果你将来自于 HTTP 请求的不可信的数据传递到 Java 文件构造器，攻击者就可以利用“../”或空字节攻击来欺骗你的验证。你应该考虑对你的数据使用间接引用，以防止这种类型的攻击。ESAPI 库支持促进这种间接引用的 ReferenceMaps。

5. 错误的安全配置

现代的 JavaEE 应用程序和框架，例如 Struts 和 Spring 中有着大量的安全设置。确定你已经浏览过这些安全设置，并按你想要的那样设置。例如，小心<security-constraint>中的<http-method>标签。这表明安全约束仅适用于列出的方法，允许攻击者使用其他 HTTP 方法，如 HEAD 和 PUT，来绕过整个安全约束。也许你应该删除 web.xml 中的<http-method>标签。

6. 敏感数据暴露

Java 有大量的加密库，但它们不容易正确使用。你应该找到一个建立在 JCE 基础上的库，并且它能够方便、安全地提供有用的加密方法。比如 Jasypt 和 ESAPI 就是这样的库。你应该使用强大的算法，如 AES 用于加密，以及 SHA256 用于 hashes。但是要小心密码 hashes，因为它们可以利用 Rainbow Table 被解密，所以要使用自适应算法，如 bcrypt 或 PBKDF2。

7. 缺少功能级访问控制

JavaEE 支持声明式和程序式的访问控制，但很多应用程序仍然会选择创造它们自己的方案。像 Spring 框架也有基于注释的访问控制基元。最重要的事情是要确保每一个暴露的端口都要有适当的访问控制检查，包括 web 服务。不要以为客户端可以控制任何东西，因为攻击者会直接访问你的端点。

8. 跨站点伪造请求（CSRF）

每个改变状态的端点需要验证请求有没有被伪造。开发人员应该在每个用户的会话中放入随机令牌，然后当请求到达的时候验证它。否则，攻击者就可以通过链接到未受保护的应用程序的恶意 IMG，SCRIPT, FRAME 或 FORM 标签等创建“攻击”页面。当受害者浏览这种页面时，浏览器会生成一个“伪造”的 HTTP 请求到 URL 在标签中被指定的任何内容，并且自动包括受害人的认证信息。

9. 使用带有已知漏洞的组件

现代的 JavaEE 应用程序有数百个库。依赖性解析工具，如 Maven，导致了这个数字在过去五年时间里出现爆炸式增长。许多广泛使用的 Java 库都有一些已知的漏洞，会让 web 应用程序被完全颠覆。解决的办法是及时更新库。不要只运行单一扫描，因为新的漏洞每天都在发布。

10. 未经验证的转址和转送

任何时候你的应用程序使用不可信的数据，例如 request.getParameter（）或 request.getCookie（），在调用 response.sendRedirect（）时，攻击者可以强制受害者的浏览器转到一个不受信任的网站，目的在于安装恶意软件。forward 也存在着类似的问题，不同之处在于攻击者可以转送他们自己到未经授权的功能，如管理页面。一定要仔细验证转址和转送目标。

你应该持续留意这些问题。新的攻击和漏洞总是在被发现。理想情况下，你可以集成安全检查到现有的构建、测试和部署过程。

要在应用程序中检查这些问题，可以尝试免费的 Contrast for Eclipse 插件。这不是一个简单的静态分析工具。相反，C4E 利用 Java 仪表化 API，来监视应用程序中与安全相关的一切。 C4E 甚至能实时地做到完整的数据流分析，因此它可以跟踪来自于请求的数据，通过一个复杂的应用程序。例如，假设你的代码获取了一个参数值，用 base64 解码它，再存储于 map 中，把 map 放到数据 bean 中，再将 bean 存储到一个会话属性中，在 JSP 中获取 bean 的值，并使用 EL 将这个值插入到网页。Contrast for Eclipse 可以跟踪这些数据并报告 XSS 漏洞。哪怕你正在使用的是复杂的框架和库。没有其他工具能在速度，精度和易用性方面与之媲美。

你可以在 Eclipse Marketplace 找到 Contrast for Eclipse。然后，只需转到服务器选项卡“Start with Contrast”——剩下的就交给它办吧。

译文链接： http://www.codeceo.com/article/10-security-controls-in-javaee.html

翻译作者：码农网 – 小峰

原文 http://news.cnblogs.com/n/544288/

正文到此结束