webgoat - A5 Cross Site Request Forgeries

（P1） 跨站请求伪造（Cross-site request forgery），缩写为 CSRF（有时发音为“sea-surf”）或 XSRF，是一种恶意利用网站的攻击方式，在这种攻击中，未经授权的命令由网站信任的用户发送。与跨站脚本攻击（XSS）不同，XSS 利用了用户对特定网站的信任，而 CSRF 则是利用了网站对用户浏览器的信任。 跨站请求伪造是一种针对网络浏览器的“混淆代理”（confused deputy）攻击。CSRF 通常具有以下特征： * 它涉及那些依赖用户身份的网站。 * 它利用了网站对该身份的信任。 * 它诱使用户的浏览器向目标网站发送 HTTP 请求。 * 它涉及具有副作用的 HTTP 请求。 用户在其网络浏览器中保存的 cookie 进行认证后，可能会在不知情的情况下向信任该用户的网站发送 HTTP 请求，从而导致不希望发生的操作。 CSRF 攻击滥用的是基本的 web 功能。如果该网站允许操作引起服务器状态变化，如更改受害者的电子邮件地址或密码，或进行购买，攻击者就能利用这些功能。强迫受害者检索数据对攻击者没有帮助，因为响应不会传递给攻击者，而是传递给受害者。因此，CSRF 攻击通常针对会导致状态变化的请求。 接下来，我们将进行一些练习，探讨如何执行 CSRF 请求。 （P2） 使用 GET 请求的 CSRF 攻击 这是一种最简单的 CSRF 攻击。例如，你收到一封包含以下内容的电子邮件： 如果用户仍然登录到 bank.com 的网站，这个简单的 GET 请求将会把资金从一个账户转移到另一个账户。当然，在大多数情况下，网站可能会有多种控制机制来批准请求 （P5） 大多数框架现在默认支持防止CSRF。例如，使用Angular时，一个拦截器会默认从cookie中读取名为XSRF-TOKEN的令牌，并将其设置为HTTP头部X-XSRF-TOKEN。由于只有在您域名上运行的代码才能读取该cookie，后端可以确定HTTP请求来自您的客户端应用程序而不是攻击者。后端服务器会在cookie中设置令牌。这些都是框架来实现的，我们就不深入研究了。 （P6） 但是我只有 JSON API，并且没有启用 CORS，这样的情况下怎么会容易受到 CSRF 攻击呢？ 许多 web 应用程序没有针对 CSRF 实施任何保护措施，它们在某种程度上依赖于仅使用 application/json 作为内容类型来进行保护。从浏览器发送这种内容类型的请求的唯一方式是使用 XHR 请求。在浏览器发送这样的请求之前，会向服务器发起一个预检请求（记住 CSRF 请求是跨域的）。如果预检响应不允许跨域请求，浏览器将不会执行该请求。 简而言之：这并不是对 CSRF 的有效保护。 这种保护不足的一个例子可以在这里找到。事实证明，Navigator.sendBeacon() 被允许发送带有任意内容类型的 POST 请求。 “我认为内容类型限制对那些意外地防止了 CSRF 攻击的网站是有用的。它们本身并非为此设计，但由于仅接受 XML 或 JSON 负载而偶然具备了这种安全性。 话虽如此，依赖这种行为的网站显然应该修复这一点，任何有信誉的渗透测试人员都会指出这一问题。问题在于，这是否应该是浏览器的责任，像保姆一样保护这些脆弱的网站，还是我们应该让这些脆弱的网站成为正义的牺牲品，适者生存。 在我看来，答案介于两者之间，一个好的第一步是记录所有这些网站可能依赖的同源策略漏洞。 但具体到这个问题上，如果它从未得到修复，我不认为这会是世界末日。不过，在当今时代，或许有人能通过 XML RPC 接口发射核导弹，所以也许这真的会导致世界末日。” ——爱德华多·维拉（Eduardo Vela） Firefox 和 Chrome 都修复了这个问题，但这也说明了你应该实施 CSRF 保护，而不是依赖 API 的内容类型。依赖内容类型并不能防止 CSRF 攻击。 （P8） 登录 CSRF 攻击 （P9） CSRF 影响 CSRF 的影响仅限于已登录用户能够执行的操作（如果站点/功能/操作没有得到适当保护）。真正容易受到 CSRF 攻击的领域包括物联网设备和“智能”家电。遗憾的是，许多消费级路由器也被证明容易受到 CSRF 的攻击。 CSRF 解决方案 同站点 Cookie 属性 这是现代浏览器支持的一种新扩展，它限制了 Cookie 的作用范围，使其仅在请求属于“同站点”时才会附加。例如，对于 http://webgoat.org/something 的请求，如果该请求是从 webgoat.org 发起的，则会附加同站点 Cookie。该属性有两种模式：严格模式和宽松模式。严格模式不允许跨站请求，这意味着当你在 github.com 上并且想通过 Facebook 点赞时（并且 Facebook 指定了同站点属性为严格模式），你会被重定向到登录页面，因为浏览器不会为 Facebook 附加 Cookie。 其他保护措施 幸运的是，许多（Web）应用程序框架现在都内置了处理 CSRF 攻击的支持。例如，Spring 和 Tomcat 默认开启了这一功能。只要你不将其关闭（例如在 WebGoat 中关闭了），你应该可以免受 CSRF 攻击。