分类目录归档:WEB安全

Linux系统安全_PFS/ECDH

数百万网站和数十亿网民都依靠SSL保护敏感数据如密码、信用卡号码和个人信息的传输。但最近泄漏的机密文档显示,美国国家安全局会记录大量互联网流量,储存加密数据以用于以后的密码分析。美国当然并不是唯一一个这么做的国家,沙特、中国和伊朗都是如此。保留的加密数据可以通过各种方法解密,例如法庭命令,社会工程,网站攻击,乃至密码分析。如果得到了密钥,所有相关网站的历史流量可以一次性解密。这就像打开了潘多拉的盒子。然而,互联网实际上存在应对之策——密钥协商协议Perfect Forward Secrecy(PFS),如果SSL网站的私钥泄漏,PFS可以保护以前的加密流量不会因此受到影响,因为PFS可以为每次会话分配不同密钥加密通信。PFS需要客户端浏览器和服务器端同时支持才适用。–solidot.org

但问题也不止如此,当HTTPS的网站的私钥被攻破,那么攻击者便可以很容易的制造出了中间人攻击。 这便需要一种向前的保密协议。

该协议要求,今天的秘密即使在将来的密钥被泄露,而秘密也是不被泄露的。要理解这个协议,我们首先可以从经典的TLS三次握手AES128-SHA加密套件开始,在握手期间,服务器出示证书,客户端和服务器同意主密钥。

这个过程是建立在48个字节的预置密码,是由客户端使用服务器公开的密钥进行生成和加密。然后在三次握手的过程中,客户端将密钥信息交换发送给服务器。主密钥来自客户端与服务器进行hello会话的公钥与随机值。这个方案是安全,只要服务器能够对预置的密码解密(自己的私钥)客户端发送的数据。假设,攻击者记录该服务器1年内的所有客户端和服务器之间的交流数据。2年后,服务器退役,并送往循环再造,攻击者是能够恢复出磁盘驱动器的私钥。根据这个私钥,便可以对会话进行解密。攻击者依然可以恢复密码和其他敏感信息。

现在主要的问题一个事实,私钥被用于2个目的,认证服务器加密服务共享同一个密钥。认证只是在建立通信时,而加密则持续数年之久。

为了解决这个问题的方法之一便是保持使用私钥进行验证,但是要使用一个共享密钥的独立机制。Diffie-Hellam密钥交换协议,在TLS是如何工作的呢,服务器只需要生成1次:

1 P,是一个很大的素数,

2 g,是一个原根primitive root(它能生产1~P-1所有数的一个数)

3 现设g为p的原始根,则: g mod p,g^2 mod p,…g^p-1 mod p;两两互不相同,构成一个1~p-1的全体数的一个排列。

4 对于任意数b以及素数p的原始根g,可以找到一个唯一的指数i,满足b = g^I mod p,0C=i<=p-1,则称指数i为以g为底,模p的b的离散对数。

算法描述为:

假如A和B在不安全的网络上进行协商共同的密码:

因为不安全的线路上,窃听者只能得到a,p,X,Y,除非能够计算离散对数x和y,否则将无法得到密钥k,因为k是A和B独立计算出的密钥。有Xa,Xb计算出Ya,Yb容易,但反过来由Ya,Yb计算出Xa,Xb很难。安全性上基于求有限域上求离散对数的难度。

但DH算法却容易遭中间人攻击。

为了避免中间人的攻击,构造出了基于有限域上椭圆曲线之间的同源计算问题构造细腻的公钥密码系统。

假设y^2 = X^3 + ax +b,素数p和原始根g,这些参数都是公开的,事实上,它可以有服务器生成。

利用椭圆曲线是在RFC-4492中TLS延伸的部分描述的。与经典的DH交换密钥的方法不同,在客户端和服务器端需要同意各参数。完成本协议是在客户端和服务器发送hello的消息内,虽然可以定义任意一个参数,WEB浏览器将只支持少数的预定义的曲线,通常为NIST P-256,P-384,P-521.

下面简要说一下,DH的密钥交换椭圆曲线:

 

使用ECDHE-RSA-AES128-SHA加密套件(例如P-256)已经是很程度上提高了速度。也是因为DHE-RSA-AES128-SHA缩小所涉及的各种参数的规模。

但不是所有浏览器都支持椭圆曲线加密,最近的chrome和firefox支持了NIST P-256, P-384, P-521.但大多数的IE浏览器还支持的不是很好。,最近的openssl已经加入了ECDHE密码服务套件,如果要使用64位的优化本版本,需要选择OPENSSL 1.0.1,启用ec_nistp_64_gcc_128选项。

在选择套件上,ECDHE-RSA-AES128-SHA:AES128-SHA:RC4-SHA是大多浏览器所兼容的。如果要选择PFS的方式,ECDHE-RSA-AES128-SHA,DHE-RSA-AES128-SHA,EDH-DSS-DES-CBC3-SHA。但需要确保密码套件的顺序。Nginx (1.0.6/1.1.0)是ssl_prefer_server_ciphers。Apache(2.3.3)则是SSLHonorCipherOrder。

但在使用PFS的时候,也要注意服务器端定期更新所生成的随机密钥。

