Web安全相关(二):跨站请求伪造(CSRF/XSRF)

简介

  CSRF(Cross-site request forgery跨站请求伪造,也被称为“One Click Attack”或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用。尽管听起来像跨站脚本(XSS),但它与XSS非常不同,并且攻击方式几乎相左。XSS利用站点内的信任用户,而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比,CSRF攻击往往不大流行(因此对其进行防范的资源也相当稀少)和难以防范,所以被认为比XSS更具危险性。

场景

某程序员大神God在某在线银行Online Bank给他的朋友Friend转账。

  

  转账后,出于好奇,大神God查看了网站的源文件,以及捕获到转账的请求。

  大神God发现,这个网站没有做防止CSRF的措施,而且他自己也有一个有一定访问量的网站,于是,他计划在自己的网站上内嵌一个隐藏的Iframe伪造请求(每10s发送一次),来等待鱼儿Fish上钩,给自己转账。

  网站源码:

 

    伪造请求源码:

 

  鱼儿Fish打开了大神God的网站,在上面浏览丰富多彩的内容。此时伪造请求的结果是这样的(为了演示效果,去掉了隐藏):

  

  因为鱼儿Fish没有登陆,所以,伪造请求一直无法执行,一直跳转回登录页面。

  然后鱼儿Fish想起了要登录在线银行Online Bank查询内容,于是他登录了Online Bank。

  此时伪造请求的结果是这样的(为了演示效果,去掉了隐藏):

  鱼儿Fish每10秒会给大神God转账100元。

  

  

防止CSRF

  CSRF能成功是因为同一个浏览器会共享Cookies,也就是说,通过权限认证和验证是无法防止CSRF的。那么应该怎样防止CSRF呢?其实防止CSRF的方法很简单,只要确保请求是自己的站点发出的就可以了。那怎么确保请求是发自于自己的站点呢?ASP.NET以Token的形式来判断请求。

  我们需要在我们的页面生成一个Token,发请求的时候把Token带上。处理请求的时候需要验证Cookies+Token。

  

  此时伪造请求的结果是这样的(为了演示效果,去掉了隐藏):

$.ajax

  如果我的请求不是通过Form提交,而是通过Ajax来提交,会怎样呢?结果是验证不通过。

  为什么会这样子?我们回头看看加了@Html.AntiForgeryToken()后页面和请求的变化。

  1. 页面多了一个隐藏域,name为__RequestVerificationToken。

  2. 请求中也多了一个字段__RequestVerificationToken。

  

  原来要加这么个字段,我也加一个不就可以了!

  啊!为什么还是不行...逼我放大招,研究源码去!

  

  噢!原来token要从Form里面取。但是ajax中,Form里面并没有东西。那token怎么办呢?我把token放到碗里,不对,是放到header里。

  js代码:

 

  在服务端,参考ValidateAntiForgeryTokenAttribute,编写一个AjaxValidateAntiForgeryTokenAttribute:

 

  然后调用时把ValidateAntiForgeryToken替换成AjaxValidateAntiForgeryToken。

  

  大功告成,好有成就感!

全局处理

  如果所有的操作请求都要加一个ValidateAntiForgeryToken或者AjaxValidateAntiForgeryToken,不是挺麻烦吗?可以在某个地方统一处理吗?答案是阔仪的。

  ValidateAntiForgeryTokenAttribute继承IAuthorizationFilter,那就在AuthorizeAttribute里做统一处理吧。

  ExtendedAuthorizeAttribute:

 

  

  然后在FilterConfig注册一下。

  

  FAQ:

  1. BypassCsrfValidationAttribute是什么鬼?不是有个AllowAnonymousAttribute吗?

  如果有些操作你不需要做CSRF的处理,比如附件上传,你可以在对应的Controller或Action上添加BypassCsrfValidationAttribute。

  AllowAnonymousAttribute不仅会绕过CSRF的处理,还会绕过认证和验证。BypassCsrfValidationAttribute绕过CSRF但不绕过认证和验证,

也就是BypassCsrfValidationAttribute作用于那些登录或授权后的Action。

  2. 为什么只处理POST请求?

  我开发的时候有一个原则,查询都用GET,操作用POST,而对于查询的请求没有必要做CSRF的处理。大家可以按自己的需要去安排!

  

  3. 我做了全局处理,然后还在Controller或Action上加了ValidateAntiForgeryToken或者AjaxValidateAntiForgeryToken,会冲突吗?

  不会冲突,只是验证会做两次。

时间: 2024-12-25 08:43:42

Web安全相关(二):跨站请求伪造(CSRF/XSRF)的相关文章

跨站请求伪造 CSRF / XSRF<一:介绍>

跨站请求伪造(英语:Cross-site request forgery),也被称为 one-click attack 或者 session riding,通常缩写为 CSRF 或者 XSRF, 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法. ***跟跨网站脚本(XSS)相比,XSS 利用的是用户对指定网站的信任,CSRF 利用的是网站对用户网页浏览器的信任. 攻击的细节 跨站请求攻击,简单地说,是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执

跨站请求伪造 CSRF / XSRF<二:应用>

防御的方法主要有两种<java示例> 1.检查Referer字段 HTTP头中有一个Referer字段,这个字段用以标明请求来源于哪个地址.在处理敏感数据请求时,通常来说,Referer字段应和请求的地址位于同一域名下.以上文银行操作为例,Referer字段地址通常应该是转账按钮所在的网页地址,应该也位于www.examplebank.com之下.而如果是CSRF攻击传来的请求,Referer字段会是包含恶意网址的地址,不会位于www.examplebank.com之下,这时候服务器就能识别出

跨站请求伪造CSRF原理

跨站请求伪造CSRF原理 CSRF是Cross Site Request Forgery的缩写,CSRF是伪造成合法用户发起请求 先了解下session: 用户登录时服务器端生成一个Session 返回给用户session_id在cookie中 用户下次登录带着有session_id的cookie登录 跨站请求伪造例子 只有session的话,如果有一个网站可以访问所有的cookie,那么就会获取到所有的session,然后带着你的session去访问别的网站. 比如:在一些诱骗性的网站上,可以

.NET Core实战项目之CMS 第十四章 开发篇-防止跨站请求伪造(XSRF/CSRF)攻击处理

通过 ASP.NET Core,开发者可轻松配置和管理其应用的安全性. ASP.NET Core 中包含管理身份验证.授权.数据保护.SSL 强制.应用机密.请求防伪保护及 CORS 管理等等安全方面的处理. 通过这些安全功能,可以生成安全可靠的 ASP.NET Core 应用.而我们这一章就来说道说道如何在ASP.NET Core中处理"跨站请求伪造(XSRF/CSRF)攻击"的,希望对大家有所帮助! 本文已收录至<.NET Core实战项目之CMS 第一章 入门篇-开篇及总体

Web安全测试之跨站请求伪造(CSRF)篇

跨站请求伪造(即CSRF)被Web安全界称为诸多漏洞中“沉睡的巨人”,其威胁程度由此“美誉”便可见一斑.本文将简单介绍该漏洞,并详细说明造成这种漏洞的原因所在,以及针对该漏洞的黑盒测试与灰盒子测试具体方法和示例,最后提提了一些防范该攻击的建议,希望本文对读者的安全测试能够有所启发. 一.CSRF概述 我们首先来了解一下什么是跨站请求伪造(CSRF)?跨站请求伪造是一种挟制终端用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法.攻击者只要借助少许的社会工程诡计,例如通过电子邮件或者是聊天

跨站请求伪造(csrf)

跨站请求伪造(csrf) 钓鱼网站 ? 就类似于你搭建了一个跟银行一模一样的web页面 ? 用户在你的网站转账的时候输入用户名 密码 对方账户 ? 银行里面的钱确实少了 但是发现收款人变了 最简单的原理 你写的form表单中 用户的用户名 密码都会真实的提交给银行后台 但是收款人的账户却不是用户填的 你暴露给用户的是一个没有name属性的input框 你自己提前写好了一个隐藏的带有name和value的input框 真正的网站 前端 <h1>真正的网站</h1> <form

跨站请求伪造CSRF(Cross-site request forgery)

CSRF(Cross-site request forgery)跨站请求伪造,也被称为“One Click Attack”或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用 一般被攻击步骤: 1.登录受信任网站A,并在本地生成Cookie. 2.在不登出A的情况下,访问危险网站B. 所以没事的时候不要乱点链接不是随便说着玩的. 常见场景分析: 假设你有一个这样的Action,因为已经加了[Authorize(Roles = "Admins")]标记

跨站请求伪造(CSRF攻击)理解

一  概念 你这可以这么理解CSRF攻击:攻击者盗用了你的身份,以你的名义发送恶意请求.CSRF能够做的事情包括:以你名义发送邮件,发消息,盗取你的账号,甚至于购买商品,虚拟货币转账......造成的问题包括:个人隐私泄露以及财产安全. 二  过程 1  受害者 Bob 在银行有一笔存款,通过对银行的网站发送请求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可以使 Bob 把 1000000 的存款转到

跨站请求伪造CSRF

CSRF是Cross Site Request Forgery的缩写,乍一看和XSS差不多的样子,但是其原理正好相反,XSS是利用合法用户获取其信息,而CSRF是伪造成合法用户发起请求. 在XSS危害--session劫持中我们提到了session原理,用户登录后会把登录信息存放在服务器,客户端有一个用户标识存在cookie中,只要用户不关闭浏览器或者退出登录,在其有效期内服务器就会把这个浏览器发送的请求当作当前客户,如果这时候用户被欺骗,使用浏览器打开了某些恶意网址,里面就会包含一些不是用户希

防止跨站请求伪造(CSRF)攻击 和 防重复提交 的方法的实现

CSRF的概率可以参考:http://netsecurity.51cto.com/art/200812/102951.htm 本文介绍的是基于spring拦截器的Spring MVC实现 首先配置拦截器: <mvc:interceptors> <mvc:interceptor> <!-- 匹配的是url路径, 如果不配置或/**,将拦截所有的Controller --> <mvc:mapping path="/xxx/**" /> <