跨站脚本攻击深入解析:跨站危害及cookie盗窃（4）

八、促使用户单击注入的HTML代码

利用“免费 * ”以及“ * 甩卖”来引诱别人已经成为过去，现在，攻击者通常会促使用户去做一些普通大众经常做的事情，诸如单击一个新闻链接、欣赏一副可爱的小猫的图片等等，当然使用的方法在前面我们已经说过了。

例如，快到情人节了，大多数年轻人都希望给爱人一个惊喜。攻击者就会考虑利用“阅读本文以了解如何您的爱人一个与众不同的情人节”之类的文字来诱惑用户单击链接。借助于XSS蠕虫，如果人们看到这封邮件来自其好友的话，那么人们会毫不犹豫地点击它。

然而，攻击者放入的文字越多，越容易引起潜在受害者的疑虑。现今，最有效的信件应当只发给潜在的受害者一个链接，而根本不附加任何文字。好奇是人类的本性，在这种强烈的本能的驱使下，点击该链接将大有人在。

至此，攻击手法的介绍已经告一段落，下面开始简要介绍针对跨站脚本攻击的防御措施。

九、防御跨站点脚本攻击

为了防御XSS攻击，开发人员必须谨慎处理由用户提供的并且又反过来提供给用户的那些数据。这里所说的“用户提供的数据”应该定义为所有从外部网络连接发送给Web应用程序的那些数据。

它可以是登录时用HTML表单提交的用户名，一个后台的Ajax请求、一封电子邮件、乃至http报头。要把所有这些数据都看作是从外部网络连接进入Web应用程序的有潜在危险的数据。

对于所有由用户提供的随后又通过HTTP应答（诸如Web页面以及AJAX响应（HTTP响应码200）、页面未找到错误（HTTP响应码404）、服务器错误（类似的HTTP 响应码502）、重定向（例如HTTP 响应码302，等等）回显给用户的那些数据，开发人员必须采取下列措施之一：

对数据进行正确地转义处理，以保证它们不会被解释为HTML代码（对浏览器而言）或者XML代码（对Flash而言）。

删除会被恶意使用的字符串或者字符

一般情况下，删除一些字符会对用户体验造成影响，举例来说，如果开发人员删除了上撇号（’），那么对某些人来说就会带来不便，如姓氏中带有撇号的人，他们的姓氏就无法正常显示。同时，严禁开发人员删除字符串，因为完全可以通过许多不同的形式来表示字符串。应用程序和浏览器会对字符串作出不同的解释。例如，SAMY蠕虫利用了IE不把换行符作为定界符字符这一事实，因此，IE看来JavaScript和jav％0dascr％0dipt是一回事。遗憾的是，MySpace把换行符解释为字的分界符号，并允许将向Samy（及其他人）的MySpace页面中放入下列内容：

〈 div id=“mycode” expr=“a_lert（‘1’）” style=“background:url（‘javascript:eval（document.all.mycode.expr）’）”〉〈/div〉

我们建议对所有用户提供的又被发回给Web浏览器的数据都进行转义处理，包括AJAX调用、移动式应用、Web页面、重定向等等内的数据。然而，对字符串进行转义处理并不是我们想得那么简单：您必须根据用户提供的数据将被放到HTTP应答中的具体位置来决定使用URL编码、HTML实体编码或者JavaScript编码进行转义。

十、防范基于UTF-7的XSS

基于UTF-7的攻击是很容易防范的，只要强制指定在HTTP报头中的或者HTML响应内部的字符编码即可。我们建议对默认HTTP报头做如下设置：

Content-Type： text ml; charset=utf-8

还应当对全部HTML响应添加下列限制：

《 meta http-equiv=“Content-Type” content=“text ml;charset=utf-8” 》

十一、结束语

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

跨站点脚本攻击（XSS）技术能够强迫用户执行攻击者以受害者名义在某个域上选择的脚本，如JavaScript、VBScript、ActionScript，等等。XSS要求某个域上的Web应用程序能够提供（即供应、返回）被攻击者所控制的字符。因此，攻击者可以向页面注入代码，而这些代码将来会在这个有弱点的域的上下文中执行。本文详细介绍跨站脚本的危害，以及攻击者是如何诱骗受害者的。最后介绍针对跨站脚本攻击的防御措施。至此，读者已经能够对跨站脚本攻击有一个全面深入的了解了。