Openssl的检测使用指令:openssl s_client -tls1 -cipher ECDH -connect 127.0.0.1:443

Nginx 关于PFS的代码:

使用RSA算法的时候,产生一个临时的DH密钥磋商发生,这样会话将根据这个临时的密钥加密。而证书中的密钥作为签名。这样增加了安全性。

该方法实现了OPENSSL提供的默认DH_METHD,实现了根据密钥参数生成DH公私钥,以及根据DH公钥(一方)以及DH私钥(另一方)来生成一个共享密钥,用于密钥交换。

ECDH参数不完全和DH一样,对与DH所产生参数是一个耗时的过程,所以服务器允许通过外部文件加载DH参数。ECDH的参数的形成是一套硬编码的曲线,所以参数的形成只是寻找他们,当服务器使用时,便可以加载他们。但在openssl1.0.2之前是不支持的。

可以做的是,提供ECDH参数从一个文件里读取,为了一个共同的组的一个后备。P-256是一个不错的选择则。

而这个设置不需要在服务器端进行设置,而使用的参数是有服务器端指定。

Linux系统安全_sandbox_seccomp-bpf

        linux3.5以后linux支持了Will Drewry的Seccomp-BPF的特性。Seccomp-BPF是建立在能够发送小的BPF(BSD Packet Filter)程序,有内核来执行。这个特性起先源于tcpdump的设计,因为性能的原因,可以直接在内核中运行。BPF相对与内核是不可信的,因此, 限制了有限的数量。值得注意的是,他们不能循环,限定单一函数的执行时间,以及大小,并允许内核知道他们的永远终止。

BPF(BSD Packet Filter)是一种用于Unix内核网络数据包的过滤机制。Linux之前包过滤LPF。Linux随着版本的不同,所支持的捕获机制也有所不同。2.0之前的内核版本,对Socket使用类型SOCK_PACKET,调用形式是Socket(PF_INET,SOCK_PACKET,int proctol),但这种用法已经过时,2.2之后,提出的一种新的协议簇,PF_PACKET来实现捕获机制,调用形式为:socket(PF_PACKET, int socket_type, int protocol),其中socket类型可以是SOCK_RAW,和SOCK_DGRAM,SOCK_RAW 类型使得数据包从数据链路层取得后,不做任何修改,直接传递给用户数据,而SOCK_DGRAM,则要对数据包进行加工(cooked),把数据包的数据链路层头部去掉,而使得一个通用结构sockaddr_ll来保存链路信息。

使用2.0版本内核捕获数据包存在多个问题,首先,SOCK_PACKET方式使用结构sockaddr_pkt来保存数据链路层信息,该结构缺乏包类型信息;其次,如果参数MSG_TRUNC传递给读包函数recvmsg, recv, recvfrom 等,则函数返回的数据包长度是实际读到的包数据长度,而不是数据包的真正长度。

PF_PACKET方式规避上以上的问题,在实际应用中,用户程序显然希望直接得到“原始”数据包,因此使得SOCK_RAW类型最好。Libpcap使用的SOCK_DGRAM.从而也必须为数据包合成一个“伪”链路层头部(sockaddr_ll).1,某些类型的设备数据链路层头部不可用,例如linux 内核的ppp协议,实现代码对ppp数据包的支持的不可靠,2在捕获设备为any时,所有设备意味着libpcap对所有的接口进行捕获。需要要求对所有数据包有相同的数据链路头部。具体的详细描述:http://www.linuxjournal.com/article/4852

    BPF是一种过滤机制,有网络阀(Network tap)和过滤包组成,网络阀用于从网卡设备驱动处收集网络数据包拷贝,并负责向已注册监听的用户态应用程序递交数据,过滤器则是用于决定收集的网络数据是否满足过滤器要求,满足条件的则进行后继的拷贝工作,否则丢弃该数据。

    该图的过程为:当数据包到达网络接口时,链路层的设备驱动程序通常是将数据包直接传送给协议栈进行处理。而当BPF在该网络接口注册监听时,链路层驱动程序将数据包传送给协议栈之前,先会首先调用BPF。BPF负责将此数据包指针传递至每个监听进程指定的内核过滤器,这些用户自定义的过滤器决定数据包是否被接受,以及数据包中的那些内容将被接受,对于每一个决定接受数据包的过滤器,BPF此时才进行数据拷贝工作,将所需的数据拷贝至于过滤器相连的缓冲区中,以供用户监听进程读取。数据拷贝结束后,网络设备驱动程序重新获得系统控制权,系统进行正常的网络协议处理。我们注意到BPF是先对数据包过滤,在缓冲,避免了类似SUN的NIT过滤机制,先缓冲每个数据包直到用户读取数据时在过滤造成的效率问题。

    BPF 的设计思路和当时的计算机的硬件发展有大关系,相对较老的CSPF(CMU/Stanford Packet Filter)它有两大特点,1 :基于寄存器的过滤机制,而不是早期的内存堆栈过滤机制,2:直接使用独立的,非共享的内存缓冲区。同时,BPF在过滤算法上也有很大进步(有人也做了一些优化BPF+),它使用了无环控制流图(CFG,control flow graph).而不是老式的布尔表达式树(Boolean expression tree)。

