Asp.net CSRF 跨站点请求伪造实现代码

CSRF,Cross Site Request Forgery,即跨站点请求伪造。

这种攻击是指,在用户正常登录系统以后,攻击者诱使用户访问一些非法链接,以执行一些非法操作。比如:如果删除用户操作(如,yourdomain.com/deluser?id=123)没有经过防范CSRF的处理,那么,假设用户登录系统后,攻击者诱使用户同时访问了攻击者的站点的一个链接(该链接正好为yourdomain.com/deluser?id=123),那么,系统就会在用户不知情的情况下丢失一个用户。

在这个例子中,跨站请求中的链接之所以被正常执行,首先是因为请求中浏览器正常发送了yourdomain的认证信息(一般保存在cookie中),服务器根本不知道该请求是用户为之,还是恶意为之。其次,就是请求中的参数是可以被猜测的。这两个条件,构成了CSRF攻击的全部条件。

这里还需要强调一下,如果认证基于cookie,那么实际上还有第三个条件:如果cookie是本地cookie,浏览器还需要允许跨域发送本地cookie,即如果请求是第三方网站发起的,应带上请求的域的cookie。IE默认是不允许跨域发送本地cookie的(session cookie则无此限制),而firefoxe就默认允许的。

原理如图:

应对策略

1:采用token的形式。

采用token是指让请求所带的参数变的不可猜测。即,每次需要保护的请求都要带上一个额外的参数,该参数可以是sessionid(一定要是额外的参数,但是其值可以为sessionid),也可以是另外的无法被猜测的一个值。然后,服务器在得到这个请求后,再验证该值是否匹配。

可能有人会进一步提出,不是sessionid也是可以非法得到的吗,或者说用户的sessionid是没有授权被操作的?答案是没错,但是,那又是另外的攻击方法(涉及到会话劫持和权限欺骗)了,在这里,仅仅防御的是CSRF攻击。

不过为了保险起见,我们可以用sessionid+salt,然后散列的方式来生成这个token。

采用token的形式,我们还需要考虑该token,也就是客户端所带的这个参数的保存问题。从CSRF的本质考虑,token的保存首先不能保存在cookie中,因为cookie本身就是在发送请求的时候可以被带上。

其次,token可以保存在服务器端吗,如,我们可以为当前请求设定一个唯一标识,然后保存在session中。答案当然也是不行的,我们可以假设完成一次请求包含两个部分:发起请求的URL(或程序),处理请求的URL(或程序),诚然,这种方式我们防住了单独请求”处理请求的URL”的CSRF攻击。但是,既然攻击者得到了处理请求的页面,那么,他在伪造CSRF的时候,只要带上了发送请求的页面,就依然可以完成一次攻击。

所以,token的保存只能是保存在发送到客户端的页面中,然后客户端在接下来发送的请求的时候,带上这个参数就可以了。当然,如果页面本身已经被XSS攻破,那么攻击者仍旧可以伪造一次合法请求,但这已经不是防范CSRF的范畴了,而是防范XSS。

2:每次需要被保护的请求发送时,都要求用户输入密码;

3:每次需要被保护的请求发送时,都带上referrer。不过这并不是应对的最佳策略,因为referrer是可以被轻易伪造的。

具体措施

以下具体措施针对token的形式。

n  遍历前台所有发送请求的地方

1:文件查找前台所有的”svc”,”ajax”,”.aspx”,”.html”,”.htm”

2:文件查找前台所有的”form”

根据以上的查找,汇总到如下的表格:


序号

文件

代码行

GET/POST

处理完成否

 

 

 

 

 

n  处理请求

筛选出需要进行CSRF处理的请求。然后对请求做如下处理:

如果是GET方式发送的请求,则为请求加入参数token=[value],其中[value]为sessionid的值;

如果是POST方式发送的请求,则为Form加入隐藏的input,其name为token,其值为sessionid。      

n  遍历所有的请求处理处

1:遍历所有的svc,为svc的方法增加token参数

