浅谈ASP.NET MVC 防止跨站请求伪造(CSRF)攻击的实现方法

在HTTP POST请求中，我们多次在View和Controller中看下如下代码：

1.View中调用了Html.AntiForgeryToken()。

2.Controller中的方法添加了[ValidateAntiForgeryToken]注解。

这样看似一对的写法其实是为了避免引入跨站请求伪造（CSRF）攻击。

这种攻击形式大概在2001年才为人们所认知，2006年美国在线影片租赁网站Netflix爆出多个CSRF漏洞，2008年流行的视频网址YouTube受到CSRF攻击，同年墨西哥一家银行客户受到CSRF攻击，杀毒厂商McAfee也曾爆出CSRF攻击（引自wikipedia）。

之所以很多大型网址也遭遇CSRF攻击，是因为CSRF攻击本身的流程就比较长，很多开发人员可能在几年的时间都没遇到CSRF攻击，因此对CSRF的认知比较模糊，没有引起足够的重视。

CSRF攻击的模拟示例

我们这里将通过一个模拟的示例，讲解CSRF的攻击原理，然后再回过头来看下MVC提供的安全策略。

看似安全的银行转账页面

假设我们是银行的Web开发人员，现在需要编写一个转账页面，客户登录后在此输入对方的账号和转出的金额，即可实现转账：

[Authorize]
public ActionResult TransferMoney()
{
 return View();
}
[HttpPost]
[Authorize]
public ActionResult TransferMoney(string ToAccount, int Money)
{
 // 这里放置转账业务代码
 ViewBag.ToAccount = ToAccount;
 ViewBag.Money = Money;
 return View();
}

由于这个过程需要身份验证，所以我们为TransferMoney的两个操作方法都加上了注解[Authorize]，以阻止匿名用户的访问。

如果直接访问http://localhost:55654/Home/TransferMoney，会跳转到登录页面：

登录后，来到转账页面，我们看下转账的视图代码：

@{
 ViewBag.Title = "Transfer Money";
}

<h2>Transfer Money</h2>

@if (ViewBag.ToAccount == null)
{
 using (Html.BeginForm())
 {
 <input type="text" name="ToAccount" />
 <input type="text" name="Money" />
 <input type="submit" value="转账" />
 }
}
else
{
 @:您已经向账号 [@ViewBag.ToAccount] 转入 [@ViewBag.Money] 元！
}

视图代码中有一个逻辑判断，根据ViewBag.ToAccount是否为空来显示不同内容：

1.ViewBag.ToAccount为空，则表明是页面访问。

2.ViewBag.ToAccount不为空，则为转账成功，需要显示转账成功的提示信息。

来看下页面运行效果：

功能完成！看起来没有任何问题，但是这里却又一个CSRF漏洞，隐蔽而难于发现。

我是黑客，Show me the money

这里就有两个角色，银行的某个客户A，黑客B。

黑客B发现了银行的这个漏洞，就写了两个简单的页面，页面一（click_me_please.html）：

<!DOCTYPE html>
<html>
<head>
 <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
</head>
<body>

 哈哈，逗你玩的！

 <iframe frameborder="0"
style="display:none;" src="./click_me_please_iframe.html"></iframe>

</body>
</html>

第一个页面仅包含了一个隐藏的iframe标签，指向第二个页面（click_me_please_iframe.html）：

<!DOCTYPE html>
<html>
<head>
 <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
</head>
<body onload="document.getElementById('myform1').submit();">

 <form method="POST" id="myform1"
action="http://localhost:55654/Home/TransferMoney">
 <input type="hidden" name="ToAccount" value="999999999">
 <input type="hidden" name="Money" value="3000">
 </form>

</body>
</html>

第二个页面放置了一个form标签，并在里面放置了黑客自己的银行账号和转账金额，在页面打开时提交表单（body的onload属性）。

现在黑客把这两个页面放到公网：

http://fineui.com/demo_mvc/csrf/click_me_please.html

然后批量向用户发送带有攻击链接的邮件，而银行的客户A刚好登录了银行系统，并且手贱点击了这个链接：

然后你将看到这个页面：

你可能会在心里想，谁这么无聊，然后郁闷的关闭了这个页面。之后客户A会更加郁闷，因为黑客B的银行账号[999999999]已经成功多了3000块钱！

到底怎么转账的，不是有身份验证吗

是的。转账的确是需要身份验证，现在的问题是你登录了银行系统，已经完成了身份验证，并且在浏览器新的Tab中打开了黑客的链接，我们来看下到底发生了什么：

这里有三个HTTP请求，第一个就是[逗你玩]页面，第二个是里面的IFrame页面，第三个是IFrame加载完毕后发起的POST请求，也就是具体的转账页面。因为IFrame是隐藏的，所以用户并不知道发生了什么。

我们来具体看下第三个请求：

明显这次转账是成功的，并且Cookie中带上了用户身份验证信息，所有后台根本不知道这次请求是来自黑客的页面，转账成功的返回内容：

如何阻止CSRF攻击