下面说一下BPF的包过滤模式:

    包过滤可以看作是针对数据包的布尔函数运算。如果返回值为真,那么内核为监听程序拷贝数据,反之则丢弃。形式上包过滤由一个或者多个谓词判断的AND操作和OR操作组成。

    包过滤在具体的实现上是通过将数据包简单的看作一个字节数组,谓词判断根据具体的协议映射到数组的特定位置进行判断过滤工作。例如,判断数据包是否是ARP协议,只需要盘点数组的第13,14个字节是否为0×0806。因此,包过滤的算法的中心任务,是使用最少的判断操作。

    布尔表达式树理解上比较直观,它的每一个叶子结点即一个谓词判断,而非叶子结点则为AND或OR操作。而CFG算法是一种特殊的状态机,图中每一个非叶节点代表的是对数据包进行谓词判断操作,而边则是判断的结果。在CFG中,只存在2个叶子结点,分别代表过滤通过True和未通过Flase。
CSPF主要有3个缺点,1:过滤操作使用的栈在内存中被模拟,维护栈指针需要使用若干的加/减等操作,而内存操作时现代计算机架构的主要瓶颈。2:布尔表达树造成了不需要的重复计算。3不能分析数据包的变长头部。BPF使用的CFG算法,实际上是一种特殊的状态机,每一个节点代表了一个谓词判断,而左右分别对应了判断失败和成功后的跳转,跳转后又是谓词判断,这样反复操作,直到到达成功或失败的终点。CFG算法的优点在于把对数据包的分析信息直接建立在图中。从而不需要重复计算。CFG是一种“快速的,一直向前”的算法。

BPF包过滤模式的实现,BPF采用了一种过滤器伪机的方式(filter Pseudo-machine)。BPF伪机器方式是一个轻量级,高效的状态机。对BPF过滤代码进行解释,BPF过滤机过滤代码形式为”opcode jt jf k”,分别代表了操作码和寻址方式,判断正确的跳转和失败的跳转,以及操作所使用的通用数据域。

    BPF过滤代码从逻辑上看,很类似汇编语言,但它实际上是机器语言,注意到上述的3个域的数据都是int和char型。显然,有用户来写过滤代码太过于复杂,但这种设计更适合用于操作硬件。特别用来编写需要写少量固定序列的硬件驱动程序。BPF实际上是一组基于状态机匹配的过滤序列,用于简单的数据包模式匹配。用指令集简单的将上图描述如下:

    每个匹配包至少包含4个元素,定义为一个结构体如下:

    其很显然应该是一个状态驱动的循环:

看看linux实现的代码,基本上是这样实现的。

    BPF用于很多的抓包程序,在linux中,一般内核自动编译进了af_packet这个驱动,因此只需要在用户态配置一个PACKET的socket,然后将filter配置进内核即可,使用setsockopt的SO_ATTACH_FILTER 命令,这个filter是在用户空间配制的,比如tcpdump应用程序,tcpdump和内核BPF过滤器的关系类似iptables与netfilter的关系,只是Netfilter实现了match/target的复合配合,而BPF的target则只是选择是否要与不要。

    回到主题上来,seccomp-bpf在使用BPF的时候,借鉴了其思想。
大量的系统调用暴露在用户空间,在程序的整个生命周期内并没有使用。而随着系统调用的改变和成熟,bug的发现和根除,一套可用的系统调用是满足用户程序基本的调用。将可以产生出一组尽量少的系统调用暴露在用户空间。系统调用的过滤就是在应用程序的使用中。

Seccomp过滤器提给了一种手段,为一个进程调用系统调用时指定了过滤器,而这个过滤器则是BPF。BPF作为socket过滤器不同之处则是操作当前的user_regs_struct数据结构,这需要预先定义好系统调用的ABI和定义过滤规则。但系统调用的参数保存在用户空间,但要验证该参数是否安全是非常困难的。

    Seccomp用户无法避免TOCTOU (time-of-check-time-of-use)系统调用对框架的注入式攻击。如一个恶意进程可能会在“参数被安全检查”之后,而在实际使用之前,将参数换掉,这边使节或系统调用时所作的参数检查变得没有意义。但要解决这个问题,也不能仅把目光盯住系统的调用入口。

针对系统调用的过滤,不是一种沙箱的模式,其更多的提供了减少内核暴露的表面,除此之外,需要和其他的规则和方案进行配合。
当seccomp模式被添加,但它们不是直接设置超时的过程,是一种新的模式, 仅当CONFIG_SECCOMP_FILTER设置,并用prctl启用PR_ATTACH_SECCOMP_FILTER参数。
与seccomp过滤器交互式通过prctl调用。
PR_ATTACH_SECCOMP_FILTER ,允许一个新的过滤器使用BPF程序的规范,BPF程序将被执行user_regs_struct结构的数据。用法为

WEB安全_浏览器安全_sandbox

  浏览器SandBox

google chrome 是一个采取多进程架构的浏览器,主要进程分为:浏览器内核进程,渲染引擎进程,插件进程,扩展进程等。这里针对google 开源chromuim进行说明。

