浏览器中拦截Web攻击的研究

王 丽，钱文祥

(安徽理工大学计算机学院，安徽 淮南 232001)

微软推出Internet Explorer 3 之时便同时开放了WebBrowser 给开发者使用，开发者可以在自己的程序中使用WebBrowser 控件以实现与浏览器类似的功能。

截至2014年，服役13年之久的Internet Explorer 6 由于安全性不足引发了人们的关注。微软也多次劝告用户升级至更高版本的浏览器。在版本6 之后的浏览器中，Internet Explorer 一直在增添新的安全功能。Internet Explorer 8 中，微软加入了基于请求字串的XSS 检测功能和对反点击劫持的HTTP 头的支持;之后，Internet Explorer 9、10、11 几个版本加入了进程层面的安全特性，例如加入硬件执行保护、代码地址随机化、安全异常处理链以及浏览器的64 位化。但是浏览器作为脚本宿主，针对脚本攻击却没有更多的安全提升。因此，为了用户的数据安全，有必要为其定制安全功能。

1 攻击检测

由于网页中代码和数据的界限不明，导致了很多注入类的攻击手段，针对脚本注入的跨站脚本请求攻击(Cross Site Scripting，XSS，由于和层叠样式表缩写一样，被改称为XSS)。而浏览器自身的实现，将导致表示层的攻击，利用视觉欺骗的攻击点击劫持则是这类攻击。而网站自身实现的不完善，则将导致其他针对网站的攻击，例如浏览器中可以实现的跨域请求伪造(Cross Site Request Forgery，CSRF)。

而超文本标记语言是一个语法宽松的语言，在HTML 标签的“属性=值”对中，有很多字符会被浏览器丢弃，即使加入了也不影响执行。Internet Explorer 支持的VBScript 和Javascript 中，存在更多的编码方式。由于对脚本的支持，字符和函数还可以通过Javascript 的重载和库函数、系统事件、对象强制转换等方式获得。

1.1 XSS 的动态检测

由于XSS 属于脚本注入，而且由于浏览器支持信息的多样化，攻击者注入的脚本采用普通字符比对方式将难以检测。因此，将采用正则表达式，在用户发出请求时进行动态检测并修正。

程序将在Internet Explorer 自带的检查之外再次做额外的检查。主要检测方式是针对请求字串在正文写入的位置进行判断，对非文本节点通过Boost 库的TR1 正则表达式引擎对请求内容进行正则匹配，实现扫描。通过导出mshtml.dll 中的字符串组，可以得到Internet Explorer 自带的库，对其自带的库进行判断分析之后，可以知道其无法防御的攻击方法，接着，针对这些内容完善补充正则表达式即可防御攻击者的防御。

使用时，如果用户访问的请求匹配到了正则表达式，那么提示用户可以选择过滤或是继续访问。如果用户选择过滤，程序将动态删除攻击向量，达到动态清除攻击向量的作用。新增的正则表达式如表1所示。

表1 新增的正则表达式

1.2 CSRF 的动态检测

CSRF 属于网站侧的实现缺陷，因此，浏览器只能协助减少危害，而并不能保证消除所有危害。CSRF 攻击主要依靠同源准则来检测，程序不仅会应用较为严格的同源策略，还会对请求实体进行XSS 检查，使用的XSS 判断方式如上节所述。之所以加上这类检测是因为IE 自带的XSS 过滤器其实只会对GET 请求进行检查，而POST XSS 在某种程度上也是一个危害较大的攻击方式，尤其是配合上CSRF，一样可以达到同样的危害。所以，如果浏览器的POST 请求中发现了XSS 攻击代码，浏览器将同样会对POST 的实体部分进行净化，然后询问用户是将POST 转换为GET 请求，还是将POST 丢弃。软件的同源判断逻辑如表2 所述。

表2 软件的同源判断逻辑

1.3 点击劫持的动态检测

在浏览器中有一个特性，即如果样式表中存在opacity 属性，那么元素在浏览器中显示的顺序将不会再以其z-index 大小来判定，而是使用一个特殊的判断逻辑:谁的opacity 大，谁显示的时候排在前面。

但是，同一个位置的元素的事件接受函数将依然使用z-index 来判断，如果一个位置上有多个元素，而这个位置上发生了某个事件，那么这个位置上的元素中谁的z-index 大，谁就会接收到这个事件。

因此，要实施点击劫持攻击，攻击者最容易的是只通过iframe 框架的方式来加载被害网站，而且通常是设置iframe 全透明或者透明度非常大，以至于几乎无法看见，通常是0%～1%的情况比较多。然后，在iframe 上方覆盖一层虚假页面，例如“点击某处开始游戏”的页面，而要求用户点击的地方实际上覆盖在下方iframe 中一些敏感位置，例如微博的“关注”按钮等位置。

因此，攻击者攻击时，只需要指定下方iframe的样式为高z-index 和低opacity，给自己伪造的内容的样式指定为低z-index 和高opacity，那么就可以创建一个点击劫持页面。

点击劫持页面的特性也正是检测的突破口所在。通过遍历元素的样式表，找到存在opacity 属性的iframe，并对其进行逻辑检查，从而以最小的报警次数获得较为准确的判定结果，发现攻击后，程序将删除元素的透明元素，从而将真实页面内容展现给用户。

