跨站请求伪造 (CSRF),也称为一键攻击或会话操纵,是一种网络安全漏洞,允许攻击者诱骗用户执行他们不想执行的操作。
这些操作是在用户经过身份验证的 Web 应用程序上执行的,攻击者利用 Web 应用程序信任用户浏览器的事实,浏览器会自动随请求发送会话 cookie 或其他凭据。
此类攻击可能导致严重后果,例如未经授权的资金转移、凭证更改甚至账户接管。
在本文中,我们将探讨 CSRF 的机制、其工作原理、成功的 CSRF 攻击的潜在影响、漏洞示例以及防止 CSRF 的各种方法。
此外,我们将研究现实世界中的 CSRF 攻击实例来说明此漏洞的危险性。
什么是 CSRF?
CSRF 攻击利用了现代 Web 应用程序依赖身份验证机制(例如会话 cookie)来识别用户的事实。
当用户通过身份验证时,浏览器会在对 Web 应用程序的任何后续请求中自动包含会话 cookie。
这就是漏洞所在。攻击者可以构造恶意请求,并在受害者不知情的情况下由其浏览器执行。
由于会话 cookie 是自动包含的,因此 Web 应用程序会处理该请求,就好像该请求是由受害者发出的一样。
主要特点:
-
利用信任:CSRF 利用 Web 应用程序对用户浏览器的信任。
-
无意的操作:受害者在不知情的情况下在 Web 应用程序上执行操作,例如更改帐户详细信息、转账或删除数据。
-
会话管理:这种攻击通常会成功,因为现代浏览器会自动在跨源请求中包含会话 cookie,除非采取了 CSRF 令牌或 SameSite cookie 等缓解措施。
CSRF 的工作原理
要了解 CSRF 的工作原理,必须分解攻击成功所必须满足的条件。根据常见的分解,以下条件使得 CSRF 攻击成为可能:
CSRF攻击的条件:
-
相关操作:必须存在攻击者希望受害者执行的操作。这可能是特权操作(例如修改用户权限)或针对用户特定数据的任何操作(例如更改受害者的密码)。
-
基于 Cookie 的会话处理:Web 应用程序必须依靠 Cookie 进行会话管理,并且浏览器必须在对应用程序的任何请求中自动包含这些 Cookie。
-
没有不可预测的请求参数:攻击者必须能够确定执行请求所需的所有参数。例如,如果更改密码的请求需要当前密码,则除非攻击者知道此密码,否则攻击将失败。
CSRF 攻击剖析
-
构建恶意请求:攻击者创建恶意请求,该请求在执行时将代表受害者行事。这可以使用 HTML 表单、链接甚至图像标签来完成。
例子:
<form action="https://vulnerable-website.com/email/change" method="POST">
<input type="hidden" name="email" value="[email protected]" />
</form>
<script>
document.forms[0].submit();
</script>
-
诱导受害者执行请求:攻击者需要诱骗受害者访问恶意页面或点击恶意链接。例如,攻击者可能会向受害者发送一封包含恶意页面链接的电子邮件,或将恶意请求嵌入受害者可能访问的网页中。
-
受害者的浏览器发送请求:当受害者访问恶意页面时,浏览器会自动向目标 Web 应用程序发送请求,其中包括受害者的会话 cookie。
-
Web 应用程序处理请求:Web 应用程序处理请求,就好像请求是由受害者发出的一样,因为会话 cookie 已自动包含在内。此操作是在受害者不知情的情况下进行的。
CSRF 攻击示例
假设一个 Web 应用程序允许用户使用如下所示的简单 HTTP 请求更改他们的电子邮件地址:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE
[email protected]
攻击者可以制作恶意请求,将受害者的电子邮件地址更改为自己的:
<form action="https://vulnerable-website.com/email/change" method="POST">
<input type="hidden" name="email" value="[email protected]" />
</form>
<script>
document.forms[0].submit();
</script>
当受害者访问带有恶意表单的页面时,他们的浏览器将自动包含会话 cookie,并且易受攻击的 Web 应用程序将更改与受害者帐户关联的电子邮件地址。
CSRF 攻击的影响
CSRF 攻击的影响取决于攻击者可以诱导受害者执行的操作的性质。一些常见的后果包括:
-
账户接管:如果攻击者可以更改受害者的电子邮件地址或重置密码,他们就可以控制受害者的帐户。
-
欺诈交易:在银行或电子商务网站上,CSRF 攻击可能导致未经授权的资金转账或购买。
-
数据操纵:攻击者可以修改个人信息、删除数据或更改用户设置。
-
权限提升:如果受害者具有管理权限,攻击者可以使用 CSRF 来控制整个应用程序或敏感数据。
CSRF 漏洞示例
-
更改用户信息:CSRF 攻击的一个常见示例是更改用户帐户的电子邮件地址或密码。如果 Web 应用程序未正确验证请求的来源,攻击者可以轻松更新受害者的凭据。
-
提交订单或付款:在电子商务网站中,攻击者可以使用 CSRF 代表受害者提交订单或发起付款。
-
修改用户权限:在更复杂的 Web 应用程序中,如果存在 CSRF 漏洞,攻击者可以修改用户角色或权限,从而导致权限提升。
如何预防CSRF
有几种策略可以减轻 CSRF 攻击的风险。这些防御措施旨在确保应用程序能够区分来自用户的合法请求和来自攻击者的恶意请求。
1. CSRF 令牌
针对 CSRF 最有效的防御方法是使用 CSRF 令牌。CSRF 令牌是服务器生成的唯一、秘密且不可预测的值。
此令牌包含在每次表单提交或敏感请求中。服务器会验证令牌以确保请求来自目标用户。
工作原理:
-
服务器生成一个 CSRF 令牌并将其作为隐藏字段包含在 HTML 表单中。
-
提交表单时,服务器会检查令牌是否与服务器上存储的令牌匹配。
-
如果令牌缺失或者不正确,请求将被拒绝。
例子:
<form action="/change-password" method="POST">
<input type="hidden" name="csrf_token" value="unique-token-value" />
<input type="password" name="new_password" />
<button type="submit">Change Password</button>
</form>
2. SameSite Cookies
SameSite cookie 属性是浏览器的一项功能,它限制了 cookie 随请求发送的方式。
通过将 SameSite 属性设置为 Lax 或 Strict,浏览器将仅在来自同一站点的请求中包含 cookie,从而防止 CSRF 攻击。
例子:
设置 Cookie:sessionId=abc123;SameSite=Lax
-
Lax:Cookie 会随顶级导航请求(GET 请求)一起发送,但不随跨站点 POST 请求一起发送。
-
严格:任何跨站点请求(甚至是顶级导航)都不会发送 Cookie。
3. Referer 头验证
一些 Web 应用程序使用 Referer 标头来验证请求的来源。通过检查请求是否来自同一域,服务器可以阻止来自未经授权来源的请求。
但是,这种方法不如 CSRF 令牌可靠,因为 Referer 标头可以被某些代理或浏览器操纵或删除。
4. 双重提交 Cookie
在双重提交 cookie 技术中,服务器生成 CSRF 令牌并将其存储在 cookie 和隐藏表单字段中。
提交表单时,服务器会检查表单中的 token 是否与 cookie 中的 token 匹配。这确保请求是合法的。
5. 验证码
要求用户在执行敏感操作之前完成CAPTCHA可以防止自动 CSRF 攻击。
虽然有效,但这种方法会降低用户体验,并且并非总是最佳解决方案。
现实世界的CSRF攻击
现实世界中一个著名的 CSRF 攻击例子发生在 2007 年,当时 Gmail 被发现容易受到 CSRF 攻击。
攻击者可以利用此漏洞更改用户的电子邮件转发设置,从而拦截电子邮件。
另一个例子包括对社交媒体平台的 CSRF 攻击,攻击者利用该漏洞以受害者的名义发布恶意内容或更改他们的个人资料信息。
跨站请求伪造 (CSRF) 是一种危险的网络漏洞,如果不加以解决,可能会导致严重的后果。
通过诱骗用户提出非预期的请求,攻击者可以接管账户、转移资金或操纵数据。
但是,通过适当的防御措施(如 CSRF 令牌、SameSite cookie 和 referer 验证),Web 开发人员可以保护其应用程序免受此威胁。了解 CSRF 的工作原理并实施最佳实践对于保护用户免受此类攻击至关重要。
— 欢迎关注
原文始发于微信公众号(祺印说信安):网络安全知识:什么是跨站请求伪造?
- 左青龙
- 微信扫一扫
- 右白虎
- 微信扫一扫
评论