9

我们开发了一个新应用程序，在移动更改之前，我们使用 checkmarx 对代码进行了静态扫描。在名为 Cross Site History Manipulation 的代码中发现了一个中等级别的漏洞。

这在我验证会话值的 JSP 页面中被删除：

if(request.getSession().getAttribute("sesStrUID")!=null)

你能帮我理解这个漏洞吗？应该怎么做才能消除这个漏洞？

4

3 回答 3

5

这更像是一个浏览器漏洞，而不是 2010 年 Internet Explorer 中的网站漏洞：

Checkmarx 研究实验室在 Internet Explorer 中发现了一个新的严重漏洞（其他浏览器可能以相同的方式暴露），这将使黑客能够轻松破坏 Web 应用程序。

这违反了浏览器的同源策略，这不是您应该在 Web 应用程序中修复的问题。报告的漏洞可能是指您正在根据您的

request.getSession().getAttribute("sesStrUID")!=null

健康）状况。就是说，如果您根据会话sesStrUID值重定向服务器端，那么攻击者可以 IFrame 您的网站，如果它检测到您正在重定向，它可以推断是否sesStrUID为空。

如果您的用户使用损坏的浏览器，这只是一个问题。如果您的用户正在使用现代浏览器，那么这不值得修复 IMO。如果您想更加安全并防止点击劫持攻击，您可以输出X-Frame-Options: DENYHTTP 标头以防止框架。请注意，这只会保护您免受 IFrame 版本的攻击。有关深入讨论的其他攻击向量，请查看此 XSHM 论文。

在@adar 的回答后编辑：

Adar 的回答与我的非常相似，并且包含很多相同的信息，只是发帖人指出这仍然是一个问题。

location但是，如果您通过HTTP 标头重定向服务器端，则 XSHM 不是问题。HTTP 3xx重定向不会导致history.length现代浏览器中的值增加，因此不能用于确定用户是否登录到特定站点。

如果您在输出 JavaScript 代码以重定向

if(request.getSession().getAttribute("sesStrUID")!=null)

代码然后 XSHM 是一个问题，如果你正在重定向服务器端

<%
    String redirectURL = "http://example.com/myJSPFile.jsp";
    response.sendRedirect(redirectURL);
%>

那么你就不脆弱了。

在@adar 的回答 II 之后编辑：

@adar 是正确的：如果您尝试以下攻击场景：

  1. 在 IFrame 中打开Login.jsp- 历史包含Login.jsp.
  2. 打开- 如果服务器随后使用 HTTP 3xxShowSecretInfo.jsp重定向到，那么将保持不变，如果服务器显示-将增加 1。Login.jsphistory.lengthShowSecretInfo.jsphistory.length

因此，如果history.length增加，您可以确定用户已登录。我可以在 Windows 7 上使用 IE 11 和 Firefox 33.1 重新创建上述内容。从我的测试来看，Chrome 39 不会以这种方式受到攻击，但它在另一个方面：

假设如果用户未登录，则/ShowSecretInfo.jsp重定向到（没有查询）。/Login.jsp

  1. 在 IFrame 中打开/ShowSecretInfo.jsp- 历史包含/ShowSecretInfo.jsp.
  2. 将 IFrame src 设置为/Login.jsp- 如果history.length不增加，则您知道用户已登录。

src如果已设置为当前 URL ，Chrome 似乎不会尝试重定向。我也可以在 IE 和 Firefox 中重新创建它。

于 2015-01-06T09:53:35.183 回答
5

这是我从Checkmarx首席软件架构师 Alex Roichman 那里得到的答案：

跨站点历史操作是一种浏览器同源策略违规行为，它可以从另一个来源了解某种条件的状态。例如，许多网站会在向用户展示其私人数据之前检查用户是否经过身份验证。这可以通过以下代码完成：

If (!IsAuthenticated())
          Redirect “login.jsp”

通过使用 XSHM，可以从另一个站点了解用户当前是否已通过该站点的身份验证。

现在让我们寻找给定的行：

if(request.getSession().getAttribute("sesStrUID")!=null)

此行似乎检查用户是否有会话，甚至是否已经过身份验证。由于在“if”语句中存在“重定向”，因此任何其他站点都可能知道这一点，request.getSession().getAttribute("sesStrUID")!=null或者用户是否已经过身份验证。
因此，这个结果是正确的，它与旧的或现代的浏览器无关：所有现代浏览器都提供对 history.lengh 的访问，这个属性可能导致通过 XSHM 侵犯隐私，并且由于向后兼容性问题没有简单的修复。

X-Frame-Options：DENY可以防止 XSHM 的 IFrame 版本，但旧浏览器不支持此选项。

在 SilverlightFox 的回答后编辑

我同意我们有非常相似的答案。

不过，关于：

“3xx 重定向不会导致 history.length 的值在现代浏览器中增加”

这是正确的，XSHM 正是基于此。

寻找以下攻击场景：

  1. 在 IFrame 中打开“Login.jsp” - 现在历史记录中包含“login.jsp”。
  2. 打开 'ShowSecretInfo.jsp' - 如果服务器将重定向到 3xx 的 'Login.jsp'，那么 history.length 将保持不变，如果服务器将显示 'ShowSecretInfo.jsp' - history.length 将增加 1。

这意味着受攻击的用户已通过身份验证——侵犯隐私。

于 2015-01-09T21:12:24.020 回答
0

来自OWASP 网站

跨站点历史操作 (XSHM) 是一种 SOP（同源策略）安全漏洞。SOP 是现代浏览器最重要的安全概念。SOP 意味着来自不同来源的网页在设计上无法相互通信。跨站点历史操作违规是基于客户端浏览器历史对象未在每个站点上正确分区的事实。操纵浏览器历史可能导致 SOP 受损，允许双向 CSRF 和其他利用，例如：用户隐私侵犯、登录状态检测、资源映射、敏感信息推断、用户活动跟踪和 URL 参数窃取。

使用request.getSession().getAttribute("sesStrUID")，您没有做任何涉及浏览器历史记录的事情，所以看起来它的检测错误

于 2015-01-05T17:01:31.113 回答