Chromium允许渲染进程运行在Sandbox里,这样即便代码存在漏洞被网页利用了,也不会对系统造成威胁。

关于sandbox的安全机制,伯克利和斯坦福大学的研究学者们做了一个很好的论文,下面就泛泛的结合他们的论文谈一下。他们的论文题目为:《The Security Architecture of the Chromium Browser

》。

chromium 拥有2个模块来保护域安全,

browser kernel:其是和操作系统交互的。

rendering engine 渲染引擎,在沙箱中运行,限制权限。

1 简介

浏览器内核模块的行为代表用户,而渲染引擎模块代表网页,模块运行在单独的保护域,通过执行沙箱,降低了渲染引擎的权限。即使攻击者利用未修补漏洞的渲染引擎,获得整个渲染引擎沙箱的特权,也可以防止攻击者读写用户的文件系统

浏览器的安全策略,像同源策略一样复杂,可以说这种细粒度的隔离难以不破坏现有的网站,用户又要求其兼容性,为了兼容,一个模块化的浏览器必须要支持整个网络的平台。

浏览器的内核是负责管理持久性的资源,如cookie ,password database;以及用户和操作系统交换,接收用户的输入,并绘制到屏幕上,这个架构是基于以下2点的设计:

1)   该体系架构必须要兼容现有网络,具体而言,安全性限制网站的结构应该是透明的,这样的设计决策,极大的限制了整个体系结构的范畴。

2)    该体系结构将渲染引擎作为黑箱,将未解析的HTML作为输入,并将产生位图输出,尤其是该体系架构依赖于渲染引擎来执行同源策略,这样的设计降低了浏览器内核安全监控的复杂性,因为浏览器内核只需要执行粗粒度的安全增强便可以,例如,浏览器内核赋予对上传整个实例到渲染引擎的能力,这种特权值只需要单个的安全 “源”,

这种架构不能防止攻击者妥协渲染引擎从而攻击其他站点,(如读取其cookie);相反,该结构体的目的是房子读写用户的文件系统,从而帮助用户避免恶意软件侵袭。

为了评估chromium的安全性,我们选取离开IE,Firefox,Safari的漏洞统计,来确定那些漏洞会影响到chromium,发现其中67%的会发生在渲染引擎的地方。

chromium的体系结构为了减轻严重漏洞的危险,重新严格限定了攻击者使用浏览器内核的接口。测试了代码执行的漏洞会发生在浏览器内核中,其中72.7%的漏洞会利用充分验证的系统调用,而不是减轻了附加的沙箱。如,利用一个不当转义的Shell Execute弱点去攻击浏览器的外部协议。虽然这些弱点的统计不是很完善,但这些结果,让我们相信chromium的体系结构,适当的划分l浏览器内核和渲染引擎的浏览器组件。

     将浏览器分为2个保护区域,一个表示用户而另一个则是网页,chromium的安全体系架构可以减轻月70%的浏览器关键漏洞和攻击者执行的代码,其余的漏洞则归为沙箱来处理,这样架构可以充分利用沙箱的安全优势,又能够保持性能和现有的web的兼容性。

     首先采取的是三管齐下的措施来考量其兼容性,首先是通过完成99%的10115次兼容webkit的测试,第二人工访问了500个最为流行的网站来发现其不兼容性,第三通过已经部署的上以百万的用户反馈。

2威胁模型

为了表示chromium的安全属性,我们定一个枚举攻击者的能力和目标威胁模型,这个安全体系结构旨在防止攻击者为了达到目标所拥有的能力,我们可以利用这个威胁模型来评价chromium的架构如何有效的保护用户免受攻击。

(一)hacker的能力:我们认为攻击者知道一个未打补丁的安全漏洞在用户的浏览器上,并能够利用用户的浏览器渲染恶意的内容,通常,这些能力足够威胁用户的及其,更为具体的说,我们假设攻击者具备以下能力:

1)   攻击者拥有一个域名,如attacker.com 。这个域名还未添加到浏览器的恶意软件的黑名单中,攻击者拥有一个有效的https的证书域,并在网络上控制至少一台主机。具备这些能力只需5美元

2)   攻击者可以说服用户访问他的网站,这是很难的价格来衡量这种能力,但在以前的研究中,能吸引一季度100万用户只需要50美元左右

3)   攻击者利用利用一些exploit,攻击一些未打补丁的可以执行任意代码漏洞的用户浏览器,如HTML解析器的缓冲区溢出,正则表达式库的证书溢出,或书签的缓冲区溢出。

(二)范围内目标,chromium架构侧重于防止攻击者从三个高度实现目标:

1)   持续的恶意软件,攻击者试图在用户计算机上安装恶意软件,如:安装一个僵尸网络的客户端,接收命令,在网络中工作或协同其他用户参与网络工作。

2)   键盘记录器,攻击者监视用户的击键,用来盗取用户密码和隐私数据。需要在用户没有关闭浏览器才能生存。

3)   文件盗取,攻击者企图获取用户磁盘上的敏感数据

如果攻击者能够实现这些目标的一个或多个,将会给用户造成严重的危害,chromium的体系架构目的是防止攻击者的这种能力

