【问题标题】:Adding additonal Security to Website为网站添加额外的安全性
【发布时间】:2015-05-14 17:56:04
【问题描述】:

我正在运行基于 Java Spring MVC 的 Web 应用程序。它也基于 Hybris 平台。

现在,身份验证和授权方面的基本功能已经实现。这意味着我们确实有会话过滤器、工作用户系统等。

但是,我们目前没有针对诸如 XSS 和其他可能存在的攻击的安全措施。 XSS 可能是最大的担忧,因为它是最常见的攻击方式。

现在,我想知道......采取哪些步骤是明智的? 我环顾四周,发现存在 XSS-Filter 之类的东西。 实现这样很容易,只需复制源代码并将其添加为 tomcats web.xml 中。

但我想知道这样的过滤器是否提供了令人满意的安全性?

还有更多臃肿的解决方案,例如我可以使用 spring-security。 但是,阅读文档,我觉得这非常臃肿,其中很大一部分实现了已经实现的内容(例如两个 A)。我觉得将它配置到我需要它做的工作量需要做很多工作。 我错了吗?

还有:

您认为如何处理安全问题,例如 XSS?您是使用某个适合需求的预定义框架,还是按照cheat sheet 之类的内容“手工制作”您的安全性?

【问题讨论】:

  • 让我添加一个评论:考虑到您已经拥有大量的 JSP/JS,现在必须保护它们免受各种形式的 XSS 攻击。你会怎么做?安装过滤器似乎是不够的。至少我的研究表明,这些似乎总是有很多针对精心设计的攻击的漏洞。我觉得唯一的方法是逃避注入页面的每个输入。但是基本上不重写每个JSP和Js文件是不可能的,是吗?

标签: java spring security spring-security hybris


【解决方案1】:

以下是我在项目中所做的有关 hybris 安全性的列表:

初读文档

以下链接包含有关 hybris 安全性的资源和详细信息。

XML 解析器

我们经常需要从xml导入数据。

所有 Sax 解析器都应使用以下功能:

它允许

  • 指示实现安全地处理 XML。这可能会对 XML 构造设置限制,以避免出现诸如拒绝 服务攻击。
  • 不包括外部一般实体。
  • 不包括外部参数实体或外部 DTD 子集
  • 如果传入文档包含 DOCTYPE 声明,则引发致命错误

JSON

必须使用 OWASP lib json-sanitizer 验证所有输入。见https://www.owasp.org/index.php/OWASP_JSON_Sanitizer

例子:

String wellFormedJson = JsonSanitizer.sanitize(jsonData);
try
{
    return new ObjectMapper().readValue(wellFormedJson, JsonNode.class).toString();
}
catch (final IOException ex)
{
     LOG.error("Incorrect json data : " + wellFormedJson, ex);
}

日志

不得直接记录来自应用程序外部的字符串,以防止日志注入。

控制器案例

在 web 上下文中,所有控制器都必须扩展 BaseController。此类包含方法 logParam,应该用于记录未知内容。

此方法使用YSanitizer.sanitize(input)

public class YSanitizer
{
    public static String sanitize(final String input) {
        String output = StringUtils.defaultString(input).trim();
        output = output.replaceAll("(\\r\\n|\\r|\\n)+", " ");
        output = StringEscapeUtils.escapeHtml(output);
        return output;
    }
}

其他情况

拨打StringEscapeUtils.escapeJava(valToLog) 就足够了。

保护敏感数据免受堆检查

由于可以检查堆,因此不应将敏感数据存储在 String 对象中。

确实,字符串是不可变的,可以在堆中停留一段时间。

为防止出现此问题,所有敏感字符串都必须存储在 char[] 中。

这个数组应该尽快填充“0”(当不需要该值时)。

并不是说这种方法不是 100% 安全,而是减少了在堆中查找密码的时间窗口。

跨站脚本 (XSS)

确保de.hybris.platform.servicelayer.web.XSSFilter 在传入请求的过滤器列表中

部署检查 (from Go-Live Checklist)

  • 验证所有用户的默认密码是否已更改
  • 更改生产环境的管理员用户密码
  • 禁用自动登录或预填充密码
    • 产品驾驶舱
    • CMS 驾驶舱
    • CS 驾驶舱
    • hMC
  • 密码编码应该是MD5或更好的SHA256
  • 更改默认密码编码器
  • 为 MD5 和 SHA256 密码编码器更改 SALT
  • 验证数据库密码以及将其以纯文本形式存储在 local.properties 中的要求。
  • 确认用户帐户和结帐页面只能通过安全的 SSL 连接访问
  • 检查 Web 应用程序防火墙是否到位
  • 执行代码审查以确保没有敏感数据(如信用卡信息或密码)记录到日志文件中
  • 验证 hybris 应用程序服务器未以 root 身份运行
  • 保护已连接的 JMX

