首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 计算机考试 > 软件考试 > 复习指导 >

系统数据——跨站脚本攻击XSS解析(2)

2009-02-27 
跨站脚本的名称源自于这样一个事实,即一个Web站点可以把他们的选择的代码越过安全边界线注射到另一个不同的、有漏洞的Web 站点中。当这些注入的代码作为目标站点的代码在受害者的浏览器中执行时,攻击者就能窃取相应的敏感数据,并强迫用户做一些用户非本意的事情。

  2.Path:这个属性是用来提高域安全模型的控制力度,使其包含URL路径。注意,属性path是可选的,如果设置了它,那么cookie只会发送给路径与属性path相吻合的那些服务器。例如,如果http://x.y.z.com/a/WebApp建立了一个路径属性设为/a的cookie;那么该cookie只会发送给所有http://x.y.z.com/a/*范围内的请求。但是,当人们向http://x.y.z.com/index.html或http://x.y.z.com/a/b/index.html的请求时,该cookie不会发送。

  3.Secure:如果一个cookie设置了该属性,那么只有遇到HTTPS请求时才发送该cookie。注意,HTTP和HTTPS的响应都可以对属性secure进行相应的设置。因此,一个HTTP请求/应答可以改变HTTPS的cookie的secure设置。对于某些高级中间人攻击来说,这是一个大问题。

  4.Expires:通常情况下,当浏览器关闭时,cookies就会被删除。不过,您可以设置一个截止日期,在此之前,cookies将一直存放在用户的机器上,并且对于每个HTTP请求都发送此cookie,直到期满为止。截止日期的格式一般为Wdy, DD-Mon-YYYY HH:MM:SS GMT。 通过设置属性expires为一个过去的日期,可以立即删除cookies。

  5.HttpOnly:这个属性对于Firefox和Internet Explorer都是新增的。它在Web应用中很少使用,因为它只对Internet Explorer有效。如果这个属性被设置,那么IE 将不允许阅读该cookie,也不允许通过JavaScript的document.cookie对该cookie执行写操作。这个属性是用来防止攻击者窃取cookies来做坏事,不过,攻击者总是可以创建JavaScript来做等价的事情,所以即使不通过窃取cookies也无所谓。

  下面是带有安全属性cookies的示例代码:
  CookieName1=CookieValue1; domain=.y.z.com; path=/a;
  CookieName2=CookieValue2; domain=x.y.z.com; secure
  我们知道,像来自服务器端的JavaScript和VBScript代码可以通过访问变量document.cookie来对cookies进行读写操作,除非该cookie设置了HttpOnly属性并且用户正在使用IE。这是一个很大的安全隐患,黑客对此极为感兴趣,因为cookies通常含有认证证书,CSRF保护措施的信息和其他机密信息;此外,中间人攻击可以编辑HTTP通信中的JavaScript代码,呵呵,这简直就是一场恶梦。

  如果一位攻击者可以突破或绕过同源策略的话,就可以通过DOM的变量document.cookie轻松读取cookies。另外,写入新的cookies也是非常容易的,攻击者只要使用类似下列字符串格式来连接document.cookie变量即可:
  var cookieDate = new Date ( 2030, 12, 31 );
  document.cookie += "CookieName=CookieValue;" +
  /* 以下各行均为可选内容 */
  "domain=.y.z.com;" +
  "path=/a;" +
  "expires=" + cookieDate.toGMTString() + ";" +
  "secure;" +
  "HttpOnly;"
  读者可以对照全面讲述的内容自己理解上述代码,我想这并非难事。

  四、Cookies在创建和语法分析方面的安全隐患

  Cookies可以用于JavaScript、浏览器、Web服务器、负载均衡系统及其他独立系统,每个系统都使用不同的代码来解析Cookies。毫无疑问,这些系统将以不同的方式来解析和阅读cookies。攻击者也许能够将受害者已有的cookie中的一个替换掉,换上的cookie在系统看来表面上跟想要的那个没什么两样,但是实际上内容却大相径庭了。

  举例来说,攻击者也许能够添加一个cookie,而这个cookie恰好与受害者已有的cookies中的一个重名,这样攻击者就覆盖了原先的cookie。可以考虑一下大学的设置,其中一位攻击者具有一个公开的web页面,位于http://public-pages.daxue.edu/~attacker,同时该大学在https://webmail.daxue.edu/提供了一个webmail服务。攻击者可以自己制作一个cookie并且将域设为.daxue.edu,然后把它发送到https://webmail.daxue.edu/。假如这个cookie跟webmail用于认证的cookie同名的话,现在webmail系统读取的将是攻击者伪造的cookie,而不是webmail为用户所建立的cookie。

  这时候,webmail系统会将发送该cookie的人(即攻击者)当作是其他的人对待,并进入被冒充的人(即受害者)的webmail帐户。之后,攻击者就可以对受害者中的邮件做手脚,让账户内只留下一封电子邮件,并声称用户的电子邮件由于安全原因而被屏蔽,该用户必须转到http://public-pages.Daxue.edu/~attacker/reAuthenticate(或者一个隐蔽的恶意链接)去重新登录才能看到他的所有邮件。攻击者可以建立一个重新认证连接,使其看上去像一个典型的大学登录页面那样要求受害者输入用户名和口令。当受害者递交个人信息后,用户名和口令会被发送给攻击者。

  实际上,仅仅注入cookie片段也可以使不同的系统读取不同的cookies。注意,cookies和访问控制使用相同的符号进行分隔:分号(;)。如果攻击者可以通过JavaScript添加cookies,或者cookies是根据一些用户输入来添加的,那么攻击者可以附加一个cookie片段,以利用该片段改变安全特性或者其它的cookies的值。

    五、利用JavaScript将Cookie安全模型降低至同源策略

  Cookie安全模型要比同源策略更安全一些,但是利用一些JavaScript,可以把cookie的域还原成跟同源策略的document.domain设置相同的安全级别,并且该cookie的path属性可以被完全绕过。

  我们还是使用前面的大学webmail的例子,这里假设攻击者在http://public-pages.daxue.edu/~attacker/创建了一个web页面,同时该大学在http://webmail.daxue.edu/建有一个webmail系统。如果在http://webmail.daxue.edu/中的某个页面的document.domain="daxue.edu",假设该页面为http://webmail.daxue.edu/badPage.html,那么攻击者可以通过诱导受害者到达http://public-pages.daxue.edu/~attacker/stealCookies.htm来窃取受害者的cookies,该页包含以下代码:
  <script>
  function stealCookies() {
  var victimsCookies = document.getElementById("iLoveIframes").cookie;
  sendCookiesSomewhere(victimsCookies);
  }
  </script>
  <iframe id="iLoveIframes"
  style="display:none"
  src="http://webmail.daxue.edu/badPage.html">

  类似的,如果攻击者的个人页面位于http://www.daxue.edu/~attacker/,webmail系统位于http://www.daxue.edu/webmail/,同时webmail的cookie中的路径被设为path=/webmail,那么,攻击者就可以通过诱使受害者浏览 http://www.daxue.edu/~attacker/stealCookies.html来窃取受害者的cookie,其中这个页面包含如下所示的恶意代码:
  <script>
  function stealCookies() {
  var victimsCookies = document.getElementById("iLoveIframes").cookie;
  sendCookiesSomewhere(victimsCookies);
  }
  </script>
  <iframe id="iLoveIframes"
  style="display:none"
  src="http://www.daxue.edu/webmail/anyPage.html">
  </iframe>

  六、保护Cookie

  利用Cookie安全模型中添加的特性,但是不要完全依赖Cookie安全模型中的添加的安全特性。只信任同源策略,并围绕同源策略来打造Web应用程序的安全性。

  七、Flash的安全模型

  Flash是一种流行的Web浏览器插件,它近来发行的版本中包含了很多复杂的安全模型以供开发人员根据自己的喜好进行定制。这里我们将介绍Flash的安全模型的各个方面,首先介绍的是JavaScript所不具备的那些特性。

   Flash的脚本语言称为ActionScript,它与JavaScript非常类似,并且包含了一些从攻击者的角度看来非常感兴趣的一些类:
  1.Socket类使开发人员可以创建至allowed域的原始TCP套按字连接,这可以用来达到各种目的,比如精心制作带有伪造的各种报头(例如referrer)的HTTP请求。此外,套按字也可用于扫描无法从外部访问的网络计算机和端口。
  2.ExternalInterface类使开发人员可以从Flash运行浏览器中的JavaScript,以达到各种目的,例如读写document.cookie。
  3.XML和URLLoader这两个类可以以某用户的名义发送HTTP请求(连带浏览器的Cookie)至allowed域,以达到各种目的,例如跨域请求。

  默认时,Flash的安全模型与同源策略非常类似。即,来自于某个域腇lash应用只可以读取来自该域的响应。此外,Flash还对HTTP请求的发送做了一些安全限制,但是您可以经过Flash的getURL函数发送跨域的GET请求。此外,Flash不允许通过HTTP装入的Flash应用程序读取用HTTPS载入的响应。需要注意的是,如果在另一个域上的安全策略准许跟Flash应用程序所在域通信的话,Flash却允许跨域通信。安全策略通常是一个名为crossdomain.XML的XML文件,一般位于域的根目录下。从安全角度讲,最糟糕的策略文件可能是下面这样:
  <cross-domain-policy>
  <allow-access-from domain="*" />
  </cross-domain-policy>

  该策略允许任何Flash应用程序跟存放这个crossdomain.xml文件的服务器(跨域)通信。该策略文件可以任意取名,并且可以放在任何目录下。可以使用下列ActionScript代码加载任意的安全策略文件:
  System.security.loadPolicyFile("http://public-" +"pages.univeristy.edu/crossdomain.xml");
  如果它不在服务器的根目录中,那么该政策仅适用于该策略文件所在的目录以及该目录下的所有子目录。举例来说,假设策略文件位于http://public-pages.daxue.edu/~attacker/crossdomain.xml,那么该政策将适用于对http://publicpages.daxue.edu/~attacker/doEvil.html和http://public-pages.daxue.edu/~attacker/moreEvil/doMoreEvil.html的请求,而不对诸如http://public-pages.daxue.edu/~someStudent/familyPictures.html或http://public-pages.daxue.edu/index.html这样的页面有影响。

   八、反射策略文件

  策略文件会被Flash“宽大地”解析,因此,如果您可以构造一个会导致服务器发回一个策略文件的HTTP请求,Flash将接受该策略文件。举例来说,http://www.daxue.edu/CourseListing?format=js&amp;callback=这个Ajax请求
  将得到如下所示的响应:
  <cross-domain-policy><allow-access-from%20domain="*"/>
  </cross-domain-policy>() { return {name:"English101",
  desc:"Read Books"}, {name:"Computers101",
  desc:"play on computers"}};
  然后,您可以通过ActionScript加载该策略:
  System.security.loadPolicyFile("http://www.daxue.edu/" +
  "CourseListing?format=json&callback=" +
  "< cross-domain-policy >" +
  "< allow-access-from%20domain=\"*\"/ >" +
  "< /cross-domain-policy >");
  这样会导致该Flash应用程序能够得以跨域访问http://www.daxue.edu/。
  也能您已经想到了,如果人们可以上载一个文件到包含一个不安全的策略文件的服务器并能够随后在通过HTTP进行检索的话,那么System.security.loadPolicyFile()函数也会跟这个策略文件关联起来。
  总之,Flash将遵守任何包含跨域策略的文件,除非之前存在任何未闭合的标签或者扩展ASCII字符。注意,Flash Player会完全忽略MIME类型。

  九、针对策略文件反射的保护措施

  当把用户定义的数据返回给该用户时,应当把HTML中的大于号〉换码为>并且把字符<转换为<,或者直接将其删除。

  十、结束语
  在浏览器中已经建立了一些安全措施——即同源策略和Cookie安全模型。此外,一些浏览器插件,诸如Flash Player、Outlook Express 以及Acrobat Reader等,带来了更多的安全问题和安全措施。然而,如果攻击者可以强迫用户执行源自特定域的JavaScript的话,这些额外的安全措施总是倾向于削弱同源策略的力量。

  跨站脚本攻击(XSS)技术能够强迫用户执行攻击者以受害者名义在某个域上选择的脚本,如JavaScript、VBScript、ActionScript,等等。XSS要求某个域上的Web应用程序能够提供(即供应、返回)被攻击者所控制的字符。因此,攻击者可以向页面注入代码,而这些代码将来会在这个有弱点的域的上下文中执行。攻击者精心构造出供受害者运行的恶意代码之后,他还必须诱骗受害者单击一个链接。该链接一经点击,马上就会启动攻击活动。这些内容将在下一篇中加以介绍。

 

3COME考试频道为您精心整理,希望对您有所帮助,更多信息在http://www.reader8.net/exam/

热点排行