三) 范围外的目标,有很多攻击者的目标是chromium体系机构不提供的额外保护,chromium包含一定的特性低于这些危险,这些特性依赖渲染引擎执行的”同源策略”

1)   网络钓鱼,在钓鱼攻击中,攻击者使用一些技巧让用户进入一个不城市的网站,并提供了自己的密码。攻击者利用未修补的漏洞可以创建一个说服钓鱼网站破坏一个窗口显示真实的网站。

1)chromium具备多项安全功能减轻网络钓鱼攻击,浏览器突出显示网站域名,已知钓鱼网站的安全警告,以及额外的安全性用户界面元素。

2)   “源隔离” chromium的架构 渲染引擎将会对整个网络站点为主进行渲染,意味这渲染引擎可以代表整个网站,例如,攻击者利用代码执行漏洞获得cookie,存储在浏览器内密码,如果攻击者不能利用这些未修补的漏洞,通常浏览器的安全策略防止攻击者读取coolie或密码,主机名不在他的控制下。

3)   防火墙规避,同源策略是限制攻击者的访问是在浏览器内,防火墙规避旨在保护机密资源。

4)    网站的漏洞,如果网站包含xss,csrf,以及header注入等,这些需要网站必须修复其脆弱性。 chromium支持httpOnlyCookies来缓解部分XSS

3 chromium架构

 

chromium结构有2个模块,渲染引擎和浏览器内核,在一个较高的水平,渲染引擎负责转换HTTP响应和用户输入事件转换为呈现的位图,而浏览器内核则负责用户操作系统进行交互,内核的浏览器公开API,渲染引擎使用网络发出请求,访问持久化存储,并显示在用户的屏幕上的位图。浏览器内核是值得用户信任的,而渲染引擎则是值得网页信任的。

(一) 渲染引擎,渲染引擎解释执行网页内容提供的默认行为,如绘制<input>元素,和服务调用DOM API,呈现的网页进行了几个阶段,1 开始与解析,建立一个在内存的DOM表示,奠定了图形化的文件和操作文件,解析脚本指令,渲染引擎也负责限制同源策略,着有助于防止恶意网站中断用户和真实的网站会话。

                                                              (表1)

      渲染引擎         

      浏览器内核

      HTML 解析     

  cookie数据库

      CSS 解析        

      历史访问数据库

      图像解码         

      密码数据库

      js解释器         

      窗口管理

      正则表达式      

      地址栏

      布局               

      安全浏览黑名单

      文档对象模型   

      网络协议栈

      渲染             

      SSL/TLS

      SVG               

   磁盘缓存

      XML解析        

      下载管理

      XSLT              

      剪贴板

BOTH

URL 解析

unicode解析

(一)渲染引擎,包含拉大部分浏览器的复杂性和佳和最直接的与不可信网页内容,例如大多数的解析发生在渲染引擎,包括HTML解析,图像解码,js解析。为了与用户,本地主机,网络交互,渲染引擎使用了浏览器内核的API,渲染引擎运行在操作系统限制的沙箱中。

(二)浏览器内核,浏览器内核负责管理多个实例的渲染引擎和实施的浏览器内核API,例如,浏览器内核实现了基于选项卡的窗口系统,包括地址栏,显示当前处于获得的URL选项卡,及其相关的安全指标,浏览器内核管理的持久化状态,如用户的书签,cookie,并保存密码,它还负责与网络进行交互与渲染引擎与操作系统的原生窗口管理器之间的中介,为了实现它的API,浏览器内核维护状态信息的权限,并据此向每个渲染引擎,如允许上载文件的列表的每个渲染引擎,浏览器内核使用这些安全策略防止渲染引擎被攻破后与用户操作系统的隔离。

驱动的浏览器组建分配的任务还有一些是为了兼容性遗留的,比如浏览器内核负责js alert警告,select下拉菜单则有渲染引擎, 某些功能,如cookie数据库还是有浏览器内核实现的,因为它直接访问文件系统,正则表达式则有渲染引擎来实现,因为他对性能是敏感的,而且有常见的安全漏洞。

正如表1所示,渲染引擎负责对于大多数的分析和加密,因为历史上,这些任务已经发生大量的源漏洞,例如,要显示一个网站的快捷图标,在浏览器用户界面,浏览器内核网络检索图像,但并不实体进行解码,相反,浏览器内核发送图像用于解码的渲染引擎,渲染引擎响应一个未压缩的图标的位图,其中浏览器内核将其复制到屏幕上,这个看似复杂的步骤,有助于防止攻击者利用一个未修补的图像解码器漏洞控制浏览器内核。这种模式的一个例外是网络协议栈,HTTP协议栈是负责解析HTTP响应头和调用gzip或bzip2解码器解压缩,这些内容编码HTTP响应,这些任务分配给渲染引擎,在成本上复杂的网络堆栈和降低性能。而URL需要浏览器内核和渲染引擎都去解析,因为URL处理无处不在。

