程序猿必读-防范CSRF跨站请求伪造

最新推荐文章于 2024-10-05 11:16:54 发布
最新推荐文章于 2024-10-05 11:16:54 发布
阅读量1.3k 收藏
点赞数
文章标签： csrf 安全漏洞 应用
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_34341290/article/details/70208941
版权
本文介绍了CSRF（跨站请求伪造）攻击的概念、危害及防范措施。重点讲解了如何通过Synchronizer Token Pattern和Cookie-to-Header Token技术来保护网站免受此类攻击。
摘要由CSDN通过智能技术生成

DSC00964

CSRF（Cross-site request forgery，中文为跨站请求伪造）是一种利用网站可信用户的权限去执行未授权的命令的一种恶意攻击。通过伪装可信用户的请求来利用信任该用户的网站，这种攻击方式虽然不是很流行，但是却难以防范，其危害也不比其他安全漏洞小。

本文将简要介绍CSRF产生的原因以及利用方式，然后对如何避免这种攻击方式提供一些可供参考的方案，希望广大程序猿们都能够对这种攻击方式有所了解，避免自己开发的应用被别人利用。

CSRF也称作one-click attack或者session riding，其简写有时候也会使用XSRF。

[TOC]

本文将会持续修正和更新，最新内容请参考我的 GITHUB 上的 程序猿成长计划 项目，欢迎 Star，更多精彩内容请 follow me。

什么是CSRF？

简单点说，CSRF攻击就是 攻击者利用受害者的身份，以受害者的名义发送恶意请求。与XSS（Cross-site scripting，跨站脚本攻击）不同的是，XSS的目的是获取用户的身份信息，攻击者窃取到的是用户的身份（session/cookie），而CSRF则是利用用户当前的身份去做一些未经过授权的操作。

CSRF攻击最早在2001年被发现，由于它的请求是从用户的IP地址发起的，因此在服务器上的web日志中可能无法检测到是否受到了CSRF攻击，正是由于它的这种隐蔽性，很长时间以来都没有被公开的报告出来，直到2007年才真正的被人们所重视。

CSRF有哪些危害

CSRF可以盗用受害者的身份，完成受害者在web浏览器有权限进行的任何操作，想想吧，能做的事情太多了。

  • 以你的名义发送诈骗邮件，消息
  • 用你的账号购买商品
  • 用你的名义完成虚拟货币转账
  • 泄露个人隐私
  • ...

产生原理以及利用方式

要完成一个CSRF攻击，必须具备以下几个条件：

  • 受害者已经登录到了目标网站（你的网站）并且没有退出
  • 受害者有意或者无意的访问了攻击者发布的页面或者链接地址

（图片来自网络，出处不明，百度来的:joy:）

整个步骤大致是这个样子的：

  1. 用户小明在你的网站A上面登录了，A返回了一个session ID（使用cookie存储）
  2. 小明的浏览器保持着在A网站的登录状态，事实上几乎所有的网站都是这样做的，一般至少是用户关闭浏览器之前用户的会话是不会结束的
  3. 攻击者小强给小明发送了一个链接地址，小明打开了这个地址，查看了网页的内容
  4. 小明在打开这个地址的时候，这个页面已经自动的对网站A发送了一个请求，这时候因为A网站没有退出，因此只要请求的地址是A的就会携带A的cookie信息，也就是使用A与小明之间的会话
  5. 这时候A网站肯定是不知道这个请求其实是小强伪造的网页上发送的，而是误以为小明就是要这样操作，这样小强就可以随意的更改小明在A上的信息，以小明的身份在A网站上进行操作

利用方式

利用CSRF攻击，主要包含两种方式，一种是基于GET请求方式的利用，另一种是基于POST请求方式的利用。

GET请求利用

使用GET请求方式的利用是最简单的一种利用方式，其隐患的来源主要是由于在开发系统的时候没有按照HTTP动词的正确使用方式来使用造成的。对于GET请求来说，它所发起的请求应该是只读的，不允许对网站的任何内容进行修改。

