跨站点请求伪造 (CSRF/XSRF)，也称为 Sea Surf 或 Session Riding，是一种网络安全漏洞，可诱使网络浏览器执行不需要的操作。因此，攻击者滥用 Web 应用程序对受害者浏览器的信任。它允许攻击者部分绕过同源策略，该策略旨在防止不同网站相互干扰。
这是有关应用程序安全性的一系列广泛指南的一部分
CSRF 攻击的影响是什么？
当一个网站代表用户向另一个网站发送数据请求以及用户的会话 cookie 时，攻击者可以发起跨站点请求伪造攻击，这会滥用受害者浏览器和网络服务器之间的信任关系。
在某些情况下，根据操作的类型，攻击者可以完全控制用户的帐户。如果受感染的用户在应用程序中具有特权角色，攻击者可能能够完全控制应用程序的所有功能和数据，这对企业和用户来说都是毁灭性的。结果可能是数据被盗、未经授权的资金转移、客户关系受损、密码更改等等。
跨站点请求伪造如何工作？
当用户尝试访问站点时，浏览器通常会自动在请求中包含凭据，以使登录过程更加方便。这些凭据可能包括用户的会话 cookie、基本身份验证凭据、IP 地址和 Windows 域凭据。
这种机制固有的风险是攻击者可以很容易地冒充用户。一旦用户通过了站点的身份验证，站点就无法区分伪造请求和合法用户请求。
在 CSRF 攻击中，攻击者冒用受害者的身份，并在未经用户同意的情况下使用它代表用户执行操作。攻击者通常遵循以下流程：
- 他们使用社会工程技术说服受害者通过电子邮件、聊天消息或类似的交流方式点击链接。
- 恶意链接本身或用户访问的网页都会触发对目标站点的请求
- 该请求据称来自用户，并利用了用户已经登录网站这一事实。
- 该网站在用户不知情或不同意的情况下承认该请求并执行攻击者请求的操作。
CSRF 攻击通常会尝试更改服务器状态，但也可用于访问敏感数据。如果攻击者成功对受害者的账户进行 CSRF 攻击，他们可以转移资金、购买产品、修改账户信息（如送货地址）、修改密码或用户登录时可用的任何其他操作。
CSRF 攻击示例
以下示例显示了 5,000 美元银行转帐的典型 GET 请求可能如下所示：
GET https://abank.com/transfer.do?account=RandPerson&amount=$5000 HTTP/1.1
攻击者可以修改脚本，从而将 5,000 美元转入他们的个人账户。恶意请求可能如下所示：
GET https://abank.com/transfer.do?account=SomeAttacker&amount=$5000 HTTP/1.1
之后，攻击者能够将请求嵌入到看起来无害的超链接中：
<a href="https://abank.com/transfer.do?account=SomeAttacker&amount=$5000">Click for more information</a>
下一步是通过电子邮件将超链接分发给大量银行客户。那些登录到他们的银行账户并点击此链接的人会无意中发起 5,000 美元的转账。
如果银行的网站仅使用 POST 请求，则无法使用 <a> href 标记来构建恶意请求。但是，攻击可以在 <form> 标记中传递。
这是这样一个表单的外观，它甚至可以是一个自我提交的表单：
<body onload="document.forms[0].submit()>
<form id=”csrf” action="https://abank.com/transfer.do" method="POST">
<input type="hidden" name="account" value="SomeAttacker"/>
<input type="hidden" name="amount" value="$5000"/>
</form>
</body>
因为上面的表单没有提交按钮，它会在用户不知情和同意的情况下被触发。相反，该按钮仅由一行 javascript 替换：
document.getElementById('csrf').submit();
什么是 CSRF 代币？
CSRF 令牌是由服务器端应用程序生成的唯一的、不可预测的秘密值，并发送到客户端以包含在客户端发出的后续 HTTP 请求中。颁发令牌后，当客户端发出请求时，服务器会检查请求是否包含预期的令牌，如果令牌丢失或无效，则拒绝它。
CSRF 令牌可以防止 CSRF 攻击，因为它们可以防止攻击者形成完全有效的 HTTP 请求，这些请求可以提供给受害者。攻击者无法确定或预测用户 CSRF 令牌的价值，因此他们生成的任何请求都不应该被应用程序接受。
常见的 CSRF 漏洞：CSRF 令牌实现中的弱点
一些最常见的 CSRF 漏洞是由 CSRF 令牌验证过程中的错误引起的。确保您的 CSRF 流程没有任何这些弱点。
验证取决于令牌的存在
在某些应用程序中，如果令牌不存在，则会跳过验证过程。这意味着攻击者只需要找到包含令牌信息的代码并将其删除，应用程序不会执行令牌验证。
CSRF 令牌与用户会话无关
一些应用程序维护一个令牌池，只要使用池中的令牌，它就会被接受。但是，该应用程序不会将特定令牌绑定到特定用户。攻击者只需要从池中获得至少一个令牌，就可以用它来冒充任何用户。
使用 HTTP 方法更改令牌验证
在某些应用程序中，使用 GET 方法而不是 POST 方法会导致 CSRF 验证无法正常工作。攻击者只需从 POST 切换到 GET，即可轻松绕过验证过程。
CSRF 令牌被复制到 cookie
某些应用程序不会记录已在使用的令牌。相反，他们将与每个令牌关联的请求参数复制到用户的 cookie 中。在此设置中，攻击者可以使用应用程序的预期格式创建一个包含令牌的 cookie，将其放置在用户的浏览器中，然后执行 CSRF 攻击。用户浏览器发送的请求会被验证，因为它会匹配攻击者提供的恶意cookie。
CSRF 预防：超越 CSRF 令牌
防止 CSRF 的基本方法是实现 CSRF 令牌，同时避免我们在上一节中描述的弱点。以下是防止 CSRF 攻击的其他方法。
使用高级验证技术来减少 CSRF
当表单中使用的所有参数都被识别时，攻击者可以发起 CSRF 攻击。因此，为了防止 CSRF 攻击，您可以添加一个附加参数，该参数具有攻击者不知道的附加值，但服务器需要验证。
最广泛使用的 CSRF 攻击预防技术被称为反 CSRF 令牌或同步器令牌。当用户通过提交表单发出一些经过身份验证的请求时，该请求中应包含一个随机令牌。然后网站将在处理发送的请求之前验证此令牌的出现，如果令牌丢失或值不正确，则请求将被拒绝，攻击者将无法发起 CSRF 攻击。
SameSite Cookie 属性
RFC 6265 bisSameSite中定义的cookie 属性试图减轻 CSRF 攻击。该属性告诉浏览器何时可以发送带有跨站点请求的 cookie。cookie 属性带有三个可能的值—— 、或。 大多数移动浏览器和所有桌面浏览器都支持此属性。SameSiteStrict LaxNone
该Strict 值可以告诉浏览器在跨站点浏览会话期间不要向站点发送 cookie。这包括遵循常规链接的会话。例如，当用户登录 GitHub 并浏览公司托管的私有 GitHub 项目时，浏览器不会向 GitHub 发送会话 cookie，从而限制了对项目的访问。
如果不需要允许外部网站链接到交易页面，您可以使用Strict flag。但是，如果您需要在可用性和安全性之间建立平衡，使由外部链接引导的用户能够保持登录会话 - 您应该使用默认Lax 值。通常，在 Lax 模式下授予的跨站点请求被认为是安全的HTTP 方法。
以下是使用 SameSite cookie 属性的两个 cookie 示例：
Set-Cookie: JSESSIONID=xxxxx; SameSite=Strict
Set-Cookie: JSESSIONID=xxxxx; SameSite=Lax
基于用户交互的 CSRF 防御
通常，需要用户干预的防御机制会对用户体验产生负面影响。但是，在某些情况下，例如金融交易，实施这种技术是合适的并且是必需的。例如，您可以添加验证码，这有助于验证它确实是人类用户而不是机器人。
一次性令牌还可以确保它是用户而不是使用登录会话的攻击者。令牌通常发送到用户的电子邮件地址或电话号码，并使用用户之前提供的信息进行验证。此外，您可以引入重新身份验证，这有助于区分 CSRF 会话和真实用户。
登录 CSRF
许多开发人员忽略了应用程序登录表单中的 CSRF 漏洞。这是因为在这个阶段用户还没有被认证，所以开发者假设没有 CSRF 的风险。然而，这个假设并不总是正确的。攻击者可以执行登录 CSRF 攻击，这可能会根据应用程序产生不同的影响。
登录 CSRF 攻击可以通过创建预会话（在用户身份验证之前启动会话）并在登录表单中请求令牌来缓解。
如果您不能信任子域（例如，如果您允许您的用户定义自己的子域），则很难缓解登录 CSRF。在这些情况下，您可以使用严格的子域和路径级别的引用标头验证来降低登录表单的 CSRF 风险。
定期进行 Web 应用程序安全测试以识别 CSRF
即使成功解决了具有 CSRF 攻击的 Web 应用程序中的漏洞，应用程序更新和代码更改也可能在未来将您的应用程序暴露给 CSRF。Web 应用程序安全测试可帮助您持续扫描和测试 Web 应用程序中的潜在安全漏洞，包括 CSRF 漏洞。
Bright 有助于在开发过程的早期跨 Web 应用程序和 API 自动检测和修复许多漏洞，包括 CSRF。
通过将 DAST 扫描左移并将它们集成到 SDLC 中，开发人员和应用程序安全专业人员可以及早发现漏洞，并在它们出现在生产环境之前进行修复。Bright 通过自动验证每个漏洞，在几分钟内完成扫描并实现零误报。这允许开发人员采用该解决方案并在整个开发生命周期中使用它。
扫描任何 Web 应用程序或 REST、SOAP 和 GraphQL API 以防止 CSRF 漏洞：免费试用 Bright
请参阅我们关于关键应用程序安全性的附加指南主题
与我们的内容合作伙伴一起，我们编写了有关其他几个主题的深入指南，这些指南在您探索应用程序安全世界时也很有用。
安全测试
了解现代应用程序和微服务的安全测试技术和最佳实践。
跨站脚本
了解允许黑客将恶意代码注入访问者浏览器的跨站脚本 (XSS) 攻击。
CSRF
了解跨站点请求伪造 (CSRF) 攻击，该攻击劫持经过身份验证的连接以执行未经授权的操作。
XXE
了解利用 Web 应用程序 XML 解析器中的漏洞的 XML 外部实体 (XXE) 攻击。
LFI
了解允许黑客在远程服务器上运行恶意代码的本地文件注入 (LFI) 攻击。
API 安全
了解如何保护应用程序编程接口 (API) 及其敏感数据免受网络威胁。
网站安全
了解如何保护关键网站和 Web 应用程序免受网络威胁。
817
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