【讨论】:

    【解决方案2】:
    1. 设置 Anti-XSS 标头(提示:使用 Spring Security 或创建自己的 Interceptor

      Content-Security-Policy: default-src 'self'   --only allow content from your own site
      
      X-XSS-Protection: 1; mode=block   --prevent some reflective attacks in some browsers
      
      X-Content-Type-Options: nosniff   --can't trick browser into detecting and running js in other content types
      
    2. 防止恶意入站 HTML/JS/CSS

      在所有用户提供的字符串字段上使用Hibernate Validator(您不需要使用Hibernate ORM 来使用它)和@SafeHtml 注释。

      您可以在一个拦截器中验证所有请求标头、发布参数和查询参数,以进行简单的 XSS 验证。

    3. 在输出时转义所有用户提供的数据

      使用 OWASP 的 Java Encoder Project <e:forHtml value="${attr}" /> 转义输出或 JS​​TL 的 <c:out value="${attr}"/>web.xml 设置

      <context-param>
          <param-name>defaultHtmlEscape</param-name>
          <param-value>true</param-value>
      </context-param>
      

      如果转义 HTML 节点文本,它们同样安全,但 OWASP 对于 HTML 属性或 &lt;script&gt; 转义更安全。

      如果要编辑的文件太多,请考虑http://pukkaone.github.io/2011/01/03/jsp-cross-site-scripting-elresolver.html

    4. 使您的会话 cookie 无法被 JavaScript 读取。在web.xml:

      <session-config>
          <cookie-config>
              <!-- browser will disallow JavaScript access to session cookie -->
              <http-only>true</http-only>
          </cookie-config>
          <tracking-mode>COOKIE</tracking-mode>
      </session-config>
      
    5. 1234563

    【讨论】:

    • 感谢您的回答 :) 过去一个小时我进行了相当多的研究,我确实认识到了一些提示,但也有一些新的、很酷的 :) 到 1.) 这是否需要其他2个?实施其他 2 点感觉有点多余? 2.)后端验证实际上是我的目标。考虑到我有大约 60k 行 JSP/JS 代码……按照我在原始帖子中发布的备忘单的规则需要做很多工作。 To 3.) JSTLs out 方法是否与使用适当的 ESAPI 函数调用一样安全?那么,c:out 是否保证安全?
    • 而对于 context-param 的事情...。这些仅适用于 spring 引起的表单元素,对吧?如果我将不受信任的数据放在
      元素中,它不会产生安全影响,对吧? --- 总的来说,我认为后端验证是我的案例,因为它是最少的工作,我可以正确地假设包含奇怪字符的请求是不友好的。我没有可以使用任何特殊字符的用户输入,所以我不妨拒绝包含任何参数的请求。我会将您的答案标记为已接受,因为您很好地显示了最常见的选项,谢谢:)
    • @Mercious 1) 您应该使用所有技术来获得最大保护。冗余还是深度防御? 3) ESAPI 比 JSTL 更安全,除了 HTML 节点文本在这种情况下它们是相同的
    • @Mercious context-param 为 Spring Forms 和 jstl 开启 HTML Escape。
    • 可以接受,我想冗余确实不会伤害 :) 到 3) 所以应该考虑使用什么,这意味着我必须仔细查看 JSP/JS 代码并做出相应决定。我明白,是的。我已经在后端将 httpOnly 属性设置为 cookie,但很好!但是 AFAIK 它并没有阻止它们被读取,只是被写入?我刚刚看到您编辑的链接......听起来非常有希望!我去看看,非常感谢:)
    【解决方案3】:

    我想添加这个答案,因为我认为这是一件简单但重要的事情:

    就我而言,我意识到我不需要允许任何类型的关键特殊字符用于用户输入。我分析了情况,意识到这没有任何意义,也没有必要在我的任何网页中这样做。

    因此,不必在大约 60k 现有代码行上实现适当样式的 XSS 安全代码,我可以简单地安装一个过滤器来清除所有我不想允许的特殊字符。

    您可能会认为这在用户友好性方面有点关键,但应该没问题。

    所以:如果您意识到不需要允许任何特殊字符,这些字符在可能的上下文之一(例如 JS、HTML、属性、...)中至关重要,那么您可以安全很多工作,因为你和我现在/曾经处于同样的境地。

    如果您从头开始工作,显然执行 Neil 提到的步骤仍然是正确的风格。 如果人们在编写所有 JS 和 JSP 内容之前就知道这些步骤,那么他们肯定会实现它们,可能是否需要它们并不重要。

    【讨论】:

      猜你喜欢
      相关资源
      最近更新 更多
      热门标签