(三)进程粒度:粗略的说,chromium使用一个单独的实例为每个标签开启一个渲染引擎,显示的内容从网页,在渲染引擎崩溃的情况下提供容错。使用渲染引擎提供受信证书的解析,如HTTPS 证书错误的警告,然而,这些渲染任务是有一个单独实例的渲染引擎,不处理从网络上获得的内容。主要的里外这种模式是web检测器,他显示信任呈现的内容和有渲染引擎显示的网页,chromium采用这种设计,因为WEB检测器交互广泛的页面检查。

插件 – chromium的架构中,每个插件运行在一个单独的主机进程中,单独于渲染引擎和浏览器内核,为了兼容现有网站,浏览器插件无法在渲染引擎里运行,因为供应商期望插件最多有一个实例的插件在web 浏览器。如果插件驻留在浏览器内核,插件的崩溃,就足够崩溃了整个浏览器。在默认的情况下,每个插件运行在沙箱以外,而且用户具有完全访问的权限,这个设置将保持现有的插件和网站,因为插件可以有任意行为,如flash 播放器插件可以控制用户的microphone和webcam,以及用户的文件系统,此设置的限制是,攻击者可以利用未修补的插件漏洞在用户计算机上安装恶意软件,供应商可以写入chromium的sandbox,能为用户提供更到范围的防外挂攻击,chromium还有一个选项,以现有的插件在sandbox中运行,要做到这一点,chromium提供一些安全设置,–safe-plugins 在命令行中设置。此设置只是实验性的,可能导致不稳定或以外现象

4沙箱

 

为了帮助抵御攻击者利用一个chromium渲染引擎的弱点,每个渲染引擎都在sandbox中,sandbox限制了渲染引擎的在运行过程中的系统调用,这些系统调用可以帮助用户达到目标。

(一)目标: 在理想状态下,sandbox会迫使渲染引擎使用浏览器内核的API与外界进行交互,许多DOM方法,如appendChild方法。在渲染引擎中实现简单的状态改变以及完全改变,在DOM方法中,XMLHttpRequest方法需要渲染引擎做的不仅仅是内部状态,一个可信的渲染引擎可以使用浏览器内核的接口来实现这些方法,sandbox目标是需要一个妥协的渲染引擎来使用浏览器内核与用户和文件系统交互。

(二)实现:当前,chromium的特定功能-sandbox渲染引擎,为了替代基于windows安全口令的方法,渲染引擎使用了Restricted Token的安全令牌的方法。每当渲染引擎试图访问一个安全对象时,Windows安全管理器会检查渲染引擎的安全令牌是否有足够的权限访问该对象。sandbox这种严格限定渲染引擎安全引擎的安全检测方法几乎在每一次这样的访问中。

(三)在渲染web协议栈。渲染引擎调整其进程的安全令牌,将安全标示符SID设置为DENY_ONLY,并添加一些严格的SID和调用AdjustTokenPrivileges函数。渲染引擎一样可以运行在一个单独的桌面中,以用来减轻安全性检查不严的WINdows API。如 调用 SetWindowsHookEx,限制一些有用无安全问题的对象,如 HWND_BROADCAST,这些目前仅限于桌面。此外,渲染引擎在windows作业对象上,限制了渲染引擎创建进程,读写剪贴板,访问用户处理的能力。

四) 限制: 虽然sandbox 限制和妥协渲染引擎交互操作的一些能力,但sandbox本身还有一些限制

1)   FAT32: fat32不支持访问控制列表,没有访问控制列表,windows的安全管理器会忽略进行的安全令牌。

2)   错误的配置对象:如果一个对象有一个NULL DACL(Discretionary access control list),在windows 安全管理器将授予访问权限,而不考虑访问的安全性令牌,虽然NULL DACL是涵见的,但一些第三方应用程序会创建NULL DACL对象,在NTFS文件系统中,问题大大减少,因为这种限制在沙箱中的删除权限,“跳过安全遍历”,迫使windows渲染引擎能够访问到目标文件的父目录。

3)TCP/IP 理论上讲,渲染引擎在Windows XP创建一个SOCKET 套接字,因为低级别的系统调用打开一个套接字,不需要操作系统执行访问检查,然而,通常win 32为库函数在创建套接字时失败,因为这些API是渲染引擎无法捕获的。我们试图建立一个POC(Proof-of-concept),在sandbox中进程无法打开套接字。在Vista中,有关的系统调用会执行安全访问检测,

 5 浏览器内核接口

 

sandbox渲染引擎限制直接与底层操作系统交互的能力。如用户交互持续性存储和网络,渲染引擎依赖与浏览器内核的API,在提供函数给渲染浏览器功能时,一定要仔细设计不授予没有必要的权限,特别是浏览器内核不能设计成泄漏读写用户文件系统的能力。

(一)用户交互: 操作系统交互的接口,允许应用程序与用户进行交互,但这些接口没有设计要使用不受信任的程序,如 X windows 系统,以创建一个窗口的 X server,意味着监视所以用户的击键,浏览器内核是渲染引擎的中介,以协助执行2个安全约束与用户互动。

1)   渲染。不是给与渲染引擎直接访问一个窗口的句柄,渲染引擎引入一个离屏位图。要显示位图给用户,渲染引擎发送的位图给浏览器内核,浏览器内核复制位图到屏幕上。这种设计增加拉一个单独的屏幕,如一般的绘图到屏幕是通过内存拷贝到内存管道,其中有一个类似的双缓冲性能的影响,以及所呈现的位图浏览器窗口的内存区域。

