跨站点历史操作解决方案

Question

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

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

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

能否帮助我理解这个漏洞以及应该采取哪些措施来消除这种漏洞？

Answer 1

这与其说是 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 的回答与我的非常相似，并且包含很多相同的信息，只是海报指出这仍然是一个问题。

但是，如果您通过locationHTTP 标头重定向服务器端，则 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. Login.jsp在 IFrame 中打开- 历史包含Login.jsp.
2. 打开ShowSecretInfo.jsp- 如果服务器随后Login.jsp使用 HTTP 3xx重定向到，history.length则将保持不变，如果服务器显示ShowSecretInfo.jsp-history.length将增加 1。

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

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

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

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

Answer 2

下面是我从亚历克斯Roichman，首席软件架构师@得到了答案Checkmarx：

跨站点的历史操作是一个浏览器同源策略违反它可能知道从其他产地的条件的状态。例如，许多站点会在向用户显示其私人数据之前检查用户是否已通过身份验证。这可以通过以下代码完成：

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' - 如果服务器将重定向到'Login.jsp' 3xx，则history.length 将保持不变，如果服务器将显示'ShowSecretInfo.jsp'- history.length 将增加1。

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

Answer 3

来自OWASP 网站

\n\n

\n

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

\n

\n\n

使用request.getSession().getAttribute("sesStrUID")，您没有执行任何进入浏览器历史记录的操作，因此看起来它的检测错误

\n