《白帽子讲WEB安全》

看书过程中一些摘抄和不理解之处的记录。

1、浏览器安全

恶意网址拦截:常见的恶意网址分为两类:一类是挂马网站,这些网站通常包含有恶意的脚本如JavaScript或Flash,通过利用浏览器的漏洞(包括一些插件、空控件漏洞)执行shellcode,在用户电脑中植入木马;另一类是钓鱼网站,通过模仿知名网站的相似页面来欺骗用户。

2、跨站脚本攻击(XSS)

1)跨站脚本攻击:英文全称是Cross Site Script,本来缩写是CSS,但是为了和层叠样式表(Cascading Style Sheet,CSS)有所区别,所以在安全领域叫做“XSS”。

2)XSS根据效果的不同可以分为以下几类:

    第一种类型:反射型XSS。反射型XSS只是简单地把用户输入的数据“反射”给浏览器。也就是说,黑客往往需要诱使用户“点击”一个恶意链接,才能攻击成功。

    第二种类型:存储型XSS。存储型XSS会把用户输入的数据“存储”在服务器端。这种XSS具有很强的稳定性。比较常见的一个场景就是,黑客写下一篇包含有恶意JavaScript代码的博客文章,文章发表后,所有访问该博客文章的用户,都会在他们的浏览器中执行这段恶意的JavaScript代码。黑客把恶意的脚本保存到服务器端,所以这种XSS攻击就叫做“存储型XSS”。

    第三种类型:DOM Based XSS。实际上,这种类型的XSS并非按照“数据是否保存在服务器端”来划分,DOM Based XSS从效果上来说也算是反射型XSS。单独划分出来,是因为DOM Based XSS的形成原因比较特别。发现它的安全专家专门提出了这种类型的XSS。出于历史原因,也就把它单独作为一个分类了。通过修改页面的DOM节点性成果的XSS,称为DOM Based XSS。

3)初探XSS Payload

一个最常见的XSS Payload,就是通过读取浏览器的Cookie对象,从而发起“Cookie劫持”攻击。Cookie中一般加密保存了当前用户的登录凭证。Cookie如果丢失,往往意味着用户的登录凭证丢失。换句话说,攻击者可以不通过密码,而直接登录进用户的账户。

4)强大的XSS Payload

XSS攻击后,攻击者除了可以实施“Cookie劫持”外,还能够通过模拟GET、POST请求操作用户的浏览器。这在某些隔离坏境中会非常有用,比如“Cookie劫持”失效时,或者目标用户的网络不能访问互联网的情况。

同时,大部分攻击者是不知道用户的“Old Password”的。为了窃取密码,攻击者可以将XSS与“钓鱼”相结合。实现思路很简单,利用JavaScript在当前页面上“画出”一个伪造的登录框,当用户在登录框中输入用户名与密码后,其密码将被发送至黑客的服务器上。

在很多时候,攻击者为了获取更大的利益,往往需要准确地收集用户的个人信息。比如,如果知道用户使用的浏览器、操作系统,攻击者就有可能实施一次精准的浏览器内存攻击,最终给用户电脑植入一个木马。XSS能够帮助攻击者快速达到收集信息的目的。最直接的是通过XSS读取浏览器的UserAgent对象,但是由于浏览器的UserAgent是可以伪造的,所以还可以通过分辨不同浏览器之间的差异准确地判断出浏览器版本。

知道了用户使用的浏览器、操作系统后,进一步可以识别用户安装的软件。在IE中,可以通过判断ActiveX控件的classid是否存在,来推测用户是否安装了该软件(这种方法很早就被用于“挂马攻击”)。浏览器的扩展和插件也能被XSS Payload扫描出来。

另外一个有趣的XSS Payload:通过CSS,来发现一个用户曾经访问过的网站。但是Firefox在2010年3月底决定修补这个问题。

一般来说,XSS 攻击需要借助第三方软件来完成。比如,客户端安装了Java环境,那么XSS就可以通过调用Java Applet的接口获取客户端的本地IP地址。

5)变废为宝:Mission Impossible

从XSS漏洞利用的角度来看,存储型XSS对攻击者的用处比反射型XSS要大。因为存储型XSS在用户访问正常URL时会自动触发;而反射型XSS会修改一个正常的URL,一般要求攻击者将XSS URL发送给用户点击,无形中提高了攻击的门槛。而有的XSS漏洞,则被认为只能够攻击自己,属于“鸡肋”漏洞。但随着时间的推移,数个曾经被认为是无法利用的XSS漏洞,都被人找到了利用方法。

6)流行的浏览器都内置了一些对抗XSS的措施,比如Firefox的CSP、Noscript扩展,IE8内置的XSS Filter等。

7)区分安全的“富文本”和有攻击性的XSS

3、跨站点请求伪造(CSRF)

1)浏览器的Cookie策略

