精华内容
下载资源
问答
  • 2022-04-27 22:18:15

    1.1 含义

      CSRF(Cross-site Request Forgery,跨站请求伪造),缩写CSRF,也有少数文章称为XSRF,一种利用用户在当前已登录的Web应用程序上执行非本意操作的攻击方法(利用受害者尚未失效的身份认证信息(cookie,会话等),创建恶意伪造的web页面请求,在受害者不知情的情况下向服务器发送请求完成非法操作(转账、改密等))。

      简言之,攻击者间接利用受害者合法身份,以其身份发送恶意请求。

    1.2 漏洞实质

      攻击者通过技术手段欺骗用户的浏览器访问一个曾经认证过的网站,由于带着认证信息被访问的网站认证信息后认为是真正用户操作便执行操作。(简单的身份认证只能保证请求发自某个用户的浏览器,却不能保证请求本身是用户自愿发起。)

    1.3产生原因

    CSRF攻击为何可以实施?

    其根本原因是从站点B.com向站点A.com发起请求,会把A.com的cookie一同发送过去。这是由于多标签浏览器(chrome,firefox等)共享一个进程造成的。

    但是要注意一点,即虽然可以一同把A.com的cookie随请求发送,但并不能在B.com通过javascript获取和操作A.com下的cookie。

    https://blog.csdn.net/SailingLee/article/details/84614073

    1.4攻击过程

           1. 用户C打开浏览器,访问受信任网站A,输入用户名和密码请求登录网站A;

           2.在用户信息通过验证后,网站A产生Cookie信息并返回给浏览器,此时用户登录网站A成功,可以正常发送请求到网站A;

           3. 用户未退出网站A之前,在同一浏览器中,打开一个TAB页访问网站B;

           4. 网站B接收到用户请求后,返回一些攻击性代码,并发出一个请求要求访问第三方站点A;
           5.  浏览器在接收到这些攻击性代码后,根据网站 B 的请求,在用户不知情的情况下携带 Cookie 信息,向网站 A 发出请求。网站 A 并不知道该请求其实是由 B 发起的,所以会根据用户 C Cookie 信息以 C 的权限处理该请求,导致来自网站 B 的恶意代码被执行。 

     1.5攻击实例      CSRF攻击实例


           受害者 Bob 在银行有一笔存款,通过对银行的网站发送请求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可以使 Bob 把 1000000 的存款转到 bob2 的账号下。通常情况下,该请求发送到网站后,服务器会先验证该请求是否来自一个合法的 session,并且该 session 的用户 Bob 已经成功登陆。

            黑客 Mallory 自己在该银行也有账户,他知道上文中的 URL 可以把钱进行转帐操作。Mallory 可以自己发送一个请求给银行:http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。但是这个请求来自 Mallory 而非 Bob,他不能通过安全认证,因此该请求不会起作用。

            这时,Mallory 想到使用 CSRF 的攻击方式,他先自己做一个网站,在网站中放入如下代码: src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”,并且通过广告等诱使 Bob 来访问他的网站。当 Bob 访问该网站时,上述 url 就会从 Bob 的浏览器发向银行,而这个请求会附带 Bob 浏览器中的 cookie 一起发向银行服务器。大多数情况下,该请求会失败,因为他要求 Bob 的认证信息。但是,如果 Bob 当时恰巧刚访问他的银行后不久,他的浏览器与银行网站之间的 session 尚未过期,浏览器的 cookie 之中含有 Bob 的认证信息。这时,悲剧发生了,这个 url 请求就会得到响应,钱将从 Bob 的账号转移到 Mallory 的账号,而 Bob 当时毫不知情。等以后 Bob 发现账户钱少了,即使他去银行查询日志,他也只能发现确实有一个来自于他本人的合法请求转移了资金,没有任何被攻击的痕迹。而 Mallory 则可以拿到钱后逍遥法外。 

    1.6 CSRF漏洞检测:
           检测CSRF漏洞是一项比较繁琐的工作,最简单的方法就是抓取一个正常请求的数据包,去掉Referer字段后再重新提交,如果该提交还有效,那么基本上可以确定存在CSRF漏洞。

           随着对CSRF漏洞研究的不断深入,不断涌现出一些专门针对CSRF漏洞进行检测的工具,如CSRFTester,CSRF Request Builder等。

           以CSRFTester工具为例,CSRF漏洞检测工具的测试原理如下:使用CSRFTester进行测试时,首先需要抓取我们在浏览器中访问过的所有链接以及所有的表单等信息,然后通过在CSRFTester中修改相应的表单等信息,重新提交,这相当于一次伪造客户端请求。如果修改后的测试请求成功被网站服务器接受,则说明存在CSRF漏洞,当然此款工具也可以被用来进行CSRF攻击。

    1.7绕过姿势

    referer-正则绕过

    出现这种问题原因是站点仅验证了referer字段,且referer校验不严格(如dvwa靶场的csrf中级别)

    referer-置空绕过

    移除referer字段便可以成功绕过

     token-仅算法验证绕过

        原因:应用程序不验证CSRF令牌是否绑定到特定账户而仅验证token算法
        绕过:payload中编码一个合法有效的token即可,测试方法:

        1账户A登录网站进入修改密码页面
        2抓包保存token令牌
        3注销账户A,登录账户B
        4转到密码更改页面并拦截请求
        5使用A账户的token令牌代替B账户的

    token-仅长度验证

    原因:应用程序仅验证每次token令牌是否不同,且长度一致
    绕过:可以通过修改令牌的值保持长度相同即可

    token-置空令牌

    原因:应用程序仅在token应用程序不为空的情况下检查token(常见)
    绕过:抓包删除请求中的token令牌即可

    token-仅静态验证

    原因:token令牌由静态和动态两部分组成,程序仅验证了静态部分
    绕过:删除动态部分,仅用静态部分绕过

    token-令牌易构造

    原因:生成的token令牌过于简单有规律可循
    绕过:探究令牌生成的方式,通过构造令牌进行绕过

     1.8防御CSRF攻击:

        referer头校验(服务端校验Referer头是否同域传来以此决定是否响应请求,能抵御99%的攻击)

        Q&A:
        问:Referer不可伪造吗?
        答:Referer是浏览器自动带上的,基于认为浏览器没有漏洞前提下无法伪造。
        问:Referer校验有啥缺点吗?
        答:当今移动端崛起下流行前后端分离,app和web共用一套后端代码,但app不会自动带Referer头,因此app端不好处理

        token校验(CSRF之所以能成功是由于所有的用户验证信息都在cookie中,用户点击链接时保存在浏览器中的cookie会像服务器发送请求,因此黑客在完全不知验证信息情况下间接利用用户的cookie通过安全验证,要想防御CSRF,关键在于请求中放入黑客不能伪造的信息,且该信息不存于cookie中。可以在HTTP请求中以参数的形式加入一个随机产生的token,并在服务器端建立一个拦截器来验证token如果请求中没有token或者token内容不正确则拒绝请求。)

        Q&A
        问:GET和POST请求怎么加入token?
        答:对于GET请求,token附在地址之后;对于POST请求在表单中提交一个隐藏的表单,<input type=“hidden” name=“csrftoken” value=“tokenvalue”>


        问:”token验证方式万无一失吗?“
        答:”现实中一个网站有很多请求,都加入token是很麻烦的,容易存在疏漏,一般在页面加载时通过js遍历dom树对所有a和form标签后加入token,解决大部门请求,但是页面加载生成后的html代码还需要编码时手动添加。第二个是难以保证token本身安全“

        Cookie添加Same-Site属性(限制三方cookie,规避CSRF攻击)

        Same-Site的三个数值:

            Strict(最为严格,完全禁止第三方 Cookie,跨站点时,任何情况下都不会发送 Cookie)

            Lax(规则稍稍放宽,大多数情况也是不发送第三方 Cookie,但是导航到目标网址的 Get 请求除外)

            None(网站可以选择显式关闭SameSite属性,将其设为None。不过,前提是必须同时设置Secure属性(Cookie 只能通过 HTTPS 协议发送),否则无效)

        验证码(敏感操作时候用户提交表单中填写一个随机的字符串,可以完全解决CSRF,缺点是易用性不怎么友好)
     

    https://blog.csdn.net/Aaron_Miller/article/details/106091534?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165106737416782388084398%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=165106737416782388084398&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_ecpm_v1~rank_v31_ecpm-8-106091534.142^v9^pc_search_result_cache,157^v4^new_style&utm_term=csrf&spm=1018.2226.3001.4187

    https://blog.csdn.net/weixin_40482816/article/details/114301717?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165106737416782388084398%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=165106737416782388084398&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_ecpm_v1~rank_v31_ecpm-4-114301717.142^v9^pc_search_result_cache,157^v4^new_style&utm_term=csrf&spm=1018.2226.3001.4187

    更多相关内容
  • Python CSRF漏洞扫描器 描述 CSRFScanner是一种用于扫描网站以查找CSRF漏洞的工具。 这是一个基本工具,不是很人性化,我最初是出于学术目的而开发的。 可以在PDF CSRFScanner_Explications.pdf(以法语编写)中...
  • 2、登录后点击跳转进入有漏洞的网站(这里模拟的是黑客发给受害者的地址) 3、点击跳转后是一个图片 注解:其中src的地址money.php是网站的转账接口 其中name是转给谁,money是转多少钱 一旦目标登录了网站访问了这...
  • CSRF漏洞

    千次阅读 2022-01-09 14:29:06
    文章目录什么是CSRF漏洞CSRF原理CSRF特点CSRF漏洞检测防御CSRF攻击:DVWA实例:security:lowsecurity:mediumsecurity:high总结 什么是CSRF漏洞 CSRF(Cross-site request forgery),也被称为:one click attack/...


    什么是CSRF漏洞

    CSRF(Cross-site request forgery),也被称为:one click attack/session riding,中文名称:跨站请求伪造,缩写为:CSRF/XSRF。
    一般来说,攻击者通过伪造用户的浏览器的请求,向访问一个用户自己曾经认证访问过的网站发送出去,使目标网站接收并误以为是用户的真实操作而去执行命令。常用于盗取账号、转账、发送虚假消息等。攻击者利用网站对请求的验证漏洞而实现这样的攻击行为,网站能够确认请求来源于用户的浏览器,却不能验证请求是否源于用户的真实意愿下的操作行为。

    CSRF原理

    网站是通过cookie来识别用户的,当用户成功进行身份验证之后,浏览器就会得到一个标识其身份的cookie,只要不关闭浏览器或者退出登录,以后访问这个网站就会带上这个cookie。如果这期间浏览器被人控制着请求了这个网站的url,可能就会执行一些用户不想做的行为(简单的行为如修改个人资料,严重的行为****)。这些请求也可以是从第三方网站提交的,即跨站。
    CSRF攻击是攻击者借助受害者的cookie骗取服务器的信任,但是攻击者并不能拿到cookie,也看不到cookie的内容。另外,对于服务器返回的结果,由于浏览器同源策略的限制,攻击者也无法进行解析。因此,攻击者无法从返回结果中得到任何信息,他只能够给服务器发送请求,执行请求中所包含的命令,在服务器端直接改变数据的值,而非窃取服务器数据。所以需要保护的对象是可以直接产生数据改变的服务。

    CSRF特点

    攻击一般发起在第三方网站,而不是被攻击的网站。
    攻击是利用受害者在被攻击网站的登录凭证,冒充受害者提交操作,仅仅是“冒用”,而不是直接窃取数据。
    攻击者预测出被攻击的网站接口的所有参数,成功伪造请求。

    CSRF漏洞检测

    检测CSRF漏洞是一项比较繁琐的工作,最简单的方法就是抓取一个正常请求的数据包,去掉Referer字段后再重新提交,如果该提交还有效,那么基本上可以确定存在CSRF漏洞。
    随着对CSRF漏洞研究的不断深入,不断涌现出一些专门针对CSRF漏洞进行检测的工具,如CSRFTester,CSRF Request Builder等。
    以CSRFTester工具为例,CSRF漏洞检测工具的测试原理如下:使用CSRFTester进行测试时,首先需要抓取我们在浏览器中访问过的所有链接以及所有的表单等信息,然后通过在CSRFTester中修改相应的表单等信息,重新提交,这相当于一次伪造客户端请求。如果修改后的测试请求成功被网站服务器接受,则说明存在CSRF漏洞,当然此款工具也可以被用来进行CSRF攻击。

    防御CSRF攻击:

    1. 验证 HTTP Referer 字段;
    2. 在请求地址中添加 token 并验证;
    3. 在 HTTP 头中自定义属性并验证。

    DVWA实例:

    security:low

    <?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  对用户的反馈
    		$html .= "<pre>Password Changed.</pre>";
    	}
    	else {
    		// Issue with passwords matching
    		$html .= "<pre>Passwords did not match.</pre>";
    	}
    
    	((is_null($___mysqli_res = mysqli_close($GLOBALS["___mysqli_ston"]))) ? false : $___mysqli_res);
    }
    
    ?>
    

    GLOBALS :引用全局作用域中可用的全部变量。$GLOBALS 这种全局变量用于在 PHP 脚本中的任意位置访问全局变量(从函数或方法中均可)。PHP 在名为 $GLOBALS[index] 的数组中存储了所有全局变量。变量的名字就是数组的键。
    从源代码可以看出这里只是对用户输入的两个密码进行判断,看是否相等。不相等就提示密码不匹配
    相等的话,查看有没有设置数据库连接的全局变量和其是否为一个对象。如果是的话,用mysqli_real_escape_string()函数去转义一些字符,如果不是的话输出错误。是同一个对象的话,再用md5进行加密,再更新数据库。
    现在知道的大概就是折磨多?!
    在这里插入图片描述
    我们按照要求输入一下密码:这里输入的是123,123.
    在这里插入图片描述
    密码修改成功,现在我们要对验证一下是否真的改变。
    在这里插入图片描述
    欧克,这时我们注意一下我们的url:http://localhost/dvwa/vulnerabilities/csrf/?password_new=123&password_conf=123&Change=Change#
    我们发现这个是不是我们改变密码的链接对吧?!
    但是我们可以看到这个链接一看就是想把你的密码改变,你还会按照他的来操作吗?
    这肯定是不可以的。所以我们简单制作一个页面就是来迷惑受害人。
    在这里插入图片描述

    密码改成了234.
    现在我们进行点击访问这个页面。
    在这里插入图片描述
    对的。
    在这里插入图片描述
    攻击成功。

    security:medium

    <?php
    
    if( isset( $_GET[ 'Change' ] ) ) {
        // Checks to see where the request came from
        if( stripos( $_SERVER[ 'HTTP_REFERER' ] ,$_SERVER[ 'SERVER_NAME' ]) !== false ) {
            // 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>";
            }
        }
        else {
            // Didn't come from a trusted source
            echo "<pre>That request didn't look correct.</pre>";
        }
    
        ((is_null($___mysqli_res = mysqli_close($GLOBALS["___mysqli_ston"]))) ? false : $___mysqli_res);
    }
    
    ?> 
    

    主要是加上一个对用户请求头的中的Referer字段进行验证。它主要是在你的refere里面需要包含你服务器中的名字。

     if( stripos( $_SERVER[ 'HTTP_REFERER' ] ,$_SERVER[ 'SERVER_NAME' ]) !== false )
    

    下面我们对其这个攻击的页面进行抓包。
    在这里插入图片描述
    password_new=hack和password_conf=hack,这个就是对其中的密码进行修改。
    并且在refere后面加上:localhost.html或者直接是http://localhost.html.
    过滤规则是http包头的Referer参数的值中必须包含主机.我们可以将攻击页面命名为localhost.html。
    在这里插入图片描述

    放包。
    在这里插入图片描述
    攻击成功。

    security:high

    <?php
    
    if( isset( $_GET[ 'Change' ] ) ) {
        // Check Anti-CSRF token
        checkToken( $_REQUEST[ 'user_token' ], $_SESSION[ 'session_token' ], 'index.php' );
    
        // 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);
    }
    
    // Generate Anti-CSRF token
    generateSessionToken();
    
    ?> 
    

    总结

    这里总结一下吧,CSRF主要是你把一个恶意的链接发给别人,利用他电脑上的信息,在你构造的url链接里修改信息,把对方的密码改变。,或者你构造一个网页在服务其中别人利用这个服务器中的链接,当你点进去的时候密码就已经被盗。
    security:high还没有理解透。待续。。。

    盛年不重来,一日难再晨。及时宜自勉,岁月不待人。——陶渊明

    展开全文
  • CSRF 漏洞

    2022-03-26 00:43:48
    CSRF 漏洞

    目录

    一、简介与原理

    二、简单攻击方式 

    通过 GET 方式实现CSRF攻击

    通过 POST 请求实现CSRF攻击

    三、与 XSS 以及 SSRF 的区别

    四、相关检测方法

    五、相关预防与修复方案

    用户侧

    开发侧


    一、简介与原理

            CSRF(Cross-Site Request Forgery)跨站请求伪造,也被称为“One Click Attack”、“Session Riding”。攻击者在用户浏览网页时,利用页面元素,在用户不知情的情况下,利用受害者的浏览器向 Web 应用服务器强迫发送伪造的 HTTP 请求达到获取或更改用户信息的行为。CSRF 攻击可以从站外和站内发起;

            其攻击普遍结合社会工程学,且攻击场景需要满足以下条件:

    1) 用户完成身份认证;

    2) 新请求不需要重新身份认证或确认机制(攻击建立在浏览器与WEB服务器的会话中);

    3) 攻击者可以正确的构造请求参数内容;

    4) 诱使用户触发攻击指令(欺骗用户访问 URL);


             CSRF 常见攻击流程如下图:


    二、简单攻击方式 

    通过 GET 方式实现CSRF攻击

            首先 Victim 登录 csrf_victim.com,然后 Victim 访问 CSRF_attacker.com 时,就对 csrf_victim.com 这个网站发起了一次 HTTP 请求,并更改了 Victim 的密码为 CSRF_Confirm

    # CSRF_attacker.com 中存在如下代码
    
    <img src="http://www.csrf_victim.com?userId=victim&password=CSRF_Confirm&Change=Change">

    通过 POST 请求实现CSRF攻击

            Victim 访问 CSRF_attacker.com 触发 CSRF

    <form name="csrf" action="http://www.csrf_victim.com" method="POST">
        <input type="hidden" name="userId" value="victim" />
        <input type="hidden" name="password" value="CSRF_Confirm" />
        <input type="hidden" name="change" value="change" />
    </form>
    
    <script>document.csrf.submit();</script>

    三、与 XSS 以及 SSRF 的区别

            XSS(Cross Site Scripting)跨站脚本攻击 利用用户对站点的信任,用户提交的数据中可以构造代码来执行,从而实现窃取用户信息等行为的攻击手段;

            CSRF(Cross-Site Request Forgery)跨站请求伪造,XSS 是实现 CSRF 攻击的一种方式,CSRF 利用站点对经过身份认证的用户的信任,客户端没有在用户进行关键操作时进行授权确认;

            SSRF(Server-Side Request Forgery)服务端请求伪造 诱使服务端应用程序向攻击者选择的域发出 HTTP 请求;


    四、相关检测与识别方法

    手动测试步骤如下:

    1)抓包记录正常的 HTTP 请求;

    2)分析 HTTP 请求参数是否可预测,分析对应的参数功能;

    3)去掉或更改 Referer 为第三方站点,然后重放请求;

    4)判断是否达到与正常请求的同等效果,若正常,则可能存在 CSRF 漏洞;反之则不存在;


    半手动测试BurpSuite 抓包,使用 Generate CSRF-PoC 生成测试


     自动测试软件下载https://github.com/aur-archive/csrftester


    五、相关预防与修复方案

    用户侧

    1)重要网站访问后要安全退出;

    2)不随意点击各类链接和弹窗;

    3)定期清理浏览器中缓存的 Cookie 信息;


    开发侧

    1)增加 Token 验证,并保证随机性。在 Session 中绑定 Token,如果不能保存到服务端,则替代保存到 Cookie 中;

            生成随机 Token 的代码如下:

    # 生成 Token
    session_start();
    function set_token(){
        $_SESSION['token'] = md5(time()+rand(1,9999));
    }

            验证 Token 的代码如下:

    # 使用 Token 做验证
    function check_token(){
        if(isset($_POST['token'])&&$_POST['token'] === $_SESSION['token']){
            return ture;
        }else{
            return false;
        }
    }

            或是在 form 表单中自动填入 Token 字段;

    <input type="hidden" name="anti_csrf_token" value="$token" />

            亦或是在 HTTP 请求中自动添加 Token ,在服务器中对比 POST 提交的 Token 参数与 Session 中绑定的 Token 是否一致;

    2)设置安全的会话管理,不在客户端保存敏感信息。并且设置会话过期机制,如:当前页面10分钟无操作则自动登录超时,在关闭和退出页面时会话自动失效;

    3)同源策略,通过在 HTTP 头字段中的 Referer 来限制页面来源,要求页面请求必须来源于同一个网页站点 (但是此方式无法站内发起的 CSRF 攻击以及 Referer 字段伪造);

    4)在重要的功能点上增加动态验证码(在一定程度上影响用户体验);

    展开全文
  • CSRF漏洞详解 一文了解CSRF漏洞

    千次阅读 2020-11-11 13:50:09
    本篇总结归纳CSRF漏洞

    前言

    本篇总结归纳CSRF漏洞

    1、什么是CSRF

    跨站请求伪造(Cross Site Request Forgery,CSRF)

    • 目标用户使用其用户名和密码登录受信任站点,从而创建了一个新的会话,受信任站点则会为目标用户Web浏览器Cookie中的会话信息存储了会话标示符
    • 测试者往Web应用页面中插入恶意的HTML链接或脚本代码,而目标页面又没有过滤或者过滤不严,那么当用户浏览该页面时,用户的Web浏览器将被操纵向受信任站点发送一个恶意请求,比如删除帖子、添加管理员、添加邮件转发规则、改变路由器的DNS设置等。
    • Web浏览器将会为这个恶意请求自动附加会话Cookie信息,因为是访问的受信任站点,因此该恶意请求将会成功完成。

    与XSS相比

    • XSS:利用用户对站点的信任,攻击者通过注入程序来修改网站来使用户浏览器被重定向等
    • CSRF:利用站点对已经身份认证的用户的信任,攻击者伪造一个链接误导用户点击链接来使用用户的身份认证来访问服务器

    2、攻击原理

    成因就是网站的cookie在浏览器中不会过期,只要不关闭浏览器或者退出登录,那以后只要是访问这个网站,都会默认你已经登录的状态
    而在这个期间,攻击者发送了构造好的csrf脚本或包含csrf脚本的链接,可能会执行一些用户不想做的功能

    过程如下

    • 用户C打开浏览器,访问受信任网站A,输入用户名和密码请求登录网站A
    • 在用户信息通过验证后,网站A产生Cookie信息并返回给浏览器,此时用户登录网站A成功,可以正常发送请求到网站A
    • 用户未退出网站A之前,在同一浏览器中,打开一个TAB页访问网站B
    • 网站B接收到用户请求后,返回一些攻击性代码,并发出一个请求要求访问第三方站点A
    • 浏览器在接收到这些攻击性代码后,根据网站B的请求,在用户不知情的情况下携带Cookie信息,向网站A发出请求。网站A并不知道该请求其实是由B发起的,所以会根据用户C的Cookie信息以C的权限处理该请求,导致来自网站B的恶意代码被执行。

    在这里插入图片描述

    3、几种攻击类型

    (1)GET类型的CSRF

    GET类型的CSRF利用非常简单,只需要一个HTTP请求
    这种类型的CSRF一般是由于程序员安全意识不强造成的
    一般会这样利用:

    <img src=http://wooyun.org/csrf?xx=11 /> 
    

    在访问含有这个img的页面后,成功向http://wooyun.org/csrf?xx=11 发出了一次HTTP请求
    所以,如果将该网址替换为存在GET型CSRF的地址,就能完成攻击了

    (2)POST类型的CSRF

    这种类型的CSRF危害没有GET型的大,利用起来通常使用的是一个自动提交的表单,如:

    <form action=http://wooyun.org/csrf.php method=POST>
    <input type="text" name="xx" value="11" />
    </form>
    <script> document.forms[0].submit(); </script> 
    

    访问该页面后,表单会自动提交,相当于模拟用户完成了一次POST操作

    (3)过基础认证的CSRF(常用于路由器)

    POC:

    <img src=http://admin:admin@192.168.1.1 /> 
    

    加载该图片后,路由器会给用户一个合法的SESSION,就可以进行下一步操作了

    (4)未进行token校验

    没有csrf-token的校验是最经典的CSRF漏洞高发处
    但是这种漏洞只有在一些高风险的位置才有价值,比如csdn上关注/取关,发表博文等等一些操作
    而在淘宝中如查看某一商品、执行某一模糊查询,这样的都属于无价值的被默认许可的csrf

    (5)FLASH CSRF

    参考低调的Flash CSRF攻击

    (6)Json劫持

    参考谈谈Json格式下的CSRF攻击

    如果服务端没有校验Content-Type,或者没有严格校验Content-Type是否为application/json
    我们可以使用XHR来实现csrf

    poc如下:

    <html>
     <head>
     <script style="text/javascript">
          function submitRequest()
          {
            var xhr = new XMLHttpRequest();
            xhr.open("POST", "http://victim.com/carrieradmin/admin/priceSheet/priceSheet/savePriceSheet.do", true);
            xhr.setRequestHeader("Accept", "application/json, text/plain, */*");
            xhr.setRequestHeader("Accept-Language", "zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3");
            xhr.setRequestHeader("Content-Type", "application/json; charset=utf-8");
            xhr.withCredentials = true;
            xhr.send(JSON.stringify({"serialNumber":"CYS1811291899","type":2,"temp":1,"enableTime":"2018-11-01 00:00:00","disableTime":"2018-11-29 12:00:00","name":"1","supplierCode":"","province":"天津市","city":"天津市","region":"和q区","remark":"","fromType":2,"chargeDetailList":[{"province":"山西省","city":"晋城市","region":"陵川县","price42":"1","price65":"1","price71":"1","price76":"1","priceA":"11","priceB":"","priceC":"1","times":"1","unloadPrice":"1"}]}));
        }
       </script>
     </head>
      <body>
        
        <form action="#">
          <input type="button" value="Submit request" onClick="submitRequest()"/>
        </form>
      </body>
      
    </html>
    

    使用XMLHttpRequest、fetch能构造出JSON请求,并且能设置Content-Type,但是无法跨域

    fetch发起的请求代码:

    <html>
    <title>JSON CSRF POC</title>
    <script>
        fetch('http://victim.com/vul.page', {method: 'POST', credentials: 'include', headers: {'Content-Type': 'text/plain'}, body: '{"name":"attacker","email":"attacker.com"}'});
    </script>
     
    </form>
    </html>
    

    4、CSRF的检测

    最简单的方法就是抓取一个正常请求的数据包,去掉Referer字段后再重新提交,如果该提交还有效,那么基本上可以确定存在CSRF漏洞

    网站可能存在CSRF漏洞的位置:

    • 订阅处
    • 评论处
    • 管理员添加处
    • 密码修改处
    • 资料修改处
    • 删除用户或者信息处

    随着对CSRF漏洞研究的不断深入,不断涌现出一些专门针对CSRF漏洞进行检测的工具,如CSRFTester,CSRF Request Builder
    github上有个工具autoFindXssAndCsrf

    5、CSRF的防御

    (1)验证 HTTP Referer 字段

    根据 HTTP 协议,在 HTTP 头中有一个字段叫 Referer,它记录了该 HTTP 请求的来源地址
    在通常情况下,访问一个安全受限页面的请求来自于同一个网站,比如需要访问 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory,用户必须先登陆 bank.example,然后通过点击页面上的按钮来触发转账事件
    因此,要防御 CSRF 攻击,网站只需要对于每一个转账请求验证其 Referer 值,如果是以 bank.example 开头的域名,则说明该请求是来自银行网站自己的请求,是合法的。如果 Referer 是其他网站的话,则有可能是黑客的 CSRF 攻击,拒绝该请求。

    这种方法的显而易见的好处就是简单易行,网站的普通开发人员不需要操心 CSRF 的漏洞,只需要在最后给所有安全敏感的请求统一增加一个拦截器来检查 Referer 的值就可以。

    然而,这种方法并非万无一失。Referer 的值是由浏览器提供的,虽然 HTTP 协议上有明确的要求,但是每个浏览器对于 Referer 的具体实现可能有差别,并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法,就是把安全性都依赖于第三方(即浏览器)来保障,从理论上来讲,这样并不安全。事实上,对于某些浏览器,比如IE6 或 FF2,目前已经有一些方法可以篡改 Referer 值。如果 网站支持IE6 浏览器,黑客完全可以把用户浏览器的 Referer 值设为以 bank.example 域名开头的地址,这样就可以通过验证,从而进行 CSRF 攻击。

    即便是使用最新的浏览器,黑客无法篡改 Referer 值,这种方法仍然有问题。因为 Referer 值会记录下用户的访问来源,有些用户认为这样会侵犯到他们自己的隐私权,特别是有些组织担心 Referer 值会把组织内网中的某些信息泄露到外网中。因此,用户自己可以设置浏览器使其在发送请求时不再提供 Referer。当他们正常访问银行网站时,网站会因为请求没有 Referer 值而认为是 CSRF 攻击,拒绝合法用户的访问。

    (2)在请求地址中添加 token 并验证

    CSRF 攻击之所以能够成功,是因为黑客可以完全伪造用户的请求,该请求中所有的用户验证信息都是存在于 cookie 中,因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证。要抵御 CSRF,关键在于在请求中放入黑客所不能伪造的信息,并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token,并在服务器端建立一个拦截器来验证这个 token,如果请求中没有 token 或者 token 内容不正确,则认为可能是 CSRF 攻击而拒绝该请求。

    这种方法要比检查 Referer 要安全一些,token 可以在用户登陆后产生并放于 session 之中,然后在每次请求时把 token 从 session 中拿出,与请求中的 token 进行比对,但这种方法的难点在于如何把 token 以参数的形式加入请求。对于 GET 请求,token 将附在请求地址之后,这样 URL 就变成 http://url?csrftoken=tokenvalue。 而对于 POST 请求来说,要在 form 的最后加上 <input type=”hidden” name=”csrftoken” value=”tokenvalue”/>,这样就把 token 以参数的形式加入请求了。但是,在一个网站中,可以接受请求的地方非常多,要对于每一个请求都加上 token 是很麻烦的,并且很容易漏掉,通常使用的方法就是在每次页面加载时,使用 javascript 遍历整个 dom 树,对于 dom 中所有的 a 和 form 标签后加入 token。这样可以解决大部分的请求,但是对于在页面加载之后动态生成的 html 代码,这种方法就没有作用,还需要程序员在编码时手动添加 token。

    该方法还有一个缺点是难以保证 token 本身的安全。特别是在一些论坛之类支持用户自己发表内容的网站,黑客可以在上面发布自己个人网站的地址。由于系统也会在这个地址后面加上 token,黑客可以在自己的网站上得到这个 token,并马上就可以发动 CSRF 攻击。为了避免这一点,系统可以在添加 token 的时候增加一个判断,如果这个链接是链到自己本站的,就在后面添加 token,如果是通向外网则不加。不过,即使这个 csrftoken 不以参数的形式附加在请求之中,黑客的网站也同样可以通过 Referer 来得到这个 token 值以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的原因。

    (3)在 HTTP 头中自定义属性并验证

    这种方法也是使用 token 并进行验证,和上一种方法不同的是,这里并不是把 token 以参数的形式置于 HTTP 请求之中,而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类,可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性,并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便,同时,通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏,也不用担心 token 会透过 Referer 泄露到其他网站中去。

    然而这种方法的局限性非常大。XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新,并非所有的请求都适合用这个类来发起,而且通过该类请求得到的页面不能被浏览器所记录下,从而进行前进,后退,刷新,收藏等操作,给用户带来不便。另外,对于没有进行 CSRF 防护的遗留系统来说,要采用这种方法来进行防护,要把所有请求都改为 XMLHttpRequest 请求,这样几乎是要重写整个网站,这代价无疑是不能接受的。

    (4)二次验证

    业务上也可以做防御

    在调用某些功能时进行二次验证
    如删除用户时,弹出“确认删除用户吗”

    还有验证码也可以

    结语

    对CSRF做了个归纳

    展开全文
  • CSRF漏洞详细解读

    多人点赞 热门讨论 2022-05-13 14:25:09
    什么是CSRF2.CSRF漏洞危害二 CSRF的三种漏洞1.GET类型CSRF2.POST类型CSRF3.Token类型CSRF三 靶场演示四 CSRF漏洞修复方法修复方案(1)验证http referer字段(2).在请求地址中添加token并验证(3)在http头中⾃定义...
  • 主要涉及CSRF漏洞挖掘技巧,最新版csrf漏洞通用POC生成方法,CSRF漏洞修复方法,在页面没有设置token或者TOKEN可以被破解时挖掘csrf,然后通过POC进行验证,本文仅限于CSRF漏洞挖掘等学习
  • CSRF漏洞详解

    千次阅读 2022-02-22 21:17:34
    文章目录注意什么是CSRFCSRF的成因CSRF的危害...浏览器CORS【跨站资源共享】的问题,不同的网站发送JS请求浏览器会主动拦截删除Cookie,所以这种漏洞偏少。 什么是CSRF CSRF(Cross-site request forgery)跨站请求伪
  • hucart-含有CSRF漏洞的源码,亲测真实有效可用,如有侵权,请联系CSDN管理员删除
  • CSRF漏洞详细说明

    2021-02-26 07:38:40
    经常入选owasp漏洞列表Top10,在当前web漏洞排行中,与XSS和SQL注入并列前三。与前两者相比,CSRF相对来说受到的关注要小很多,但是危害却非常大。通常情况下,有三种方法被广泛用来防御CSRF攻击:验证token,验证...
  • CSRF漏洞原理攻击与防御(非常细)

    千次阅读 2022-04-01 23:27:14
    CSRF漏洞原理攻击与防御 目录CSRF漏洞原理攻击与防御一、什么是CSRF?二、CSRF攻击原理及过程三、CSRF分类1. GET类型的CSRF2. POST类型的CSRF四、CSRF漏洞的挖掘五、CSRF漏洞的防御1、验证码2、在请求地址中添加 ...
  • CSRF漏洞原理与防御方式

    千次阅读 2021-09-15 16:11:29
    CSRF漏洞原理 CSRF被叫做跨站请求伪造,该怎么理解这句话呢,比如 用户a在浏览器登录了账号,当他发送登录请求时候,服务器验证了账号密码,会返回给一个身份信息存放在cookie里面,浏览器保存,那么以后用户访问...
  • csrf漏洞的原理是?如何防御和利用csrf漏洞。 当我们打开或登录某个网站后,浏览器与网站所存放的服务器将会产生一个会话,在会话结束前,用户就可以利用具有的网站权限对网站进行操作(如:发表文章、发送邮件、...
  • Pikachu靶场之XSS漏洞详解前言漏洞简述CSRF是什么CSRF攻击原理CSRF攻击防护如何确认一个web系统存在CSRF漏洞第1关 CSRF(get)第2关 CSRF(post)第三关 CSRF Tokentoken验证原理其他防范措施 前言 本篇文章用于巩固对...
  • 尽管听起来像跨站脚本(XSS),但它与XSS非常不同,XSS利用站点内的信任用户,而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比,CSRF攻击往往不大流行(因此对其进行防范.
  • CSRF 漏洞原理详解及防御方法

    千次阅读 2021-01-14 17:13:22
    黑盒挖掘:先搭建好环境,打开几个非静态页面,抓包看有没有token,如果没有,再直接请求这个页面,不带referer,如果返回数据还是一样的,那说明很有可能存在CSRF漏洞, 白盒挖掘:读取代码的核心文件,查看里边有...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 19,853
精华内容 7,941
关键字:

csrf漏洞

友情链接: 第12章.rar