安全技术研究CSRF攻击

　　介绍
　　跨站点请求伪造(CSRF / XSRF)是一种攻击类型，当用户通过恶意站点、博客、电子邮件、程序或即时消息进行身份验证时，在受害者不知情的情况下web浏览器在受信任的站点上执行非法的操作，就会发生这种攻击。
　　对于大多数站点，浏览器请求自动包含与站点相关的任何凭证(会话cookie、Windows域凭证、IP地址等)。因此，该网站无法区分受害者发送的是合法请求还是伪造请求。
　　执行CSRF攻击的攻击者无法看到伪造请求的响应，因为攻击是瞬时的，即state-changing请求。然而，当与针对管理员账号的社会工程攻击相结合时，这种方法可能对WEB应用程序造成严重的破坏。
　　影响及危害
　　CSRF攻击目标是专门针对state-changing的请求，而不是窃取数据，因为攻击者无法看到伪造请求的响应。成功的CSRF攻击的影响仅限于易受攻击的应用程序所暴露的能力。例如，这种攻击可能导致资金转移、更改密码或使用用户的凭证进行购买消费操作。
　　场景
　　CSRF攻击通常包括两种行为:通过社交工程或网络钓鱼诱骗受害者点击链接或加载页面，然后从受害者的浏览器向网站发送看似合法、精心制作的请求。攻击者能够发送带有值的请求，包括网站与受害者关联的cookie，仿冒受害者在网站上执行某些操作。
　　以下例子很好地说明了＂跨站点＂一词在这种攻击中的应用: 用户使用表单身份验证登录www.vulnerablexxxx.com。 服务器对用户进行认证。来自服务器的响应包括一个身份验证cookie。 在不注销的情况下，用户访问恶意网站，例如www.attackerwebsite.com。该恶意网站载有下列HTML:
　　注意，表单的交互是发送到受攻击的站点，而不是恶意站点。这是CSRF的＂跨站点＂部分。 用户单击提交按钮。浏览器在请求中包含身份验证cookie。 该请求运行在具有用户身份验证上下文的服务器上，可以执行经过身份验证的用户允许执行的任何操作。
　　如何防护
　　有许多代码模型可以防止CSRF攻击，并且可以同时应用多个代码模型作为深度安全策略防御的一部分。 开发人员应该要求所有不安全的方法(POST、PUT、DELETE)能够防伪造令牌，并确保安全的方法(GET、HEAD)没有任何副作用。 开发人员应该考虑实现一个同步器令牌模式:
　　在身份验证成功后，在服务器端生成一个随机令牌，并与用户的会话相关联。令牌作为HTML响应的一部分返回给用户(例如，表单中的隐藏字段或通过AJAX检索)。
　　当用户需要执行敏感操作时，令牌就包含在请求中。应用程序验证令牌的正确性，然后仅当请求中的令牌与存储在用户会话中的令牌匹配时，才执行请求的操作。 如果在服务器端维护CSRF令牌的状态有问题，开发人员可以采用双重提交Cookie模式。这是一种容易实现的无状态替代方法，它为cookie和请求参数分配一个随机值，并由服务器验证cookie值和请求值是否匹配: 客户端请求一个包含表单的HTML页面。 服务器在响应中包含两个令牌。一个令牌作为cookie发送。另一个被放置在一个隐藏的表单字段中。令牌是随机生成的，因此攻击者无法猜测值。 当客户端提交表单时，它必须将两个令牌发送回服务器。客户端将cookie令牌作为cookie发送，并在表单数据中发送表单令牌。 如果一个请求不包含这两个令牌，服务器将禁止该请求。 如果存在origin header，开发人员应该验证其值是否与目标origin匹配。与Referer不同的是，Origin头将出现在来自HTTPS URL的HTTP请求中。 如果origin header不存在，开发人员应该验证Referer标头中的主机名是否与目标原点匹配。这种减轻CSRF的方法也通常用于未经身份验证的请求，例如在建立会话状态之前发出的请求，这需要跟踪同步令牌。 重要的是，开发者应该加强基于用户交互的CSRF防御: 重新身份验证(密码或更强) 一次性的令牌 验证码