保护 mashup 中的工件和数据的技术和技巧-2

look_w

阻止会话固定（session fixation）在服务器上验证一个用户之前，如果没有首先使现有会话失效，可能会导致所谓的会话固定。会话固定允许入侵者截获验证后的会话，或者创建新会话并捕获会话标识符。当一个合法用户使用这个会话标识符创建一个会话时，该会话标识符可能会被恶意使用。
中的 Java™ 代码展示了验证一个客户机请求而没有首先使现有会话失效的例子。            
清单 3. 会话固定漏洞示例

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

private boolean authenticateUser(HttpServletRequest req) {   // session.invalidate() should have been called prior to this   // to invalidate an existing session   HttpSession session = req.getSession(false);   if (null != session)   {     // existing session assumed valid     return true;   }   if (authenticateRequest(req) == true)   {     // create a new session     req.getSession();     return true;   }       return false; }

清单 3 展示了这样一种情况：一个现有会话没有被设置为失效，因此该会话被认为对当前请求有效。当一个新用户向服务器提供验证凭证时，这种情况可能会成为漏洞，因为只要会话有效，它就允许现有会话的发起人记录数据甚至可能利用数据发起攻击。
阻止这种类型的攻击的技术有：

• 指定会话过期时间。
• 使用显示的注销 UI 控件来提示会话失效。
• 当需要保护隐私时，迫使用户重新输入凭证。
• 对每个请求重新生成会话标识符。

一个 mashup 页面中的入侵者常常利用这种情况来绕开浏览器限制并重定向敏感数据，然后再记录这些数据。这种攻击称为跨站点脚本编写（cross-site scripting）。         
阻止 CSRF 攻击CSRF 攻击由一个入侵站点的恶意代码发起，该代码欺骗浏览器，使其将无关的请求传输到一个受信任站点。浏览器的同源政策（SOP）并不阻止来自 不同来源的请求，而是只阻止传输到 不同来源的站点的请求。因此，SOP 不能阻止 CSRF 攻击。
CSRF 攻击依赖于这样一个服务器假设：来自启动了验证会话的浏览器的所有请求都是有效的。典型的身份验证机制，如用户名/密码、cookies 和 SSL 证书，都不足以抵御 CSRF 攻击，因为这些机制依赖于验证浏览器和服务器之间的会话，而不是每个单独请求与服务器之间的会话。
在 CSRF 攻击过程中，请求来自一个入侵者站点，然后通过一个经过验证的浏览器页面传输到服务器。然后，服务器在不知情的情况下将响应传输回入侵者站点。CSRF 攻击过程中的请求和响应的序列如  所示。
图 1. CSRF 攻击过程中的事件序列图 1 展示一个入侵者站点通过一个经过验证的 mashup 页面向一个 mashup 服务器发送请求。这种攻击只在一种情况下可行：入侵者站点使 mashup 页面为其将请求代理到企业 mashup 服务器。入侵者可以使用各种 HTML 技术进行这种攻击。
入侵者发动 CSRF 攻击所使用的一种技术是将一个 URL 嵌入到 <img> 标记的 src 属性中。当浏览器评估这个 <img> 标记时，这个 URL 将被引用。数据将被传输到该 URL 引用的主机。例如，注意下面的 <img> 标记：            

1	<img src="//mybank/transfer?amount=10000&fromaccount=44332&toaccount=55443">

如果 myback 对会话进行验证时，包含上述 <img> 标记的页面被访问，那么这个 <img> 标记将被评估并引用 src 属性中指定的 URL，从而启动被请求的动作。
如果 mybank 的服务器避免使用 HTTP GET 请求来发起更改，而是只使用 POST 来发起更改，那么您可以阻止这种类型的 DSRF 攻击。
mashup 服务器经常采用的一种阻止 CSRF 攻击的技术是要求每个 HTTP 请求都包含一个特定于请求的令牌，通过每个 POST 和 GET 请求一起传输到服务器。