2:遍历所有的aspx页面的code-behind

3:遍历所有其它的后台方法,如果存在的话,如控制器方法(在EL中并不存在)。

根据以上的查找,汇总到如下的表格


序号

文件

代码行

处理完成否

 

 

 

 

n  处理请求处理处

处理参数中的token,检测该token是否存在于当前的sessionid中,如果存在,则放行,否则异常;

以上全部的逻辑用代码表示,大致如下

 

 代码如下 复制代码

protected void Page_Load(object sender, EventArgs e)
        {
            string token = CreateToken();
            PutTokenToClient(token);
            SaveTokenInServer(token);
        }

        protected void ButtonDosomething_Click(object sender, EventArgs e)
        {
            string token = GetTokenFromRequest();
            //需要csrf保护的地方就check才放行
            if (TokenIsOK(token))
            {
                //todo: go
            }
            else
            {
                //todo: block
            }
        }

        private string GetTokenFromRequest()
        {
            //todo 从请求中得到coken,一般为URL QueryString或表单元素
            throw new NotImplementedException();
        }

        private void PutTokenToClient(string token)
        {
            //todo 将其保存到前台,如请求的url,或隐藏的input
        }

        private void SaveTokenInServer(string token)
        {
            //一般保存在session中
            Session["CRSFToken"] = token;
        }

        private bool TokenIsOK(string token)
        {
            string tokenInServer = Session["CRSFToken"].ToString();
            return tokenInServer == token ? true : false;
        }

        public string _salt = "asdfkl@,.;#sss13131313";

        public string CreateToken()
        {
            return MD5(Session.SessionID + _salt);
        }

        private void ClearToken()
        {
            Session["CRSFToken"] = string.Empty;
        }

        private string MD5(string p)
        {
            throw new NotImplementedException();
    }

时间: 2024-10-29 07:23:39

Asp.net CSRF 跨站点请求伪造实现代码的相关文章

求助!请问j2ee如何拒绝恶意请求---跨站点请求伪造

问题描述 求助!请问j2ee如何拒绝恶意请求---跨站点请求伪造 解决方案 解决方案二:request.getHeader("host")再跟你的域名比较一下就知道了解决方案三:(ASP.NET中已经提供一个自动防范的方法,就是用页面属性ViewStateUserKey.在Page_Init方法中设置其值:this.ViewStateUserKey=Session.SessionID)我现在还没有通过,你可以试试.

让我们一起来消灭CSRF跨站请求伪造(上)

写在前面的话 现在已经是2017年了,想必大家一定知道什么是CSRF(跨站请求伪造)了,因为之前关于这个话题的讨论已经有很多了.这种漏洞已经存在了很多年,社区中也有非常详细的文档以及对应的解决方案,目前很多热门的网站开发框架基本上或多或少都实现了相应的缓解方案. 那我们在本系列文章中要讨论什么呢?请大家先思考以下几个因素: 遗留应用缺少CSRF保护; 某些框架的内置CSRF防护机制存在缺陷; 应用程序没有使用已证明安全的框架保护机制; 新的应用程序没有使用提供了CSRF保护功能的现代框架; 因此

让我们一起来消灭CSRF跨站请求伪造(下)

写在前面的话 在本系列文章的上集中,我们跟大家介绍了关于CSRF的一些基本概念,并对常见的几种CSRF漏洞类型进行了讲解.那么接下来,我们就要跟大家讨论一下如何才能消灭CSRF. 现代保护机制 实际上,通过修改应用程序源代码来实现CSRF保护在很多情况下是不现实的,要么就是源代码无法获取,要么就是修改应用程序的风险太高了.但我们所设计的解决方案可以轻松地部署到RASP.WAF.反向代理或均衡负载器中,并且可以同时保护一个或多个配置相同的应用程序. 首先我们要知道,正确地使用安全或不安全的HTTP

CSRF(跨站请求伪造攻击)详解以及防护之道