但是事实上并不是如此，很多网站在开发的时候，研发人员错误的认为GET/POST的使用区别仅仅是在于发送请求的数据是在Body中还是在请求地址中，以及请求内容的大小不同。对于一些危险的操作比如删除文章，用户授权等允许使用GET方式发送请求，在请求参数中加上文章或者用户的ID，这样就造成了只要请求地址被调用，数据就会产生修改。

现在假设攻击者（用户ID=121）想将自己的身份添加为网站的管理员，他在网站A上面发了一个帖子，里面包含一张图片，其地址为http://a.com/user/grant_super_user/121

<img src="http://a.com/user/grant_super_user/121" />

设想管理员看到这个帖子的时候，这个图片肯定会自动加载显示的。于是在管理员不知情的情况下，一个赋予用户管理员权限的操作已经悄悄的以他的身份执行了。这时候攻击者121就获取到了网站的管理员权限。

POST请求利用

相对于GET方式的利用，POST方式的利用更加复杂一些，难度也大了一些。攻击者需要伪造一个能够自动提交的表单来发送POST请求。

<script>
$(function() {
    $('#CSRF_forCSRFm').trigger('submit');
});
</script>
<form action="http://a.com/user/grant_super_user" id="CSRF_form" method="post">
    <input name="uid" value="121" type="hidden">
</form>

只要想办法实现用户访问的时候自动提交表单就可以了。

如何防范

防范原理

防范CSRF攻击，其实本质就是要求网站能够识别出哪些请求是非正常用户主动发起的。这就要求我们在请求中嵌入一些额外的授权数据，让网站服务器能够区分出这些未授权的请求，比如说在请求参数中添加一个字段，这个字段的值从登录用户的Cookie或者页面中获取的（这个字段的值必须对每个用户来说是随机的，不能有规律可循）。攻击者伪造请求的时候是无法获取页面中与登录用户有关的一个随机值或者用户当前cookie中的内容的，因此就可以避免这种攻击。

防范技术

Synchronizer token pattern

令牌同步模式（Synchronizer token pattern，简称STP）是在用户请求的页面中的所有表单中嵌入一个token，在服务端验证这个token的技术。token可以是任意的内容，但是一定要保证无法被攻击者猜测到或者查询到。攻击者在请求中无法使用正确的token，因此可以判断出未授权的请求。

Cookie-to-Header Token

对于使用Js作为主要交互技术的网站，将CSRF的token写入到cookie中

Set-Cookie: CSRF-token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; expires=Thu, 23-Jul-2015 10:25:33 GMT; Max-Age=31449600; Path=/

然后使用javascript读取token的值，在发送http请求的时候将其作为请求的header

X-CSRF-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql

最后服务器验证请求头中的token是否合法。

验证码

使用验证码可以杜绝CSRF攻击，但是这种方式要求每个请求都输入一个验证码，显然没有哪个网站愿意使用这种粗暴的方式，用户体验太差，用户会疯掉的。

简单实现STP

首先在index.php中，创建一个表单，在表单中，我们将session中存储的token放入到隐藏域，这样，表单提交的时候token会随表单一起提交

<?php
$token = sha1(uniqid(rand(), true));
$_SESSION['token'] = $token;
?>
<form action="buy.php" method="post">
    <input type="hidden" name="token" value="<?=$token; ?>" />
    ... 表单内容
</form>

在服务端校验请求参数的buy.php中，对表单提交过来的token与session中存储的token进行比对，如果一致说明token是有效的

<?php
if ($_POST['token'] != $_SESSION['token']) {
    // TOKEN无效
    throw new \Exception('Token无效，请求为伪造请求');
}
// TOKEN有效，表单内容处理

对于攻击者来说，在伪造请求的时候是无法获取到用户页面中的这个token值的，因此就可以识别出其创建的伪造请求。

解析Laravel框架中的VerifyCSRFToken中间件

在Laravel框架中，使用了VerifyCSRFToken这个中间件来防范CSRF攻击。