2 程序效率和分析

用系统函数可以得到较为精准的时间量，测试中选用CPU 时间/CPU 时钟频率来获取经过时间。据此可以得出算法从开始处理数据到处理结束(不包括对话框弹出的等待时间)额外消耗的时间。试验3 次，取平均值，得出耗时数据如表3所示。

表3 基准耗时测试结果

需要注意的是，页面完全载入时间指页面完全下载的时间，不包括DOM 树渲染的时间。网络时间采用IE 的开发人员工具。

安全模块对用户浏览时产生的可感知的影响极小，也即用户几乎无法感知到模块加载前后浏览时间上的差异，从而不会产生由于用户觉得安全模块过于拖慢显示速度从而关闭安全模块的事情。安全模块的执行效率也会因此直接影响用户浏览网页时的安全性。

而需要大量操作元素的Clickjacking 模块，事实上并不会对用户浏览造成影响。因为攻击者攻击浏览器时产生的页面元素通常都非常少，否则将不利于攻击代码的传播，因此过滤时大部分都将仅对大约20 个左右的元素进行操作。

而IE 浏览器在实现直接通过IHTMLDOMNode 接口操作浏览器元素的方法时，其做的具体操作是，将对应的DOM 节点从IE 的节点二叉伸展树上移除，然后将元素对应的类从内存中删除。这一操作具体实现起来资源开销是十分少的。

以下测试结果是在程序冷启动(开机后第一次运行)下，开启对应标签后5 秒时的资源情况。每个标签的占用数据均包括标签和主程序，用后者减去前者除以标签差量得出单个标签的占用，最终全部加起来除以总标签差量得到平均每个标签的占用。后单页内存消耗方法与此相同，内存增量测试结果如表4所示。

表4 内存占用增量测试结果 KB

标签内占用的内存大部分是由IE 窗口导致的，而相对内存增量则是保护模块和IE 自身共同作用带来的增量，这可以部分反应模块对浏览时内存增加所带来的贡献。

浏览器自身就是一个资源密集型程序，如果模块贡献了过多的内存增量，那么对用户使用来说将是不利的。但是上述测试可以发现安全模块并没有贡献出过多的内存占用。

在日常使用过程中内存占用是有一定波动的，在实际测试和理论验证中内存增量并不会太多。事实证明这还是一个简单易行而且对用户机器资源消耗较少的方法。

控制内存增加的主要办法是，尽量多利用栈上内存，必要时才在堆中分配，因为栈上内存结构简单，不像堆中各个堆块数据都有不少字节用于维护堆表信息。而这两种内存都将在函数函数结束时及时释放，所以对用户来说，内存只是一个短期的增长。而一段时间后内存不断增长主要还是因为IE 自身的实现机制，与模块并无多大联系。因此本保护模块可以实现使用少量内存占用实现安全功能。

3 结语

浏览器中添加安全模块是一种自由、可定制的轻便服务形式。同时，采用模块化的防护函数可以保证在现今产品主程序迭代较慢的情况下达到产品的迅速迭代性，进而可以及时防御互联网攻击，具有十分重要的现实性意义，这是目前产品开发所流行推崇的研究开发方向。

对互联网上存在的攻击，在浏览器层面给用户添加一层额外的保障，可以让用户在浏览互联网时更加安心、省心。同时，人性化的设计也可以照顾到各个层次的互联网使用者，浏览器可以在安全和易用性上可以做到一个好的平衡点。随着互联网的进步和技术水平的提高，在未来，可以预见的是将有更多的互联网威胁，同时也会有更多的安全保护措施的诞生，安全防护意在提升黑客攻击的门槛，同时给予用户更好的互联网浏览体验，从而推动整个行业的发展。

［1］CHRISTIAN KANAMUGIRE.A Client-Side Solution Against Session Hijacking Through Xss Attacks［D］.长沙:中南大学，2012.

［2］温凯，郭帆，余敏.自适应的Web 攻击异常检测方法［J］.计算机应用，2012(7):2 003-2 006.

［3］徐少培，姚崎.基于操作劫持模式的Web 攻击与防御技术研究［J］.信息安全与通信保密，2011(1):86-89.

［4］张伟，吴灏，邹郢路.针对基于编码的跨站脚本攻击分析及防范方法［J］.小型微型计算机系统，2013(7):1 615-1 619.

［5］WADE ALCORN，CHRISTIAN FRICHOT，MICHELE ORRÙ.The Browser Hacker’s Handbook［M］.America:John Wiley ＆ Sons，Inc.，2014.

［6］MICHAL ZALEWSKI.Web 之困——现代Web 应用安全指南［M］.北京:机械工业出版社，2014.

［7］MICHAEL SUTTON，ADAM GREENE，PEDRAM AMINI.模糊测试——强制性安全漏洞发掘［M］.北京:机械工业出版社，2009.

［8］PACO HOPE，BEN WALTBER.Web Security Testing Cookbook［M］.America:O’Reilly Media，2008.

［9］王文君，李建荣.Web 应用安全威胁与防治-基于OWASP Top 10 与ESAPI［M］.北京:电子工业出版社，2009.