同源策略以及cookie安全策略

2024-04-27 09:48

本文主要是介绍同源策略以及cookie安全策略,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!


1、引言
 
    跨站点请求伪造(Cross—Site Request Forgery).以下简称CSRF。是一种广泛存在的网站漏洞。Gmail、YouTube等著名网站都有过CSRF漏洞.甚至包括“ING DIRECT”这样的荚国第四大储蓄银行的金融机构网站。2009年3月著名 网络安全机构SANS与MITRE结合来自全球超过30个软件工作者及安全专家,将CSRF列为最危险的25个编程错误之一。
 
    2、现有的Web安全缺陷
 
    2.1 Web安全策略
 
    与CSRF有关的主要有三个Web安全策略:同源策略、Cookie安全策略和Flash安全策略。
 
    2.1.1同源策略
 
    同源指的是:同协议,同域名和同端口。同源策略,简单地说就是要求动态内容(例如,JavaScript或者VBScript)只能读取或者修改与之同源的那些HTTP应答和Cookie.而不能读取来自不同源的内容。浏览器的同源策路限制了脚本只能访问同源下的资源。
 
    同源策略仅仅阻止了脚本读取来自其他站点的内容.但是却没有防止脚本向其他站点发出请求。因为CSRF攻击是由于某些请求被发出,而引起在服务器端执行了某些动作所引起的,所以同源策略无法防止CSRF攻击。
 
    2.1.2 Cookie安全策略
 
    RFC2109定义了Cookie的安全策略。服务器设置Cookie值并为Cookie设置安全属性。Cookie的安全属性包括了Domain、Path、Secure、Expires、MaxAge和HttpOnly等。Cookie安全策略类似于同源策略并且要比同源策略更安全一些,但是利用脚本,可以把Cookie的安全级别降低.甚至Cookie的path属性可以被完全绕过。如果一位攻击者可以突破或绕过两源策略的话,就可以通过DOM的变量document.cookie轻松读取Cookie。
 
    2.1.3 Flash安全策略
 
    默认时,Flash的安全策略与同源策略非常类似,来自于某个域的Flash应用只可以读取来自该域的响应。但是Flash的安全策略并不被同源策略限制.Adobe公司定义了F1ash的跨域策略,该策略通常定义在一个名为crossdomain.xml的策略文件中。该文件定义了哪些域可以和当前域通信。错误的配置文件可能导致兀ash突破同源策略。导致受到迸一步的攻击。安全研究人员曾经对500个顶级网站进行了分析.发现其中有143个站点使用了crossdomain.xml策略文件。而在这143个站点中。又有47个站点对来自第三方站点的连接完全接受,这可能导致CSRF 漏洞。
 
    2.2 Web认证方式和 浏览器的安全缺陷
 
    现在的Web应用程序几乎都是使用Cookie来识别用户身份以及保存会话状态。浏览器在最初加入Cookie功能时并没有考虑安全因素。假设一个网站使用了Cookie,当一个用户完成身份验证之后.浏览器得到一个标识用户身份的Cookie,只要不退出或关闭浏览器。以后访问相同网站下的页面的时候,对每一个请求浏览器都会“智能”地主动附带上该网站的Cookie来标识自己,用户不需要重新认证就可以被网站识别。当第三方WEB页面产生了指向当前网站域下的请求时,该请求也会带上当前网站的Cookie。这种认证方式,称之为隐式认证。
 
    不同浏览器对于Cookie的处理不尽相同,Internet Explorer默认阻止向第三方发送当前的Cookie(见213节),而Firefox和Chrome则默认没有限制。
 
    现在很多用户上网使用多窗口或多标签页浏览器,例如傲游、Firefox、Opera等。这些浏览器在方便用户的同时也增大了风险,因为它们只有一个进程运行,Cookie在各个窗121或标签页之问是共享的。
 
    除了Cookie认证方式之外,其他Web认证机制也面临同样的问题。比如HTTP基本认证,用户通过认证后。浏览器仍会“智能”地把用户名和口令附加到之后第三方发给站点的请求中。即使网站使用了安全套接字(SSL)来加密连接.浏览器也会”智能“地自动把SSL认证信息加到第三方发给站点的请求中。
 
    2.3 P3P的副作用
 
    Internet Explorer在处理Cookie时,还遵守P3P(Platform forPrivaey Preferenees)规范。P3P是W3C制定的一项关于Cookie的隐私保护标准,要求网站向用户表明它对用户隐私的处理。比如将收集哪些信息。信息做何用途等。如果该站点的信息收集行为同用户设定的标准相符,则两者之闻关于个人隐私信息的协定就可以自动地缔结,而用户可毫无阻碍地浏览该站点;如果不符,浏览器会提醒用户,由用户决定是否对自己制定的个人隐私策略作出修改以进入该网站,双方最终通过一个双向的选择达成用户个人隐私策略。
 
    P3P策略产生了一个副作用:如果一个网站设置了有效的P3P策略,Internet Explorer允许第三方到它的Web请求自动带上Cookie。网站可能遭到CSRF攻击;如果一个网站没有设置P3P策略或者P3P策略无效,第三方到它的Web请求不会带有该网站的Cookie,反而免受CSRF攻击
 3、CSRF攻击的原理
 
    网站是通过隐式认证认证用户时,只要不关闭浏览器或者退出,以后访问相同网站时,浏览器会自动在请求中附带上认证信息。如果浏览器被其它网页控制请求了这个网站的URL,可能会执行一些用户不希望的功能。
 
    下面用例子来说明:
 
    假设某个网站(example.com)保存了用户的电子邮件地址信息.并且通过这个邮箱地址实现密码恢复等功能。网站仅采用了Cookie的隐式认证方式来验证用户.用户在验证登录后可以用如下这个URL来更改自己的邮件地址设置:http://www.2cto.com /setemail=邮件地址
 
    那么攻击者只要创建一个HTML页面包含以下代码:
 
    < IMG src=“ http://www.2cto.com /setemail = 新邮件地址”>
 
    当已经登录过example.com的用户访问这个页面的时候,浏览器就会向example.com发出请求改变用户的邮箱地址。
 
    对于所有使用隐式的认证方式并且没有采取针对CSRF攻击的自我保护措施的网站,几乎都可能存在CSRF漏洞。
 
    4、CSRF与XSS比较
 
    Cross—Site Scripting Cxssl允许攻击者将恶意代码注入到受害网站的网页上,其他使用者在观看网页时就会受到影响。这类攻击通常包含了HTML以及客户端脚本语言。
 
    CSRF与之相比区别在于:XSS攻击需要借助脚本语言,CSRF攻击则未必需要脚本语言:XSS需要受害站点接受用户输人来保存恶意代码。而CSRF攻击可能从第三方网站发起;XSS产生的主要原因是对用户输入没有正确过滤.CSRF产生的主要原因是采用了隐式的认证方式。如果一个网站存在XSS漏洞。那么它很大可能也存在CSRF漏洞。即使一个网站能够完美地坊御XsS漏洞,却未必能够防御CSRF。
 
    另外,CSRF与XSS也不是截然分开的,一个攻击可能既是CSRF攻击。又是XSS攻击。
 
    5.防范CSRF攻击
 
    为了防范CSRF攻击,理论上可以要求对每个发送至该站点的请求都要显式的认证来消除威胁。比如重新输入用户名和口令。但实际上这会导致严重的易用性问题。所以,提出的防范措施既要易于实行,又不能改变现有的Web程序模式和用户习惯,不能显著降低用户体验。
 
    5.1服务器端的防范措施
 
    (1)对于网站所有接受用户输入的内容进行严格的过滤。这条措施不止针对CSRF漏洞,而主要是减少XSS漏洞的可能性。而一个有XSS漏洞的网站,很难保证它对CSRF是安全的。这条措施是其它安全措施的基础。
 
    (2)GET方法只用于从服务器端读取数据,POST方法用于向服务器端提交或者修改数据。仅使用POST方法提交和修改数据不能防范CSRF攻击,但是会增加攻击的难度。避免攻击者简单地使用< IMG >等标签就能通过GET方法进行CSRF攻击。
 
    同时,这样做也符合RFC2616推荐的Web规范。
 
    (3)在所有POST方法提交的数据中提供一个不可预测的参数,比如一个随机数。或者一个根据时间计算的HASH值。并且在Cookie中也同样保存这个参数。把这个参数嵌入标签保存在FORM表单中,当浏览器提交POST请求到服务器端时.从POST数据中取出这个参数并且和Cook.ie中的值做比较,如果两个值相等则认为请求有效,不相等则拒绝。根据同源策略和Cookie的安全策略,第三方网页是无法取得Cookie中的参数值的.所以它不能构造出相同随机参数的POST请求。
 
    另外,为了保证一个用户同时打开多个表单页面。所有页面都能正常工作,在一次会话的有效期内。只使用同一个随机参数。也就是说,在会话初始化的时候生成一个随机参数,在以后的页面和Cookie中,都使用这个参数。直到会话结束,新的会话开始时,才生成新的参数,否则会只有用户最后一次打开的页面才能正常提交POST请求.多标签或多窗口浏览器会不能正常工作。
 
    (4)在关键的服务器端远程调用动作之前,增加人机交互环节。例如CAPTCHA人机区分识别程序㈣(典型应用如图片验证码)。
 
    (5)利用Cookie安全策略中的安全属性,但是不要完全依赖Cookie安全策略中的安全属性,只信任同源策略,并围绕同源策略来打造Web应用程序的安全性。
 
    (6)正确配置网站针对Flash的跨域策略文件。严格限制跨域、跨站的请求。
 
    5.2客户端的防范措施
 
    (1)保持浏览器更新,尤其是安全补丁,包括浏览器的Flash插件等的更新。同时也要留意操作系统、杀毒、防火墙等软件的更新。
 
    (2)访问敏感网站(比如信用卡、网上银行等)后,主动清理历史记录、cookie记录、表单记录、密码记录,并重启浏览器才访问其他网站。不要在访问敏感网站的同时上其它网站。
 

    (3)推荐使用某些带有“隐私浏览”功能的浏览器,比如Safail。“隐私浏览”功能可以让用户在上网时不会留下任何痕迹。浏览器不会存储Cookie和其它任何资料.从而CSRF也拿不到有用的信息。IE 8把它叫做“InPfivate浏览”,Chrome称作“Incognito模式”。

