Asp.net安全架构之3: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();
    }
复制代码

 本文转自最课程陆敏技博客园博客,原文链接:http://www.cnblogs.com/luminji/archive/2012/06/08/2511384.html,如需转载请自行联系原作者

相关文章
|
4月前
|
人工智能 安全 Cloud Native
Nacos 3.0 架构升级,AI 时代更安全的 Registry
随着Nacos3.0的发布,定位由“更易于构建云原生应用的动态服务发现、配置管理和服务管理平台”升级至“ 一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台 ”。
|
4月前
|
存储 设计模式 人工智能
AI Agent安全架构实战:基于LangGraph的Human-in-the-Loop系统设计​
本文深入解析Human-in-the-Loop(HIL)架构在AI Agent中的核心应用,探讨其在高风险场景下的断点控制、状态恢复与安全管控机制,并结合LangGraph的创新设计与金融交易实战案例,展示如何实现效率与安全的平衡。
700 0
|
1月前
|
人工智能 API 数据库
Semantic Kernel .NET 架构学习指南
本指南系统解析微软Semantic Kernel .NET架构,涵盖核心组件、设计模式与源码结构,结合实战路径与调试技巧,助你从入门到贡献开源,掌握AI编排开发全栈技能。
183 2
|
1月前
|
存储 监控 安全
132_API部署:FastAPI与现代安全架构深度解析与LLM服务化最佳实践
在大语言模型(LLM)部署的最后一公里,API接口的设计与安全性直接决定了模型服务的可用性、稳定性与用户信任度。随着2025年LLM应用的爆炸式增长,如何构建高性能、高安全性的REST API成为开发者面临的核心挑战。FastAPI作为Python生态中最受青睐的Web框架之一,凭借其卓越的性能、强大的类型安全支持和完善的文档生成能力,已成为LLM服务化部署的首选方案。
|
8月前
|
人工智能 运维 安全
AI 安全架构概述
AI 安全架构涵盖数据采集、模型训练、推理部署等阶段,确保安全性、隐私与合规。其核心组件包括数据层、模型层、推理层、应用层和运维层,针对数据安全威胁(如数据投毒)、模型窃取、对抗攻击及系统漏洞等风险,提出数据加密、对抗训练、联邦学习等防御策略,并强调开发前、开发中和部署后的最佳实践,以降低 AI 解决方案的安全风险。
837 13
|
3月前
|
存储 安全 前端开发
如何开发一套EHS 健康安全环境管理系统?(附架构图+流程图+代码参考)
本文介绍如何开发一套完整的EHS(健康、安全和环境)管理系统,涵盖系统核心模块、技术架构、数据库设计、前后端开发示例及上线建议,帮助企业提升安全管理效率与合规性。
|
3月前
|
传感器 安全 前端开发
如何开发一套EHS健康安全环境管理系统中的风险管理板块?(附架构图+流程图+代码参考)
本文详解企业EHS(健康·安全·环境)系统中的风险管控板块,强调其核心在于构建“识别—评估—巡检—治理—验证”的闭环流程,将风险数据可视化并转化为可落地的行动指引。内容涵盖风险管控的意义、功能边界、系统架构、LEC评估方法、巡检流程、看板设计、开发技巧、落地建议、实现效果及代码参考,帮助技术团队和EHS负责人快速掌握系统搭建要点,提升企业安全管理水平。
|
7月前
|
监控 安全 数据安全/隐私保护
销售易CRM:技术架构与安全性能的深度解析
销售易CRM基于云计算与微服务架构,融合高可用性、弹性扩展及模块化开发优势,为企业提供灵活定制化的客户关系管理解决方案。系统采用多层次安全防护机制,包括数据加密、细粒度权限控制和实时监控审计,确保数据安全与隐私保护。某金融机构的成功案例表明,销售易CRM显著提升了数据安全性和系统性能,同时满足行业合规要求。作为数字化转型的利器,销售易CRM助力企业实现可持续发展与市场竞争力提升。