2)   用户输入,而不是传送用户输入直接到渲染引擎,操作系统提供这事件给浏览器内核,浏览器内核调度这些事件定位当前用户界面元素。如果焦点在chrome浏览器上,输入事件则有浏览器内核处理,如果该内容具有焦点时,浏览器内核将输入时间交个渲染引擎,本设计利用用户的焦点来限制用户的输入事件给渲染引擎。

(二)持久性存储:sandbox的责任是确保渲染引擎的责任是不能直接访问用户的文件系统。然而,渲染引擎不需要一些用户的文件上传和下载

1)   上传,用户可以将文件上传到网站,需要上传控制,当用户点击表单控件,浏览器显示一个文件选择的对话框,让用户选择上传的文件,如果浏览器内核不限制文件,渲染引擎可以直接上传,攻击者利用渲染引擎便会读取用户文件系统的文件

chromium采用了类似DarpaBrowser的powerbox模式,处理用户的选择,授权到同一个文件选择对话框的文件上传文件到任意网站,浏览器内核负责显示文件对话框和记录文件的用户已授权渲染引擎的历史,同样当文件拖放到浏览器的内容,渲染引擎积极渲染上传的授权文件。

2)   下载,当下载文件时,一个网站允许写入到用户的文件系统,不是直接的写入文件系统,而渲染引擎使用浏览器内核的API下载,为了保护文件系统,浏览器内核下载到指定的下载目录,此外浏览器内核黑名单的某些文件名,渲染引擎可以用它来提升权限检测,如设备名,文件名,本地扩展,shell集成的文件名,如:desktop.ini

(三) 网络 而不是直接访问,渲染引擎检索通过浏览器内核从网络中检索URL,在一个URL请求提供服务,渲染引擎检查浏览器内核是否授权的URL,网络的URL协议如http,https,FTP,可以请求每个实例的渲染引擎。浏览器内核防止大多数渲染引擎请求URL的方案,因为一个有漏洞的渲染引擎可以读取用户磁盘驱动器的各种文件的URL。

6 chromuim 源代码下载

 

获得chromuim源代码的方法如下:

           1 安装gclient工具:

获得 depot_tools:git:

添加depot_tools 路径 PATH:$ export PATH=”$PATH”:pwd/depot_tools

也可以添加到. bashrc 文件中。

2) 下载代码

7 chromuim 源代码举例

以上是POC的一段代码,由于分析代码不是本文的主题,这里就不深究下去了,此章只是想让大家了解浏览器安全的问题。
除了上面的安全问题,还有恶意网址拦截等安全问题,这里就不再分析下去了

WEB安全_浏览器安全_同源策略

1 概述

本文是走入Linux操作系统系列的其中一篇,本文主要是针对近期关于web安全检测的一些学习和体会,web安全的关心范畴来自于web开发人员,测试人员,安全运维人员,以及互联网的另一头所谓的小黑们。WEB的应用逐渐成为互联网的核心,WEB的安全技术也在兴起,对web安全的问题爆发也越来越流行。
2011年末,一场有CSDN密码泄漏用户数据的事件掀起了一场血淋淋的个人密码泄漏大幕。跟随着网x,xx网,天x,猫x等大型网站的爆库现象,用户的用户名和密码便在互联网上随意下载,一时风声鹤唳,草木皆兵。

2 前言

2011年的那场爆库现象,警方也得出结论,模糊的记得其中2条(与本文不太相关,没有深究其准确性),一是安全意识不够,管理不规范。二是没有使用国家规定安全级别的操作系统。安全问题大都是出自对安全意识问题,如:你的密码在各大网站注册的时候,无论是用户名和密码都是一样的,甚至是你的邮箱。邮箱问题很是严重,因为很多网站是通过邮箱找回密码的,邮箱破解了,很多你的个人秘密和利益都被破解了,当然这其中有一部分属于社会工程学范畴。

一篇文章不能把web安全相关的东西讲的很全面,但我想还是将一些比较重要的东西说出来比较好,这样可以丰富大家的知识。写一篇文章要参考了很多书籍和资料,这里推荐大家的资料为:《The.Web.Application.Hacker’s.Handbook.Finding.and.Exploiting.Security.Flaws,.Stuttard,.Pinto,.2ed,.Wiley,.2011》,当然这本中文翻译本也有了,《黑客攻防技术宝典:Web实战篇(第2版)》 china-pub 地址为:http://product.china-pub.com/3662840 。《白帽子讲WEB安全》。

 3WEB安全发展历程

 

说起安全就会想起hacker这个词,hacker这个词的褒贬暂且不提,对于hacker来说,不想拿到root的hacker不算好hacker,在hacker的行业里,有人分为2种黑客,一种是玩exploit(精通计算机技术,挖掘漏洞编写exploit),另一种是玩脚本的(对攻击本身感兴趣,编程技术不是很高)。在国内存在者一些功利性比较强的黑客,与本主题无关这里闭而不谈。