从上面的实例我们可以看出，CSRF源于表单身份验证的实现机制。

由于HTTP本身是无状态的，也就是说每一次请求对于Web服务器来说都是全新的，服务器不知道之前请求的任何状态，而身份验证需要我们在第二次访问时知道是否登录的状态（不可能每次请求都验证账号密码），这本身就是一种矛盾！

解决这个矛盾的办法就是Cookie，Cookie可以在浏览器中保存少量信息，所以Forms Authentication就用Cookie来保存加密过的身份信息。而Cookie中保存的全部值在每次HTTP请求中（不管是GET还是POST，也不管是静态资源还是动态资源）都会被发送到服务器，这也就给CSRF以可乘之机。

所以，CSRF的根源在于服务器可以从Cookie中获知身份验证信息，而无法得知本次HTTP请求是否真的是用户发起的。

Referer验证

Referer是HTTP请求头信息中的一部分，每当浏览器向服务器发送请求时，都会附带上Referer信息，表明当前发起请求的页面地址。

一个正常的转账请求，我们可以看到Referer和浏览器地址栏是一致的：

我们再来看下刚才的黑客页面：

可以看到Referer的内容和当前发起请求的页面地址一样，注意对比：

1.浏览器网址：click_me_please.html

2.HTTP请求地址：Home/TransferMoney

3.Referer：click_me_please_iframe.html，注意这个是发起请求的页面，而不一定就是浏览器地址栏显示的网址。

基于这个原理，我们可以简单的对转账的POST请求进行Referer验证：

[HttpPost]
[Authorize]
public ActionResult TransferMoney(string ToAccount, int Money)
{
 if(Request.Url.Host != Request.UrlReferrer.Host)
 {
 throw new Exception("Referrer validate fail!");
 }

 // 这里放置转账业务代码

 ViewBag.ToAccount = ToAccount;
 ViewBag.Money = Money;
 return View();
}

此时访问http://fineui.com/demo_mvc/csrf/click_me_please.html，恶意转账失败：

MVC默认支持的CSRF验证

MVC默认提供的CSRF验证方式更加彻底，它通过验证当前请求是否真的来自用户的操作。

在视图页面，表单内部增加对Html.AntiForgeryToken函数的调用：

@if (ViewBag.ToAccount == null)
{
 using (Html.BeginForm())
 {
 @Html.AntiForgeryToken()
 <input type="text" name="ToAccount" />
 <input type="text" name="Money" />
 <input type="submit" value="转账" />
 }
}
else
{
 @:您已经向账号 [@ViewBag.ToAccount] 转入 [@ViewBag.Money] 元！
}

这会在表单标签里面和Cookie中分别生成一个名为__RequestVerificationToken 的Token：

然后添加[ValidateAntiForgeryToken]注解到控制器方法中：

[HttpPost]
[Authorize]
[ValidateAntiForgeryToken]
public ActionResult TransferMoney(string ToAccount, int Money)
{
 // 这里放置转账业务代码
 ViewBag.ToAccount = ToAccount;
 ViewBag.Money = Money;
 return View();
}

在服务器端，会验证这两个Token是否一致（不是相等），如果不一致就会报错。

下面手工修改表单中这个隐藏字段的值，来看下错误提示：

类似的道理，运行黑客页面http://fineui.com/demo_mvc/csrf/click_me_please.html，恶意转账失败：

此时，虽然Cookie中的__RequestVerificationToken提交到了后台，但是黑客无法得知表单字段中的__RequestVerificationToken值，所以转账失败。

以上这篇浅谈ASP.NET MVC 防止跨站请求伪造(CSRF)攻击的实现方法就是小编分享给大家的全部内容了，希望能给大家一个参考，也希望大家多多支持我们。

赞 (0)