CSRF(Cross Site Request Forgery, 跨站域请求伪造)是一种网络的攻击方式,该攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点,从而在并未授权的情况下执行在权限保护之下的操作,有很大的危害性.然而,该攻击方式并不为大家所熟知,很多网站都有 CSRF 的安全漏洞.本文首先介绍 CSRF 的基本原理与其危害性,然后就目前常用的几种防御方法进行分析,比较其优劣.最后,本文将以实例展示如何在网站中防御 CSRF 的攻击,并分享一些开发过程中的最佳实践. C

跨站请求伪造(CSRF)攻击原理解析:比你所想的更危险

跨站请求伪造(Cross-Site Request Forgery)或许是最令人难以理解的一种攻击方式了,但也正因如此,它的危险性也被人们所低估.在"开放式Web应用程序安全项目"(OWASP)的榜单中,CSRF(又称XSRF)就位于前10的位置.简而言之,就是恶意软件强制浏览器在用户已认证的上下文环境中,执行原本并不需要的指令. 浏览器厂家深知这一危害,从而推出了某些类型的CSRF防护技术. 尽管如此,攻击者们的手段也在日益翻新,甚至结合多种类型的Web攻击以放大危害(比如XSS和S

安全漏洞问题4:跨站请求伪造

安全漏洞问题4:跨站请求伪造 1.1. 漏洞描述 跨站请求伪造(CSRF)是一种挟制终端用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法.攻击者只要借助少许的社会工程诡计,例如通过电子邮件或者是聊天软件发送的链接,攻击者就能迫使一个Web应用程序的用户去执行攻击者选择的操作. 在跨站请求伪造攻击中,攻击者构造恶意URL请求,然后诱骗合法用户访问此URL链接,以达到在Web应用中以此用户权限执行特定操作的目的.和反射型XSS的主要区别是:反射型XSS的目的是在客户端执行脚本:CSRF的

[译] 跨站请求伪造已死!

本文讲的是[译] 跨站请求伪造已死!, 原文链接:Cross-Site Request Forgery is dead! 原文作者:Scott 译文出自:掘金翻译计划 译者:XatMassacrE 校对者:newbieYoung,DeadLion 跨站请求伪造已死! 在连续不断的被跨站请求伪造折磨了这么多年后,我们现在终于有了一个合理的解决方案.一个对网站拥有者没有技术负担.实施起来没有难度.部署又非常简单的方案,它就是 Same-Site Cookies. 和互联网历史一样悠久的跨站请求伪造

《第三方JavaScript编程》——7.3 跨站请求伪造

7.3 跨站请求伪造 在第4章中,我们谈到了同源策略.该策略被所有浏览器支持,并防止不同来源的Web页面互相访问对方的方法和属性.你已经学到了一些技巧,使用这些技巧可以向你的服务器跨域发送消息.在本节中,我们将介绍利用该特性是如何转而对你进行攻击的. 跨站请求伪造(CSRF或者XSRF)是针对用户的另一种类型的漏洞.与XSS不同,XSS是将伪造的内容展现给用户,而XSRF利用的是Web应用程序与用户浏览器之间的信任.在本质上,易受XSRF攻击的Web应用都允许攻击者通过自己的网站诱导用户执行某些

php漏洞之跨网站请求伪造与防止伪造方法

伪造跨站请求介绍 伪造跨站请求比较难以防范,而且危害巨大,攻击者可以通过这种方式恶作剧,发spam信息,删除数据等等.这种攻击常见的表现形式有: 伪造链接,引诱用户点击,或是让用户在不知情的情况下访问 伪造表单,引诱用户提交.表单可以是隐藏的,用图片或链接的形式伪装. 比较常见而且也很廉价的防范手段是在所有可能涉及用户写操作的表单中加入一个随机且变换频繁的字符串,然后在处理表单的时候对这个字符串进行检查.这个随机字符串如果和当前用户身份相关联的话,那么攻击者伪造请求会比较麻烦. 如果攻击者以隐藏