在页面的表单中使用{{ CSRF_field() }}来生成token，该函数会在表单中添加一个名为_token的隐藏域，该隐藏域的值为Laravel生成的token，Laravel使用随机生成的40个字符作为防范CSRF攻击的token。

$this->put('_token', Str::random(40));

如果请求是ajax异步请求，可以在meta标签中添加token

<meta name="CSRF-token" content="{{ CSRF_token() }}">

使用jquery作为前端的框架时候，可以通过以下配置将该值添加到所有的异步请求头中

$.ajaxSetup({
    headers: {
        'X-CSRF-TOKEN': $('meta[name="CSRF-token"]').attr('content')
    }
});

在启用session的时候，Laravel会生成一个名为_token的值存储到session中。而使用前面两种方式在页面中加入的token就是使用的这一个值。在用户请求到来时，VerifyCSRFToken中间件会对符合条件的请求进行CSRF检查

if (
  $this->isReading($request) ||
  $this->runningUnitTests() ||
  $this->shouldPassThrough($request) ||
  $this->tokensMatch($request)
) {
  return $this->addCookieToResponse($request, $next($request));
}

throw new TokenMismatchException;

在if语句中有四个条件，只要任何一个条件结果为true则任何该请求是合法的，否则就会抛出TokenMismatchException异常，告诉用户请求不合法，存在CSRF攻击。

第一个条件$this->isReading($request)用来检查请求是否会对数据产生修改

protected function isReading($request)
{
    return in_array($request->method(), ['HEAD', 'GET', 'OPTIONS']);
}

这里判断了请求方式，如果是HEAD，GET，OPTIONS这三种请求方式则直接放行。你可能会感到疑惑，为什么GET请求也要放行呢？这是因为Laravel认为这三个请求都是请求查询数据的，如果一个请求是使用GET方式，那无论请求多少次，无论请求参数如何，都不应该最数据做任何修改。

第二个条件顾名思义是对单元测试进行放行，第三个是为开发者提供了一个可以对某些请求添加例外的功能，最后一个$this->tokensMatch($request)则是真正起作用的一个，它是Laravel防范CSRF攻击的关键

$sessionToken = $request->session()->token();
$token = $request->input('_token') ?: $request->header('X-CSRF-TOKEN');

if (! $token && $header = $request->header('X-XSRF-TOKEN')) {
  $token = $this->encrypter->decrypt($header);
}

if (! is_string($sessionToken) || ! is_string($token)) {
  return false;
}

return hash_equals($sessionToken, $token);

Laravel会从请求中读取_token参数的的值，这个值就是在前面表单中添加的CSRF_field()函数生成的。如果请求是异步的，那么会读取X-CSRF-TOKEN请求头，从请求头中读取token的值。

最后使用hash_equals函数验证请求参数中提供的token值和session中存储的token值是否一致，如果一致则说明请求是合法的。

你可能注意到，这个检查过程中也会读取一个名为X-XSRF-TOKEN的请求头，这个值是为了提供对一些javascript框架的支持（比如Angular），它们会自动的对异步请求中添加该请求头，而该值是从Cookie中的XSRF-TOKEN中读取的，因此在每个请求结束的时候，Laravel会发送给客户端一个名为XSRF-TOKEN的Cookie值

$response->headers->setCookie(
    new Cookie(
        'XSRF-TOKEN', $request->session()->token(), time() + 60 * $config['lifetime'],
        $config['path'], $config['domain'], $config['secure'], false
    )
);

写在最后

本文只是对CSRF做了一个简单的介绍，主要是侧重于CSRF是什么以及如何应对CSRF攻击。有一个事实是我们无法回避的：没有绝对安全的系统，你有一千种防御对策，攻击者就有一千零一种攻击方式，但不管如何，我们都要尽最大的努力去将攻击者拦截在门外。如果希望深入了解如何发起一个CSRF攻击，可以参考一下这篇文章 从零开始学CSRF。

作为一名web方向的研发人员，无论你是从事业务逻辑开发还是做单纯的技术研究，了解一些安全方面的知识都是很有必要的，多关注一些安全方向的动态，了解常见的攻击方式以及应对策略，必将在你成长为一名大牛的路上为你“推波助澜”。