黑客帝国想必大家都看过吧,其中有很多镜头,如下图:

其中这张图利用到了常见的nmap和ssh,以及一个sshnuke的exploit。最近韩国的幽灵电视剧也有很多镜头显示黑客们利用exploit的技能。但现在的电视剧上关于黑客的镜头大多是无厘头的,cd,ls什么的,便可以入侵了。有点玄乎。

Web安全问题的兴起在web1.0时代,关注服务器动态脚本的安全问题,如webshell(将可执行脚本上传到服务器)。

SQL注入以及XSS的威力也逐步被大家重视,在web2.0时代,XSS以及CSRF的危险则更强大。

上图是2007-2011年web应用安全事件的统计表。

要全面的认识一个安全问题,首先要明白安全问题组成的属性,有人提出了安全的三个要素:机密性,完整性以及可用性,后来有人补充了可审计性和不可抵赖性等要素。

设计安全方案,要做到以下几点:

     1 能够有效的解决问题

     2 用户体验好

     3 高性能

     4 低耦合

     5 易于扩展和升级

安全问题的发展历程也不是短短百十字能描写清楚,HTML5以及云计算的爆发,对web安全要求越来越高,下面从理论性上简单的了解一下web安全的问题。

 4 脚本安全

4.1 浏览器安全

浏览器是互联网的最大入口,每个浏览器都有自己的安全特性,而同源政策的一种安全约定是浏览器最为核心也最为基本的安全功能。web是建在同源策略的基础之上,浏览器则是同源策略的一种实现。

4.1.1同源策略

什么是同源策略?

同源策略是指浏览器会阻止从一个域上加载的脚本获取或者操作另一个域上的文档属性,也就是说,受到请求的URL的域必须与当前的WEB页面的域相同,否则浏览器会主动隔离来自不同源的内容。这一种同源策略,限制了不同源的”document”或脚本。

同源是指:同协议,同域名,同端口,host(域名或IP地址,如果是IP地址可以当作子域名)

他的精髓很简单,它认为任何站点装载的信赖内容是不安全的,当被浏览器半信半疑的脚本运行在沙箱时,它们应该之被运行访问来自同一站点的资源,而不是那些来在其它站点可能怀有恶意的资源。

需要注意的是,对于当前页面来说,页面内存放的javascript文件的域并不重要,重要的是加载js的页面所在的域是什么。如

a.com通过以下代码加载b.com上的b.js。但js是运行在a.com页面中。

a.com的index页面调用b.com的b.js。b.com的index也同样调用b.js.该测试按钮的作用显示当前的href页面。

<script type=”text/javascript” src=”http://www.b.com/b.js”></script>,其测试效果如下:

这个是a.com的测试效果,显示为www.a.com。

而这个则是b.com的测试效果,显示的为www.b.com。

测试的效果显示,其中b.js的脚本是在a.com的页面中运行。因此对于当前页面a.com来说,b.js的源则是a.com;而不是b.com;

测试代码如下:

b.js内容:

同样的对于<script>,<img>,<iframe>,<link>等标签都可以跨站加载资源,而不受同源策略的限制,实际上这些带”src”属性的标签每次加载时,是由浏览器发起一次GET请求。不同与XMLHttpRequest的是,通过src属性加载的资源,浏览器限制了javascript的权限,使其不能读写返回的内容。

点击测试按钮

而在站a.com则会出现,其中返回错误状态码为0。B1.txt没有取到

可以看的出,XMLHttpRequest 受到同源策略的约束,不能跨域访问资源。

测试代码如下:

b.js loadXMLDoc;

xmlHttptest.html code: b.com的代码。a.com域的代码类同。

但,随着互联网的发展,跨域请求的需求越来越多,W3C委员会制定了针对XMLHttpRequest跨域访问标准。他需要通过目标域返回的HTTP头来授权是否允许跨站访问,由于HTTP对与js来说一般是无法控制的,所以认为这个方案是可以实施的,但注意,可以跨域的方案的安全基数是信任”Javascript无法控制该HTTP头”。如果此信任被打破,则方案也将不在安全。

以下将在chrome上实现跨域访问的实验

点击测试按钮,结果如下:

这个测试需要在服务器端进行修改http header,使其支持Access-Control-Allow-Origin协议。

我们可以抓取http报头信息看到:

http://www.b.com/test.php?url=http://www.b.com/b1.txt

 

———————————————————

下面将贴出测试代码:

需要修改b.js的loadXMLDoc(url)函数体的地方

需要使用php修改header的代码

如果使用的其他语言实现,需要使用request.addheader方法实现,IE8需要使用XDomainRequest的方法。

跨域的风险是要注意的,ajax一般不允许跨域,也要根据不同的浏览器设定了。跨域容易引起第三方的恶意安全注入,网络攻击者(“中间人攻击”) 可能篡改服务器响应内容从而可能攻击你编写的扩展内容。

对于浏览器而言,除了DOM,Coookie,XMLHttpRequest受到同源策略的限制外,第三方插件也有各自的同源策略。如 flash,JAVA Applet等。

同源策略也会有很多漏洞,这里就不再深究下去了,有兴趣的可以查阅互联网