JavaEE的十大安全控制

0x00前言

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

0x01 注入

    注入发生在开发人员获取不可信的信息，例如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) 注入，所有这些都极度危险，因此在发送数据到这些解释器的时候要格外小心。

0x02损坏的验证和会话管理

    JavaEE支持身份验证和会话管理，但这里有很多容易出错的地方。你必须确保所有经过验证流量都通过SSL，没有例外。如果你曾经暴露JSESSIONID，那么它就可被用来在你不知情的情况下劫持用户会话。你应该旋转JSESSIONID，在用户进行身份验证以防止会话固定攻击（Session Fixation attack）的时候。你应该避免使用response.encodeURL（），因为它会添加用户的JSESSIONID到URL，使得更容易被披露或被盗。
0x03跨站点脚本攻击（XSS）
    XSS发生在当JavaEE开发人员从HTTP请求获取不可信的信息，并把它放到HTTP响应中，而没有适当的上下文输出编码的时候。攻击者可以利用这个行为将他们的脚本注入网站，然后在这个网站上劫持会话和窃取数据。为了防止这些攻击，开发人员需要执行敏感的上下文输出编码。如果你把数据转换成HTML，使用&#xx;格式。请务必括号HTML属性，因为有很多不同字符而不带括号的属性会被终止。如果你把不可信的数据放到JavaScript，URL或CSS中，那么对于每一个你都应该使用相应的转义方法。并且在和嵌套上下文，如一个用Javascript写的在HTML属性中的URL打交道时，要非常小心。你可能会想要编码库，例如OWASP ESAPI的帮助。

0x04不安全的直接对象引用

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

0x05错误的安全配置

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

0x06敏感数据暴露

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

0x07缺少功能级访问控制

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

0x08跨站点伪造请求（CSRF）

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

0x09使用带有已知漏洞的组件

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

0x10未经验证的转址和转送

    任何时候你的应用程序使用不可信的数据，例如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”——剩下的就交给它办吧。

欢迎大家分享更好的思路，热切期待^^_^^ !!！