yang洋PHPer
关注
《网络安全学习》 第九部分----CSRF（跨站请求伪造）漏洞详解
tomatocc的博客
08-28 443
跨站请求伪造（也称为XSRF，CSRF和跨站点参考伪造）通过利用站点对用户的信任来工作。站点任务通常链接到特定URL（例如：http：//site/stocks？buy = 100＆stock = ebay），允许在请求时执行特定操作。如果用户登录到站点并且攻击者欺骗他们的浏览器向这些任务URL之一发出请求，则执行任务并以登录用户身份登录。通常，攻击者会将恶意HTML或JavaScript代码嵌...
pikachu-CSRF(跨站请求伪造)
a1245678899的博客
11-10 646
Cross-site request forgery 简称为“CSRF”，在CSRF的攻击场景中攻击者会伪造一个请求（这个请求一般是一个链接），然后欺骗目标用户进行点击，用户一旦点击了这个请求，整个攻击就完成了。点击修改个人信息然后使用burpsuite抓包可以看到这个数据的传输过程是get型，数据包含在URL之中直接在URL之中构造包含自己信息的网址，伪造一下，诱导用户去点击。当链接被点击以后，可以看到信息已经被修改。
anti-CSRF Token布署时需要注意的一点问题
tenfyguo的技术专栏
11-24 1万+
from : http://hi.baidu.com/aullik5/blog/item/b2cdb4444d061c21cffca3a5.html       防范CSRF攻击的方案有许多种，有用验证码来防的(tenfy:方案比较重，适合于敏感数据的变更类操作，对一般查询信息类不是很合适)，更多的是生成一个随机的token，当用户提交的时候，在服务器端比对一下token值是否正确，不正确就丢弃掉，正确就验证通过。     （因为有些人喜欢钻牛角尖，所以再次强调下，我们习惯于区分CSRF和XSRF，后者是在
【web安全】——CSRF跨站请求伪造
最新发布
wxh的博客
10-05 1055
可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证。CSRF攻击的过程，往往是在用户不知情的情况下构造了网络请求。
web安全之token和CSRF攻击
热门推荐
梦空间
05-03 2万+
上文我转载了两篇关于ThinkPHP令牌验证的文章（ThinkPHP中的create方法与自动令牌验证）。其中提及到了  token ，这里针对 token 的作用，转载了另外两篇文章。 （web安全之token   Web安全之CSRF攻击） web安全之token 参考：http://blog.csdn.net/sum_rain/article/details/370
http referer 验证防御方法_【知识点】5个防御CSRF的小技巧
weixin_39931101的博客
11-29 678
CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装成受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此...
怎么防止跨站请求伪造攻击（CSRF）？
dzqxwzoe的博客
02-24 1594
没学过的同学也不要慌，可以去B站搜索相关视频，你搜关键词网络安全工程师会出现很多相关的视频教程，我粗略的看了一下，排名第一的视频就讲的很详细。从时代发展的角度看，网络安全的知识是学不完的，而且以后要学的会更多，同学们要摆正心态，既然选择入门网络安全，就不能仅仅只是入门程度而已，能力越强机会才越多。不过我们这个水平也就算个渗透测试工程师，也就只能做个基础的安全服务，而这个领域还有很多业务，像攻防演练、等保测评、风险评估等，我们的能力根本不够看。下面用一个银行网站的转账功能，说明攻击原理。
Django中如何防范CSRF跨站点请求伪造攻击的实现
09-19
CSRF（Cross-Site Request Forgery，跨站请求伪造），是一种常见的安全攻击手段。在这种攻击中，攻击者利用受害者的身份（通常是通过受害者已登录状态下的Cookies）发起恶意请求。这些请求对于服务器而言是合法的，...
CSRF跨站请求伪造，含使用教程和测试工具
05-04
CSRF跨站请求伪造，使用OWASP CSRFTester工具可以抓取并伪造请求，其测试原理是，使用代理抓取我们在浏览器中访问过的所有的连接以及所有的表单等信息，通过在CSRFTester中修改相应的表单等信息，重新提交，相当于一...
27家网络安全大厂，程序员找工作用得上！
瓦罗兰特顶级C位的博客
11-24 711
27家网络安全大厂，程序员找工作用得上！
anti-csrf, 全功能反CSRF库.zip
09-18
anti-csrf, 全功能反CSRF库 反csrf库 动机没有任何好的会话来支持CSRF保护库。 我们的意思是：CSRF令牌可以限制为以下任何或者全部：特定会话特定的HTTP URI特定的IP地址( 可选)可以存储多个CSRF令牌CSR
anti-csrf:功能齐全的反CSRF库
04-29
反CSRF库 动机 没有好的会话驱动的CSRF预防库。 好的，我们的意思是： 可以将CSRF令牌限制为以下任意一项或全部： 一个特定的会议 特定的HTTP URI 特定的IP地址（可选） 可以存储多个CSRF令牌 CSRF令牌在使用一次后失效 会话数据中存储的令牌数量上限在我们的实现中，最早的被删除 警告-请勿在所有$_SESSION数据都存储在客户端的cookie中的任何项目中使用。 这将快速运行HTTP cookie的最大4KB存储空间。 在任何项目中使用 请参阅autoload.php以获取SPL自动加载器。 与Twig模板一起使用 首先，添加一个像这样的过滤器： use \ ParagonIE \ AntiCSRF \ AntiCSRF ; $ twigEnv -> addFunction ( new \ Twig_SimpleFunction (
Anti-CSRF and AJAX
softuse的博客
02-03 448
Anti-CSRF and AJAX The form token can be a problem for AJAX requests, because an AJAX request might send JSON data, not HTML form data. One solution is to send the tokens in a custom HTTP header. The...
校验Referer头，防范CSRF(跨站请求伪造)攻击的拦截器
weixin_34372728的博客
12-29 1912
public final static String domainName = "192.168.2.123"; package com.web.interceptors; import org.apache.log4j.Logger; import org.apache.struts2.ServletActionConte...
跨站请求伪造（CSRF）攻击原理及预防手段
慢慢
06-02 5853
随机化Token（CSRF Token）：Token是用于验证网站请求者身份的一种机制，可以防止CSRF攻击。该Token会在每次访问页面时刷新，以确保每次请求都需要新的Token。例如，在web应用程序中，可以通过hidden field的方式将Token加入到表单中，提交时验Referer检查：在服务端校验请求头中的Referer字段，确保请求是来自合法的来源页面，常用于辅助Token机制的验证。
开源项目 `anti-csrf` 使用教程
gitblog_00138的博客
08-26 375
开源项目 anti-csrf 使用教程 anti-csrfFull-Featured Anti-CSRF Library项目地址:https://gitcode.com/gh_mirrors/an/anti-csrf 1. 项目的目录结构及介绍 anti-csrf 项目的目录结构如下： anti-csrf/ ├── src/ │ ├── AntiCSRF.php │ └── Sessio...
4-3csrf token详解以及常见的防范措施
山兔的博客
07-10 5985
CSRF（post）实验演示和解析  Anti CSRF token  常见CSRF防范措施CSRF的主要问题是敏感操作的链接容易被伪造，那么如何让这个链接不容易被伪造？ -每次请求，都增加一个随机码（长度要够，需要够随机，不容易伪造），后台每次对这个随机码进行验证！就是这个token值Ant上CSRF（token）项目的token生成代码：当我们每次请求修改页面的时候，后台会先去调用一个函数，在实际的系统里面，会写的更复杂一点，当我们去请求页面的时候，后台会去查一下session里面，有没有tok
CSRF跨站请求伪造漏洞
12-06
CSRF（Cross-site request forgery）跨站请求伪造是一种网络攻击方式，攻击者通过伪造用户请求来冒充用户身份，从而进行一些非法操作。攻击者通常会在第三方网站上设置陷阱，引诱用户点击链接或者访问页面，从而触发...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值