《504.Web安全之客户端攻击与防御 论文.doc》由会员分享，可在线阅读，更多相关《504.Web安全之客户端攻击与防御 论文.doc（11页珍藏版）》请在三一办公上搜索。
1、Web安全之客户端攻击与防御摘 要Internet的繁荣给世界带来了重大的改变。“.com”成为了家喻户晓的词汇，甚至被一些电视广告用作嚼头。这种大量公司投身于Web的现象在华尔街被称为“.com爆炸”。但随着越来越多的Web服务程序和网站的开发，Web的漏洞如同雨后春笋般地出现。在Web出现之前的很长一段时间内，大多数的软件都是独立运行在单独的计算机上，或者在一个封闭的客户机-服务器环境中（非面向Internet的），人们期望Web这一开放环境能够提供给他们以往使用独立软件时的感觉是不现实的。Web不是一个封闭的、可预知的环境；这与独立的计算机或封闭的网络不通。在Web中，应用程序需要面对很
2、多的危险。诸如：多平台的客户机、缺少状态信息、未知和不可控的客户机资源，以及恶意的用户等等。一个黑客可能仅仅是通过偷看某个Web应用的合法用户存在硬盘上的cookie，而获得了他的用户ID和密码，那么即使是拥有配置完美的防火墙，貌似最安全的网络服务器也对他束手无策。因此，除了检查网站的所有基础设施已确保其安全之外，每一个安装在这些基础设施之上的Web应用都需要检查，从而保证它们没有任何安全隐患。关键词： Web安全 客户端 攻击 防御Internet has brought prosperity to the worlds major changes. . Com became a house
3、hold word, and even some television ads for chewing first. Such a large number of companies participate in the Web phenomenon known in Wall Street . Com explosion. However, as more and more Web services, programs and web site development, Web of vulnerability as sprung up. Before the advent of the W
4、eb for a long period of time, most of the software is run independently in a separate computer, or in a closed client - server environment (not for the Internet), the people expect the open Web environment can provide independent software used in the past when they felt was unrealistic. Web is not a
5、 closed, predictable environment; it closed with a separate computer or network unreasonable. In the Web, the application needs to face many dangers. Such as: multi-platform clients, lack of state information, unknown and uncontrollable client resources, and malicious users, etc. A hacker could just
6、 peep a Web application by the legal existence of the hard disk on the users cookie, and get his user ID and password, even if it is to have the perfect firewall configuration, seemingly the most secure Web server also for his wits end . Therefore, in addition to checking the site all the infrastruc
7、ture facilities have to ensure their safety, every one of these installed on the Web application infrastructure need to check to ensure they do not have any security problems. Keywords: Web Security Client Attack Defense目 录1 绪论 1 1.1 课题背景及目的 1 1.2 国内外研究状况 1 2 WEB安全概述 1 2.1 WEB安全的定义 1 2.2 WEB客户端安全面临的
8、问题 12.2.1 WEB服务器的安全 22.2.2 WEB客户端的安全 23 Web客户端的攻击与防御 23.1 客户端识别和验证 23.1.1 基于用户知道的信息knows-something方法 33.1.2 绕过客户机端的验证 43.1.3 何时使用这种攻击 53.1.4 如何实施这种攻击 54 Web客户端安全分类 54.1. ACTIVEX 64.2 JAVASCRIPT 64.3 COOKIES 64.4 Web客户端木马的实质 64.5 防御措施 7结束语 8 参考文献8 1 绪论 1.1 课题背景及目的 中国的互联网发展已进入了第二个十年，随着互联网的基础设施的建设，人们观念
9、意识的变革，互联网越来越成为人们生活中不可分割的一部分。基于互联网的Web应用如火如荼，迅速发展，各类网站数量也呈井喷式增长，随之而来的，是日益突出的安全问题。不断被发现的漏洞，黑客的恶意攻击，在网络上疯狂爬行的蠕虫，迅速扩散的病毒，盗取虚拟财物的木马，所有这一切都令人惶惶不可终日。人们一方面享受着 Web带来的好处，另一方面却要忍受着不可预料的安全威胁。本课题就是针对Web客户端与应用程序的安全问题展开讨论。 1.2 国内外研究状况 目前和相当一段时间内，国内外关于Web安全的研究主要从安全协议的制定、系统平台的安全、网站程序的安全编程、安全产品的研发、Web服务器的安全控制等方面着手。安全
10、协议的制定方面，已经提出了大量实用的安全协议，具有代表性的有：电子商务协议SET，IPSec协议，SSL/TLS协议，简单网络管理协议SNMP， PGP协议，PEM协议，S-HTTP协议，S/MIME协议等。这些协议的安全性分析特别是电子商务协议，IPSec协议，TLS协议是当前协议研究中的热点。系统平台的安全方面主要研究安全操作系统、安全数据库等，以及现有常用系统(如WINDOWS,UNIX,LINUX)的安全配置；还有就是针对黑客常用的攻击手段制定安全策略。网站程序的安全编程方面，主要研究规范化编程以及现有编程语言（ASP,ASP.NET,PHP,CGI,JSP等）的安全配置和发布增加功能
11、与安全性的新版本。安全产品的研发方面，目前在市场上比较流行，而又能够代表未来发展方向的安全产品大致有以下几类:防火墙、安全路由器、虚拟专用网VPN、安全服务器、电子签证机构CA和PKI产品、用户认证产品、安全管理中心、入侵检测系统IDS、入侵防御系统IPS等；在上述所有主要的发展方向和产品种类上，都包含了密码技术的应用，并且是非常基础性的应用。 Web服务器的安全控制方面，主要研究时下流行的Apache、IIS的安全缺陷分析与安全配置，如Apache的访问控制机制、安全模块，IIS的安全锁定等。 (摘自2 WEB安全概述 2.1 WEB安全的定义 Web安全并没有一个明确的概念。要理解web安
12、全，首先需要了解什么是web。World Wide Web，简称WWW，是英国人TimBerners-Lee 1989年发明的。通过WEB，互联网上的资源，可以在一个网页里比较直观的表示出来;而且资源之间，在网页上可以互联。因此，基于网页及网页所连接的各种资源的安全性问题就构成了web安全的实体。随着互联网与用户结合的日益紧密，web安全在如今信息化时代的意义也就显得越发重要。Web安全由于其平台的特殊性，通常归纳为网站安全、数据安全以及web平台上运行的应用安全三大类。企业要做到全面的web安全防护，不仅仅要保证企业边界安全防护，更要对企业内部网络运维进行有效的管控。然而如今的web安全现状
13、并不理想，web安全防护还没有引起企业的广泛关注，或者并不清楚如何去保证企业的web安全。(摘自2.2 WEB客户端安全面临的问题 2.2.1 WEB服务器的安全 在Web安全中，服务器的安全是最基础也是最困难的，因为服务器的源代码庞杂，如FreeBSD6.0的汇编行数达到1，271，723，OpenBSD则有1，260，7072，Windows Vista更是达到惊人的5000万行。针对Web服务器具体的安全威胁主要体现在：服务器程序编写不当导致的远程代码执行；应用程序编写不当、过滤不严格造成的代码注入，可能引起信息泄漏、文件越权下载、验证绕过、远程代码执行等；乐观相信用户输入、过滤不严格导
14、致跨站脚本攻击，在欺骗管理员的前提下，通过精心设计的脚本获得服务端Shell；针对服务器系统的拒绝服务攻击。(摘自2.2.2 WEB客户端的安全 大部分Web应用建立在一种多层客户机/服务器模型的遍体之上。不像一个独立的PC应用程序完全运行在一台单独的机器上，一个典型的Web应用由无数块代码组成（HTML、JavaScript、ASP、存储过程等），这些代码分散运行在许多机器上。图1 多层客户机/服务器设计一个攻击者基本上能设法从三个不同的入口点攻击一个Web应用，即运行应用程序中客户端部分的机器、实现客户端与相关的服务器端通信的机器和一个Web应用的服务器端（例如，应用程序服务器和它的数据库
15、服务器）。Ghosh（1998）讨论了无数电子商务的弱点，并将其分为三种攻击：客户端攻击、传输部分攻击和服务器端攻击。(摘自Web安全测试第五章客户端应用程序安全)3 Web客户端的攻击与防御3.1 客户端识别和验证对许多Web应用来说，用户在被允许使用应用程序提供的一些（或任一个）特性之前必须首先让它们识别自己。在一些系统中，这种识别可以简单到只是询问一个电子邮件地址或一个用户希望使用的假名。这些情况下，Web应用可能不会去确认用户身份的真伪大多数Web应用是不会有这种放任自由的识别方式的，它们不仅要求用户标识自己，还要验证这些表示的有效性。在Web应用的设计中，最富挑战性的共恩那个也许是设
16、计一个准确性高，同时又不会显著影响应用程序可用性或性能的用户验证机制。对于一个基于Internet的Web应用，用户可以远在国外并且使用各种各样的客户端硬件和系统软件，这就绝对不是一项小任务了。大部分Web应用基于三种不同的技术确保用户真实性：基于用户知道的某些东西（例如密码）、基于用户拥有的某些东西（例如物理上的钥匙）或者基于用户自己的一些物理特性(例如指纹)。这三种策略都可以通过不同的方法实现，每一种方法都以不同的方式在成本、易用性和准确性之间权衡。一种验证机制的准确性可以用两种方法度量：请求识别的合法用户被系统拒绝的概率（有时被称作错误拒绝率（false rejection rate）和
17、未经授权的用户欺骗系统，以致系统误认为他们是合法而允许他们使用的概率（有时被称作错误接受率（false acceptance rate）。遗憾的是，得到一个低的错误接受率（坏家伙很难进入）往往会导致一个高的错误拒绝率（好人往往被拒之门外）。例如，增加用户密码中的字母数量可以提高攻击者猜出密码（或者破解出来）的难度，但这也会增加合法用户忘记信息的概率。与错误拒绝的风险相比，有关错误接受的风险将更为严重。一次错误接受可能允许入侵者横行霸道，尽情使用系统错误授予他们的任何应用特权。尽管个别的错误接受不太重要，但随着时间的推移，大量的错误接受积累在一起将会显著影响应用。例如，一家银行如果需要复杂南极的
18、密码，其Web应用的用户操作就会变得十分复杂，那么这家银行的顾客采纳率就会明显低于其竞争者。这将导致更多的顾客转去支行或者使用电话银行（这两种服务成本都较高），从而使竞争者有机会节省成本。从测试的角度看，测试者应该努力测定某Web应用的错误接受率和错误拒绝率是否在应用的设计者（和用户）当初设定的范围之内。另外，因为不能保证某个具体的验证技术是否正确执行，所以验证所使用的方法应该经过评估，以确保验证过程本身不会受到破坏（例如，某个攻击者能够窃听在网络上发送的未加密的密码）。(摘自Web安全测试第五章客户端应用程序安全)3.1.1 基于用户知道的信息：knows-something方法这种验证策略
19、要求用户提供一些被认为只有真正用户才知道的信息，以验证用户身份。标准的用户ID和密码组合到目前为止是这种验证策略最流行的执行方法。这种验证方法表现形式多种多样，包括询问用户一个隐私问题（例如“你母亲的娘家姓是什么？”）或者要求用户提供一个有效的信用卡号以及相应的账单地址信息。与应用层用户ID及密码相关的问题和那些与影响系统软件的用户ID及密码相关的问题非常类似，不过在用户ID和密码执行方面，那些已经发展了一些属于自己的应用程序的企业灵活性更高。特别是企业可以选择自己执行的规定比那些在外面卖主发展产品中逐步形成的规定更严格 更不严格。例如，企业可以检查用户选择的任何不在字典中出现的新密码，或者可
20、以试试单用户单机器政策（也就是说，用户不能登陆一台以上的机器，并且一台机器不能同时支持一个以上用户）。因此，出了所列的用户ID清单外，测试组可能还想根据应用程序安全规范中的说明考虑将表1中的一些或者全部测试加进去。表1 应用程序的用户ID和密码测试列表是否描述应用程序是否禁止用户选用常见（因此容易被猜出来）的单词作为密码应用程序是否禁止用户选用不耐用（因此容易被破解）的密码，例如那些仅有4位字母的密码应用程序是否强制用户每个几周就改变一次密码应用程序是否强制用户针对不同的级别使用不同的密码应用程序是否允许同一台客户机上的多个用户同时访问应用服务器应用程序是否允许一个用户从多台客户机上同时访问应
21、用服务器验证方法的错误拒绝率可以接受吗？是否用寻求帮助找回遗忘密码的次数来衡量错误拒绝率认证发发的错误接受率可以接受吗？例如，在不提供额外信息的情况下，每10000次机会攻击者就有1次可以才对一个4位数字的密码(摘自Web安全测试第五章客户端应用程序安全)3.1.2 绕过客户机端的验证对用户输入进行验证，是所有的软件开发人员需要面对的一个大问题，不论开发的是Web应用程序还是通常的桌面程序。但是，不同于传统的应用程序，Web应用程序让用户更加直接地体会到这些认证是如何进行的。如果验证的信息是比较敏感的，那么最好还是在服务器端进行再一次的验证。多数时间里，输入认证是由用户界面控件进行的，注入下拉
22、菜单，它限制了用户的输入范围。使用这些控件（在客户机端）的好处是：输入认证过程迅速，并且产生的错误消息也可以得到更加准确的反映，用户输入错误的同时就可以及时发现。有些情况下，完全信任用户界面控件对输入进行的限制是不合适的，也是不大可能的。以电子邮件地址为例。通常的格式为nameorganization.type。开发人员希望验证用户输入的是正确的电子邮件地址。问题就在于电子邮件地址的灵活性很强，特别是当Web应用程序试图根据name、domain以及type等字段对地址进行分类时。这里，我们以两个电子邮件地址为例。Mike.andrews和jwcs.fit.edu。其中没有一个完全符合通常的
23、电子邮件地址格式。仅仅采用用户界面上的一些控件来验证用户是否输入了合法的电子邮件地址，是非常困难的一项工作。也可以让用户自由输入，然后将结构发送到服务器端进行验证，但是这又引发了两个新的问题。第一点就是性能：在客户机和服务器之间反复传送数据，需要耗费时间和贷款，进而会影响所有已连接至服务器的用户。第二点是可用性：用户都希望在自己输入ul错误的数据时，马上就得到错误报告（即所谓的“错误定位”）。这样，用户就可以即使修正自己的错误，并且重新提交数据。为了实现以上目的，可以在客户机端先完成输入认证的最初步骤。这就是脚本产生的原因。脚本是一种将本地的错误消息快速返回给用户的实现方法。可供Web应用程序
24、开发人员使用的脚本语言和相应的环境有很多种，其中最常见的就是JavaScript。JavaScript是基于时间驱动模型的，当用户动作时（诸如指针从输入域中医开、点击某个按钮，或者其他的“事件”），客户机端就执行相应的脚本。客户机端的脚本可以完成大量的工作，脚本最重要的功能就是对用户输入的数据进行验证。但是我们必须注意在客户机端执行的验证是什么类型的，并且我们要时刻提醒自己，在客户机端发生的任何时间都可能被恶意用户攻击。除了JavaScript，Web应用程序开发人员广泛使用的两一种机制是隐藏域。对隐藏域的实际验证过程是在服务器端进行的，但是如果要在客户机端修改或者删除这些验证，也是常容易的。
25、比方说，下面就是使用Web应用程序开发环境ColdFusion来验证表格中数据的典型方法：ColdFusion可以利用这种方法完成很多验证过程。每个需要验证的表格单元都有一个隐藏域，它们具有相同的名字，但是在一条下划线后紧跟这验证的类型，诸如：这段代码在服务器端确保了“数量”这一表格单元中填写的是一个整数。3.1.3 何时使用这种攻击要想知道一个页面中是否包含了脚本是非常容易的，因为在HTML源代码中或者在其他的包含文件中（通常带有一个.JS后缀名）会有相应的标记。更长的脚本包含在标签中（有时会附加一些其他的属性，告诉浏览器当前的脚本语言类型和版本号），不过还可以在其他的HTML标签中添加脚本
26、，只要在前面加入“javascript”或其他相应的前缀脚本是由页面中控件的“事件”进行驱动的。注入浏览器完成页面下载（OnLoad）、用户焦点从某个域中医开（OnBlur），或者将表单数据提交到服务器（OnSubmit）等等。如果你看到了标签或者On*属性，客户机端就很有可能在进行某种数据验证。这个时候，就需要检查一下在服务器端是否对数据进行了再次验证。如果您的 Web应用程序运行在ColdFusion服务器上，您就会更加希望使用隐藏域，而不是脚本。3.1.4 如何实施这种攻击测试人员希望了解客户机端在执行那些验证，并且将其删除，看看服务器上是否对其进行了再次验证。如果没有执行两侧验证，就需
27、要进行相应的BUG报告。有以下两种方法可以实现以上目标。第一种是禁止浏览器进行脚本语言的解释和执行。可以通过修改浏览器的设置完成，也可以使用扩展工具，类似Chris Pederick的Web开发人员为Firework设计的工具条（第二种移除客户机端验证的方法是进行选择性的禁止。采用和尚一种攻击类似的方法，可以将页面存储到本地及，通过修改HTML源代码的方式删除验证过程，最后重新加载页面。只要将本地存储的页面副本中相应的On*处理部分删除，并且将相对URL路径改写为绝对的URL路径（正如在上一攻击中描述过的那样），就可以达到目的。如图2所示。（摘自Web入侵安全测试与对策-第三章-攻击客户机）4
28、 Web客户端安全分类4.1. ACTIVEX ActiveX是Microsoft开发的，用来从因特网上自动下载可执行的机器代码的技术、协议和API的集合。 ActiveX控件能完成下载病毒、安装木马到格式化硬盘等一系列的危险操作，对此的安全对策是在访问网站时只安装经过认证的普遍使用的ActiveX控件。实际操作是在IE的Internet选项中安全下选择中级。4.2 JAVASCRIPTJavaScript被设计为通过浏览器来处理并显示信息，但它不能修改任何文件中的内容。也就是说，它不能将数据存放在Web服务器或用户的计算机上，更不能对用户文件进行修图2 使用PageSpy将JavaScrip
29、t从输入控件中移除改或删除。因此，JavaScript不会破坏服务器或客户机上的任何文件，也不可能被用来编写破坏计算机上资源的计算机病毒。JavaScript的漏洞通常仅仅破坏用户的隐私。避免这种安全隐患的一个要点是不去浏览一些不可信任的网站。4.3 COOKIES Cookies是帮助Web站点维持用户状态的一种机制,从技术上而言，Cookies实质上是HTTP的Header的一个选项。Cookies本身由纯文本字符串组成，能够读入游览器的内存中，并在必要时候返回给服务器端5 。Cookies的主要作用是在客户端保存用于和服务器交互的用户信息。Cookies也因此而被Internet广告商滥
30、用，为使用者展示“个性化”的广告。我们可以通过在浏览器中禁用Cookies来避免个人信息被收集，当然这样会造成一些网站功能的使用问题。4.4 Web客户端木马的实质目前的大多数站点，包括网上银行、网上商店、论坛和网上书店都都易于受到某种客户端木马骗术的攻击，之所以这样说，是因为他们都缺乏相应的保护机制。要想弄明白如何设计一个没有此类弱点的web站点，我们首先需要熟悉问题本身。当某人浏览我们的站点时，我们通常为用户生成一个web页面，其中包括一些提示用户可在本站点进行哪些活动的URLs和表单(下文将以“要约”这个词来加以指代)。客户端木马战之所以得逞，就是因为攻击者有可能以我们的名义向被害者提供
31、这些URLs和表单，这是问题的根本所在。为了消除这种威胁，我们必须保证用户是根据我们而绝非其他人所提供的URL和表单来采取行动的。许多开发人员都认为Referer header是一个用来确保访问者来自我们的站点的法宝。一般情况下，Referer header不该用于安全，因为它毕竟来自于客户端：记住，客户端总能造假。但是，用它来对付客户端特洛伊木马还是管用的但是，处于保护隐私的考虑，站点经常将Referer headers过滤掉，因此在完全合法的请求中，通常是找不到Referer headers的，所以我们必须寻找一个不用检测Referer headers的办法。还有一个办法，就是每当用户执行
32、修改某些东西的动作时，都对用户进行重新认证。这种解决方案需要对客户端提供的每个表单都增加一个口令字段。不幸的是，提供口令是一件非常烦人的事情，所以我们将尝试其它方案。4.5 防御措施为了预防客户端木马攻击，开发人员应该实现一个“检票系统”。这个系统的核心在于一些不可预测的随机数，我们称之为票据，它的工作机制如下所示：web页面通常用一个或多个要约来完成一个有副作用的动作。对于每个这样的要约，都会为其生成一个随机字符串并与该要约相关联：如果该要约是一个表单的话，可以用一个隐藏的字段来存放该票据;如果该要约是一个链接，那么可以把票据附加到URL参数列表中。对于产生的每一个票据，都为其添加一个字符串
33、来为其所指动作命名，并将这个字符串存放于接收该要约的用户的session的“票据池”中。例如，对编号为1234的单据的删除进行确认这一动作，动作名为“delnote-1234”，其票据被表示为“c90624gHu”，那么该字符串将被存为“delnote-1234-c90624gHu”。如今，我们在客户端和服务器端都有了一个相同的票据。每当从用户那里收到一个要求执行动作的请求时，就从该请求中提取票据。然后，将要执行的动作的名称加在票据前面，并在票据池中查找匹配项。如果找到了匹配的票据，那就说明该要约是由您的Web 站点所提供的，这时就执行动作，并从票据池中删掉这个票据。检票系统之所以管用，是因为
34、攻击者无法猜出你已经给客户了哪些票据值，同时他们也无法将票据插入受害者在服务器端的票据池。然而，这里有两个问题需要注意。首先，如果您在GET请求中包含了票据，那么它们就会变成URLs的一部分，如果点击了一个从您的站点到其它Web服务器的链接的话，票据就有可能通过Referer headers泄漏出去了。如果你的web页面包含来自其它站点的图像或者其它的对象的话，也会导致Referer报头的泄密问题。如果您使用了独一无二的票据，并且每次请求之后都没有忘记把它从票据池中删除的话，这就不会有问题了。GET请求通常不用于对数据有任何改动的动作，所以，我们根本就不需要在这样的请求中使用票据。此外，如果你
35、的应用程序容易受到跨站点脚本攻击的攻击，那么该系统就会失效，原因是如果攻击者能在你的服务器生成的页面内插入JavaScript代码的话，他就能从该页面提取票据。并且，他还能诱骗浏览器进行一些需要两步完成的事情：第一步去请求一个票据，然后在用户不知道的情况下使用该票据。如您所见，要想防止客户端木马战术，我们必须进行一些额外的程序设计工作，并且还得动一番脑筋看来Web开发是越来越有挑战性了，必须在开发之初就充分考虑安全问题。（摘自 Web应用客户端的木马攻击详解-太平洋电脑网Pconline-网络安全栏目）5 结束语攻击者可以目标站点的名义出现在受害者面前，并欺骗他们做一些从未打算要做的事情。要约
36、可以 是URL或自动提交的表单，并且这些要约可以通过任何可用的信道进行传播，比如电子邮件，以及目标站点之外的Web页面等。为了保护Web 站点及其用户免受客户端木马战术的滋扰，Web开发人员必须实现一些专门的安全机制。遗憾的是，到目前为止，这些机制还没有得到普遍应用，所以许多站点都存在这方面的漏洞。参考文献及引用1(美)Mike Andrews James A.Whittaker著.汪青青译.Web入侵安全测试与对策. 清华大学出版社,2006.102(美)Steven Splaine 著.李昂 等译.Web安全测试.机械工业出版社，2003.5.13 Web应用客户端的木马攻击详解（太平洋电脑网Pconline-网络安全栏目）4567 Web时代客户端正在成为黑客攻击重点ZDNET安全频道