浏览器所持有的Cookie分为两种:一种是“Session Cookie”,又称“临时Cookie”;另一种是“Third-party Cookie”,也称为“本地Cookie”。两者的区别在于,Third-party Cookie是服务器在Set-Cookie时指定了Expire时间,只有到了Expire时间后Cookie才会失效,所以这种Cookie会保存在本地;而Session Cookie则没有指定Expire时间,所以浏览器关闭后,Session Cookie就失效了。在浏览网站的过程中,若是一个网站设置了Session Cookie,那么在浏览器进程的生命周期内,即使浏览器打开了Tab页,Session Cookie也都是有效的。Session Cookie保存在浏览器进程的内存空间中;而Third-party Cookie则保存在本地。如果浏览器从一个域的页面中,要加载另一个域的资源,由于安全原因,某些浏览器会阻止Third-party Cookie的发送。

4、HTML5安全

过去在浏览器里能够存储信息的方法有以下几种:Cookie、Flash Shared Object、IE UserData。

其中,Cookie主要用于保存登录凭证和少量信息,其最大长度的限制决定了不可能在Cookie中存储太多信息。而Flash Shared Object和IE UserData则是Adobe与微软自己的功能,并未成为一个通用化的标准。因此W3C委员会希望能在客户端有一个较为强大和方便的本地存储功能,这就是Web Storage。

5、注入攻击

注入攻击是Web安全领域中一种最为常见的攻击方式。XSS本质上也是一种针对HTML的注入攻击。

1)SQL注入

盲注:所谓“盲注”,就是在服务器没有错误回显时完成的注入攻击。服务器没有错误回显,对于攻击者来说缺少了非常重要的“调试信息”,所以攻击者必须找到一个方法来验证注入的SQL语句是否得到执行。

6、文件上传漏洞

在大多数情况下,文件上传漏洞一般都是指“上传Web脚本能够被服务器解析”的问题,也就是通常所说的webshell的问题。要完成这个攻击,要满足如下几个条件:首先,上传的文件能够被Web容器解释执行。所以文件上传后所在的目录是要Web容器所覆盖到的路径。其次,用户能够从Web上访问这个文件。如果文件上传了,但用户无法通过Web访问,或者无法使得Web容器解释这个脚本,那么也不能称之为漏洞。最后,用户上传的文件若被安全检查、格式化、图片压缩等功能改变了内容,则也可能导致攻击不成功。

7、应用层拒绝服务攻击

应用层DDOS:CC攻击,“CC攻击”的前身是一个叫fatboy的攻击程序,当时黑客为了挑战绿盟的一款反DDOS设备开发了它。绿盟是中国著名的安全公司之一,它有一款叫“黑洞”的反DDOS设备,能够有效地清洗SYN Flood等有害流量。而黑客则挑衅式地将fatboy所实现的攻击方式命名为:Challenge Collapasar(简称CC),意指在黑洞的防御下,仍然能有效完成拒绝服务攻击。

防御应用层DDOS:

在一般情况下,服务器端应用可以通过判断HTTP头中的User-Agent字段来识别客户端。但从安全性来看这种方法并不可靠,因为HTTP头中的User-Agent是可以被客户端篡改的,所以不能信任。

一种比较可靠的方法是让客户端解析一段JavaScript,并给出正确的运行结果。因为大部分的自动化脚本都是直接构造HTTP包完成的,并非在一个浏览器环境中发出的请求。但有的自动化脚本是内嵌在浏览器中的“内挂”,就无法检测出来了。

除了人机识别外,还可以在Web Server这一层做些防御,其好处是请求尚未到达后端的应用程序里,因此可以起到一个保护的作用。

资源耗尽攻击:凡是资源有“限制”的地方,都可能发生资源滥用,从而导致拒绝服务,也就是一种“资源耗尽攻击”。出于可用性和物理条件的限制,内存、进程数、存储空间等资源都不可能无限制地增长,因此如果未对不可信任的资源使用者进行配额的限制,就有可能造成拒绝服务。内存泄漏是程序员经常需要解决的一种bug,而在安全领域中,内存泄漏则被认为是一种能够造成拒绝服务攻击的方式。

Server Limit DOS        Web Server 对HTTP包头都有长度限制,以Apache举例,默认是8192字节。也就是说,Apache所能接受的最大HTTP包头大小为8192字节(这里指的是Request Header,如果是Request Body,则默认的大小限制是2GB)。如果客户端发送的HTTP包头超过这个大小,服务器就会返回一个4xx错误。加入攻击者通过XSS攻击,恶意地往客户端写入了一个超长的Cookie,则该客户端在清空Cookie之前,将无法再访问该Cookie所在域的任何页面。这是因为Cookie也是放在HTTP包头里发送的,而Web Server默认会认为这是一个超长的非正常请求,从而导致“客户端”的拒绝服务。

推荐阅读更多精彩内容