预防跨站点请求伪造：了解浏览器选项卡中的隐藏危险（2）

look_w

防御 XSRF银行网站的开发人员如何预防这种攻击？我们看看一些防御 XSRF 攻击的方式。
引用页解决方案最简单的方法依赖于浏览器引用页头部。大多数浏览器会告诉 Web 服务器，哪个页面发送了请求。                 显示了浏览器向服务器发送的恶意站点请求示例：
清单 2. 发送到服务器的恶意请求示例

1 2 3 4 5 6 7 8

POST /bank/transfer.aspx HTTP/1.1 Referer: http://evilsite.com/myevilblog User-Agent: Mozilla/4.... Host: www.altoromutual.com Content-Length: 42 Cookie: SessionId=x3q2v0qpjc0n1c55mf35fxid; creditAccount=1001160141&transferAmount=10

开发人员可将引用页头部与银行主机的域名对比，拒绝任何其他请求。例如：

1 2 3 4

If(request.getHeaders("referer") != null    &&request.getHeaders("referer").indexOf(     "http://www.altoromutual.com") != 0){     throw new Exception("Invalid referer");         }

此外，如果需要，您可指定一个允许的 URL 列表，例如如果一个受信任的站点需要执行请求。
您可向 servlet 或页面基类应用该方法，以便站点的所有页面继承这一保护。但是一定要小心，如果您需要允许其他站点链接到 Altoro，此方法会破坏这些链接。                例如，Altoro 的客户无法从 Google 访问它。

1 2	GET /marketingannouncements HTTP/1.1 Referer: http://www.google.com

一种更好的解决方案是仅保护需要身份验证的页面。
引用页解决方案不会防御在电子邮件中发送的网站链接。引用页解决方案还依赖于客户端，需要正确地设置和处理引用页值。隐私软件可能删除头部，导致此保护方法不可靠。
引用页解决方案的优势在于，它兼容其他较早的基于 HTTP 的交互版本，比如 Web 服务。例如，如果客户端移动应用程序依靠站点上的一个 REST                API，那么引用页解决方案对客户端是透明的，因为客户端没有使用引用页头部。
但是，如果与较早版本的兼容性不是主要问题，那么还有更有效的解决方案，比如使用一个令牌让敏感的请求过期。
令牌解决方案令牌解决方案向表单添加一个参数，让表单在用户注销时或一个超时期限结束后过期。参见  。
清单 3. 令牌解决方案示例

1 2 3 4 5 6 7 8 9 10 11 12

<form id="transferForm" action="https://www.altoromutual.com/bank/transfer.aspx" method="post"> Enter the credit account: <input type="text" name="creditAccount" value=""> Enter the transfer amount: <input type="text" name="transferAmount" value=""> <input type="hidden" name="xsrftoken" value="JKBS38633jjhg0987PPll"> <input type="submit" value="Submit"> </form>

不要将令牌用作查询参数，因为这会使会话信息可在浏览器历史记录或 Web 日志指标和分析中看到。例如，使用下面的请求就不是个好主意：

1 2	https://www.altoromutual.com/bank/getuserinfo.aspx?creditAccount=1001160141&transferAmount=1000 &xsrftoken=JKBS38633jjhg0987PPll

要通过一个全面的措施保护所有类型的请求，并确保令牌值未在 URL 中暴露，最佳的方法是使用 HTTP 头。参见                  中的示例：
清单 4. HTTP XSRF                令牌头部示例

1 2 3 4 5 6 7 8 9

POST /bank/transfer.aspx HTTP/1.1 Referer: https://www.altoromutual.com/bank xsrftoken: JKBS38633jjhg0987PPll User-Agent: Mozilla/4.... Host: www.altoromutual.com Content-Length: 42 Cookie: SessionId=x3q2v0qpjc0n1c55mf35fxid; creditAccount=1001160141&transferAmount=10

在大多数越来越多地使用 REST API 和 Ajax 的现代应用程序中，HTTP 头是首选的解决方案。头部令牌可使用                  中的代码来设置：
清单 5. 设置头部令牌

1 2 3 4 5 6 7 8 9

<form id="transferForm" action="https://www.altoromutual.com/bank/transfer.aspx" method="post"> Enter the credit account: <input type="text" name="creditAccount" value=""> Enter the transfer amount: <input type="text" name="transferAmount" value=""> <button onClick="addXsrfHeaderAndSubmitForm(dojo.byId(transferForm))" value="Submit"> </form>

保护整个框架与引用页解决方案一样，检查令牌的最佳位置是某个影响所有经过验证的页面的位置。
一种不错的设计决策是，让所有这些页面继承一个基类，该基类应类似于  ：
清单 6. 继承一个基类

1 2 3 4 5 6 7 8 9 10 11 12 13

class AuthenticatedServletBase extends ServletBase { protected bool service(...){     .....     if(sessionUtil.getXsrfToken().equals(requestUtil.getXsrfToken())==false){         showXSRFTokenError();         return true;// handled..stop any further processing here     }     .... } }

XSRF 令牌的积极影响除了防御 XSRF 攻击，令牌头部解决方案还拥有更多安全优势，能够阻碍受保护页面上的其他类型的客户端攻击：

• JSON 劫持
• 反射式跨站点脚本攻击
• 通过 URL 重定向进行钓鱼攻击

XSRF                和安全扫描工具安全扫描程序常常报告此缺陷，问题常常并不是因为存在实际的漏洞。扫描程序无法理解请求是否敏感。但是，如果站点实现了一种全面的方法，比如本文前面介绍的一种方法，扫描程序不会发现任何这些                XSRF 问题。
如果像本文中介绍的那样修复了所有请求，而不只是修复了您认为敏感的请求，可能会预防缺乏经验的开发人员在未来引入问题。