相关推荐

  • 浅谈ASP.NET MVC 防止跨站请求伪造(CSRF)攻击的实现方法

    浅谈ASP.NET MVC 防止跨站请求伪造(CSRF)攻击的实现方法

    在HTTP POST请求中,我们多次在View和Controller中看下如下代码: 1.View中调用了Html.AntiForgeryToken(). 2.Controller中的方法添加了[ValidateAntiForgeryToken]注解. 这样看似一对的写法其实是为了避免引入跨站请求伪造(CSRF)攻击. 这种攻击形式大概在2001年才为人们所认知,2006年美国在线影片租赁网站Netflix爆出多个CSRF漏洞,2008年流行的视频网址YouTube受到CSRF攻击,同年墨西哥一

  • Django CSRF跨站请求伪造防护过程解析

    前言 CSRF全称Cross-site request forgery(跨站请求伪造),是一种网络的攻击方式,也被称为"One Click Attack"或者Session Riding,通常缩写为CSRF或者XSRF. 攻击原理 1.用户访问正常的网站A,浏览器就会保存网站A的cookies. 2.用户在访问恶意网站B, 网站B上有某个隐藏的链接会自动请求网站A的链接地址,例如表单提交,传指定的参数. 3.恶意网站B的自动化请求,执行就是在用户A的同一个浏览器上,因此在访问网站A的时

  • CSRF跨站请求伪造漏洞分析与防御

    CSRF跨站请求伪造漏洞分析与防御

    目录 CSRF 漏洞原理 漏洞危害 防御绕过 漏洞利用 防御措施 总结 CSRF 现在的网站都有利用CSRF令牌来防止CSRF,就是在请求包的字段加一个csrf的值,防止csrf,要想利用该漏洞,要和xss组合起来,利用xss获得该csrf值,在构造的请求中将csrf值加进去,就可以绕过csrf防御,利用该漏洞. 该漏洞与xss的区别:xss是通过执行恶意脚本,获取到用户的cookie等信息,再利用cookie等信息进行绕过登录限制,做一些用户可以做的事. 而csrf是伪造请求,让用户自己执行攻

  • 解析django的csrf跨站请求伪造

    解析django的csrf跨站请求伪造

    目录 1.什么是跨站请求伪造 2.如何规避跨站请求伪造(csrf校验) 3.如何符合csrf校验 3.1 form表单如何符合校验 3.2 ajax如何符合校验 4.csrf相关的装饰器 4.1 针对FBV的csrf装饰器 4.2 针对CBV的csrf装饰器 1.什么是跨站请求伪造 请看图: 我们自行写了一个网站模仿中国银行,用户不知道是否是真的中国银行,并且提交了转账信息,生成一个form表单,向银行服务器发送转账请求,这个form表单和正规银行网站的form表单一模一样,只不过里面隐藏着改变

  • SpringSecurity跨域请求伪造(CSRF)的防护实现

    SpringSecurity跨域请求伪造(CSRF)的防护实现

    目录 一.CSRF 二.攻击过程 三.防御手段 1.HTTP Referer 2.CsrfToken认证 三.使用SpringSecurity防御CSRF 1.SpringSecurity防御CSRF过程 2.SpringSecurity配置CSRF 3.启动项目测试 一.CSRF CSRF的全称是(Cross Site Request Forgery),可译为跨域请求伪造,是一种利用用户带登录 态的cookie进行安全操作的攻击方式.CSRF实际上并不难防,但常常被系统开发者忽略,从而埋下巨

  • 浅谈Asp.net Mvc之Action如何传多个参数的方法

    最近,工作上有一个需要:用户查询日志文件信息,查看某一个具体日志信息,可能同时查看该日志所在日期的其他日志信息列表. 为完成此功能,我打算在URL中传入了两个参数,一个记录此日志时间,另外一个记录日志的主键ID,因此,准备从Asp.net MVC的路由入手. 在Global.asax文件中,默认路由如下. routes.MapRoute( "Default", // 路由名称 "{controller}/{action}/{id}", // 带有参数的 URL ne

  • 浅谈ASP.NET MVC应用程序的安全性

    前言:保护Web应用程序的安全性看起来时间苦差事,这件必须要做的工作并不能带来太多的乐趣,但是为了回避尴尬的安全漏洞问题,程序的安全性通常还是不得不做的. 1．ASP.NET Web Forms开发人员 (1)因为ASP.NET MVC不像ASP.NET Web Forms那样提供了很多自动保护机制来保护页面不受恶意用户的攻击,所以阅读本博客来了解这方面的问题,更明确的说法是:ASP.NET Web Forms致力于使应用程序免受攻击.例如: 1)服务器组件对显示的值和特性进行HTML编码,以帮

  • Django框架CBV装饰器中间件auth模块CSRF跨站请求问题

    CBV添加装饰器 给CBV添加装饰器有三种方法,三种方法都需要导入模块: from django.utils.decorators import method_decorator 第一种直接在方法上面添加: from django.utils.decorators import method_decorator class MyLogin(View): @method_decorator(auth) def get(self, request): return HttpResponse('Is

  • spring security中的csrf防御原理(跨域请求伪造)

    什么是csrf? csrf又称跨域请求伪造,攻击方通过伪造用户请求访问受信任站点.CSRF这种攻击方式在2000年已经被国外的安全人员提出,但在国内,直到06年才开始被关注,08年,国内外的多个大型社区和交互网站分别爆出CSRF漏洞,如:NYTimes.com(纽约时报).Metafilter(一个大型的BLOG网站),YouTube和百度HI......而现在,互联网上的许多站点仍对此毫无防备,以至于安全业界称CSRF为"沉睡的巨人". 举个例子,用户通过表单发送请求到银行网站,银行

  • 浅谈ASP.NET Core静态文件处理源码探究

    前言 静态文件(如 HTML.CSS.图像和 JavaScript)等是Web程序的重要组成部分.传统的ASP.NET项目一般都是部署在IIS上,IIS是一个功能非常强大的服务器平台,可以直接处理接收到的静态文件处理而不需要经过应用程序池处理,所以很多情况下对于静态文件的处理程序本身是无感知的.ASP.NET Core则不同,作为Server的Kestrel服务是宿主到程序上的,由宿主运行程序启动Server然后可以监听请求,所以通过程序我们直接可以处理静态文件相关.静态文件默认存储到项目的ww

随机推荐