跨站点请求伪造 (CSRF)，也称为 XSRF、Sea Surf 或 Session Riding，是一种攻击媒介，可诱使 Web 浏览器在用户登录的应用程序中执行不需要的操作。成功的 CSRF 攻击对企业和用户来说都是毁灭性的。它可能导致客户关系受损、未经授权的资金转移、密码更改和数据盗窃——包括会话 cookie 被盗。CSRF 通常使用恶意社会工程进行，例如诱使受害者向服务器发送伪造请求的电子邮件或链接。由于毫无戒心的用户在受到攻击时通过其应用程序进行了身份验证，因此无法区分合法请求和伪造请求。
CSRF 示例
在执行攻击之前，犯罪者通常会研究应用程序，以使伪造的请求看起来尽可能合法。
例如，一个典型的 100 美元银行转账的 GET 请求可能如下所示：
获取 http://netbank.com/transfer.do?acct=PersonB&amount=$100 HTTP/1.1
黑客可以修改此脚本，从而将 100 美元转入他们自己的帐户。现在恶意请求可能看起来像：
获取 http://netbank.com/transfer.do?acct=AttackerA&amount=$100 HTTP/1.1
坏人可以将请求嵌入到看起来无辜的超链接中：
<a href="http://netbank.com/transfer.do?acct=AttackerA&amount=$100">了解更多！</a>
接下来，他可以通过电子邮件将超链接分发给大量银行客户。那些在登录银行账户时点击链接的人将无意中发起 100 美元的转账。请注意，如果银行的网站仅使用 POST 请求，则不可能使用 <a> href 标记构建恶意请求。但是，攻击可以在自动执行嵌入式 JavaScript 的 <form> 标记中进行。
这种形式可能是这样的：
<body onload="document.forms[0].submit()">
<form action="http://netbank.com/transfer.do" method="POST">
<input type="hidden" name="acct" value="攻击者A"/>
<input type="hidden" name="amount" value="$100"/>
<input type="submit" value="查看我的图片！"/>
</表格>
</body>
缓解 CSRF 的方法
存在许多有效的方法来预防和缓解 CSRF 攻击。从用户的角度来看，预防是保护登录凭证和拒绝未经授权的行为者访问应用程序的问题。
最佳实践包括：
- 在不使用时注销 Web 应用程序
- 保护用户名和密码
- 不允许浏览器记住密码
- 避免在登录应用程序时同时浏览
对于 Web 应用程序，存在多种解决方案来阻止恶意流量和防止攻击。最常见的缓解方法之一是为每个会话请求或 ID生成唯一的随机令牌。这些随后由服务器检查和验证。具有重复标记或缺失值的会话请求将被阻止。或者，与其会话 ID 令牌不匹配的请求将被阻止到达应用程序。
双重提交 cookie 是另一种众所周知的阻止 CSRF 的方法。与使用唯一令牌类似，随机令牌被分配给 cookie 和请求参数。然后，服务器在授予对应用程序的访问权限之前验证令牌是否匹配。虽然有效，但如果受保护站点链接到外部 URL，则令牌可以在多个点暴露，包括在浏览器历史记录、HTTP 日志文件、记录 HTTP 请求第一行的网络设备和引荐来源网址标头中。这些潜在的弱点使代币成为一种不完全证明的解决方案。
使用自定义规则防止 CSRF 攻击
CSRF 攻击的高度个性化特性阻碍了通用解决方案的开发。但是，可以采用自定义安全策略来防止可能的 CSRF 场景。IncapRules是 Imperva 云专有的自定义规则引擎，可让客户创建自己的安全策略。这些策略是使用直观的语法生成的，可以即时修改，从而增强我们默认的 Web 应用程序防火墙 配置。
使用 IncapRules，您可以创建一个策略，根据您的 HTTP 引用标头内容过滤对敏感页面和功能的请求。这样做允许从一个简短的安全域列表中执行请求。这种方法完全对抗 CSRF 攻击的社会工程方面。无论内容如何，它都可以防止在安全范围之外执行恶意请求。或者，您可以在“仅警报”模式下运行规则以跟踪可能的利用尝试，或提供验证码以提醒粗心的用户。
文章链接： https://www.mfisp.com/14824.html
文章标题：什么是跨站点请求伪造(CSRF)？
文章版权：梦飞科技所发布的内容，部分为原创文章，转载请注明来源，网络转载文章如有侵权请联系我们！