这篇关于同源策略以及cookie安全策略的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/940168

相关文章

在JS中的设计模式的单例模式、策略模式、代理模式、原型模式浅讲

1. 单例模式(Singleton Pattern) 确保一个类只有一个实例,并提供一个全局访问点。 示例代码: class Singleton {constructor() {if (Singleton.instance) {return Singleton.instance;}Singleton.instance = this;this.data = [];}addData(value)

Kubernetes PodSecurityPolicy:PSP能实现的5种主要安全策略

Kubernetes PodSecurityPolicy:PSP能实现的5种主要安全策略 1. 特权模式限制2. 宿主机资源隔离3. 用户和组管理4. 权限提升控制5. SELinux配置 💖The Begin💖点点关注,收藏不迷路💖 Kubernetes的PodSecurityPolicy(PSP)是一个关键的安全特性,它在Pod创建之前实施安全策略,确保P

JavaScript中document.cookie

“某些 Web 站点在您的硬盘上用很小的文本文件存储了一些信息,这些文件就称为 Cookie。”—— MSIE 帮助。一般来说,Cookies 是 CGI 或类似,比 HTML 高级的文件、程序等创建的,但是 javascript 也提供了对 Cookies 的很全面的访问权利。       每个 Cookie 都是这样的:<cookie名>=<值>   <cookie名>的限制与 javasc

缓存策略使用总结

缓存是提高系统性能的最简单方法之一。相对而言,数据库(or NoSQL数据库)的速度比较慢,而速度却又是致胜的关键。 如果使用得当,缓存可以减少相应时间、减少数据库负载以及节省成本。本文罗列了几种缓存策略,选择正确的一种会有很大的不同。缓存策略取决于数据和数据访问模式。换句话说,数据是如何写和读的。例如: 系统是写多读少的吗?(例如基于时间的日志)数据是否是只写入一次并被读取多次?(例如用户配

Flink任务重启策略

概述 Flink支持不同的重启策略,以在故障发生时控制作业如何重启集群在启动时会伴随一个默认的重启策略,在没有定义具体重启策略时会使用该默认策略。如果在工作提交时指定了一个重启策略,该策略会覆盖集群的默认策略默认的重启策略可以通过 Flink 的配置文件 flink-conf.yaml 指定。配置参数 restart-strategy 定义了哪个策略被使用。常用的重启策略: 固定间隔 (Fixe

Java后端微服务架构下的API限流策略:Guava RateLimiter

Java后端微服务架构下的API限流策略:Guava RateLimiter 大家好,我是微赚淘客返利系统3.0的小编,是个冬天不穿秋裤,天冷也要风度的程序猿! 在微服务架构中,API限流是保护服务不受过度使用和拒绝服务攻击的重要手段。Guava RateLimiter是Google开源的Java库中的一个组件,提供了简单易用的限流功能。 API限流概述 API限流通过控制请求的速率来防止

未雨绸缪:环保专包二级资质续期工程师招聘时间策略

对于环保企业而言,在二级资质续期前启动工程师招聘的时间规划至关重要。考虑到招聘流程的复杂性、企业内部需求的变化以及政策标准的更新,建议环保企业在二级资质续期前至少提前6至12个月启动工程师招聘工作。这个时间规划可以细化为以下几个阶段: 一、前期准备阶段(提前6-12个月) 政策与标准研究: 深入研究国家和地方关于环保二级资质续期的最新政策、法规和标准,了解对工程师的具体要求。评估政策变化可

面对Redis数据量庞大时的应对策略

面对Redis数据量庞大时的应对策略,我们可以从多个维度出发,包括数据分片、内存优化、持久化策略、使用集群、硬件升级、数据淘汰策略、以及数据结构选择等。以下是对这些策略的详细探讨: 一、数据分片(Sharding) 当Redis数据量持续增长,单个实例的处理能力可能达到瓶颈。此时,可以通过数据分片将数据分散存储到多个Redis实例中,以实现水平扩展。分片的主要策略包括: 一致性哈希:使用一

集群环境下为雪花算法生成全局唯一机器ID策略

雪花算法是生成数据id非常好的一种方式,机器id是雪花算法不可分割的一部分。但是对于集群应用,让不同的机器自动产生不同的机器id传统做法就是针对每一个机器进行单独配置,但这样做不利于集群水平扩展,且操作过程非常复杂,所以每一个机器在集群环境下是一个头疼的问题。现在借助spring+redis,给出一种策略,支持随意水平扩展,肥肠好用。 大致策略分为4步: 1.对机器ip进行hash,对某一个(大于

数据库归档策略

数据库迁移策略 为备战双11,需要将数据库中的相关表(历史订单)进行归档,以便腾出更多的空间迎接订单的暴增。作者经过尝试,得出自认为最优的解决方案。下面给出数据库归档策略及示例代码。 现有条件: 1.现有两个数据库:db-A 以及 db-B; 2.两个库中有字段相同的表:tba(表中只有字段订单id–rx_id(long型) 有索引); 3.归档库的tba中还有17年整年的归档数据。 4.由于单