目录介绍：

• 1、javascript关于XSS注入的一些问题
• 2、sql注入、xss攻击？
• 3、几种极其隐蔽的XSS注入的防护
• 4、常见的漏洞类型有哪些
• 5、什么是sql注入 什么是xss注入
• 6、xss注入漏洞产生的原因？xss注入过程步骤是什么？防范xss注入的方法有哪些

javascript关于XSS注入的一些问题

xss注入的内容是给浏览器看的东西，所以只要让浏览器认为它不是需要被解析的html标签或者脚本就可以了。过滤掉'' ，或者把'',''都过滤掉，已经可以保证不会被xss注入了。但是这需要建立在你其他代码没有注入漏洞的前提下。

sql注入、xss攻击？

随着B/S模式应用开发的发展，使用这种模式编写应用程序的程序员也越来越多。但是由于这个行业的入门门槛不高，程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的SQL Injection，即SQL注入。 SQL注入是从正常的WWW端口访问，而且表面看起来跟一般的Web页面访问没什么区别，所以目前市面的防火墙都不会对SQL注入发出警报，如果管理员没查看IIS日志的习惯，可能被入侵很长时间都不会发觉。 但是，SQL注入的手法相当灵活，在注入的时候会碰到很多意外的情况。能不能根据具体情况进行分析，构造巧妙的SQL语句，从而成功获取想要的数据，是高手与“菜鸟”的根本区别。 根据国情，国内的网站用ASP+Access或SQLServer的占70%以上，PHP+MySQ占L20%，其他的不足10%。在本文，我们从分入门、进阶至高级讲解一下ASP注入的方法及技巧，PHP注入的文章由NB联盟的另一位朋友zwell撰写，希望对安全工作者和程序员都有用处。了解ASP注入的朋友也请不要跳过入门篇，因为部分人对注入的基本判断方法还存在误区。大家准备好了吗？Let's Go... 入门篇 如果你以前没试过SQL注入的话，那么第一步先把IE菜单=工具=Internet选项=高级=显示友好 HTTP 错误信息前面的勾去掉。否则，不论服务器返回什么错误，IE都只显示为HTTP 500服务器错误，不能获得更多的提示信息。 第一节、SQL注入原理 以下我们从一个网站 开始（注：本文发表前已征得该站站长同意，大部分都是真实数据）。 在网站首页上，有名为“IE不能打开新窗口的多种解决方法”的链接，地址为： ，我们在这个地址后面加上单引号’，服务器会返回下面的错误提示： Microsoft JET Database Engine 错误 '80040e14' 字符串的语法错误 在查询表达式 'ID=49'' 中。 /showdetail.asp，行8 从这个错误提示我们能看出下面几点： 1.网站使用的是Access数据库，通过JET引擎连接数据库，而不是通过ODBC。 2.程序没有判断客户端提交的数据是否符合程序要求。 3.该SQL语句所查询的表中有一名为ID的字段。 从上面的例子我们可以知道，SQL注入的原理，就是从客户端提交特殊的代码，从而收集程序及服务器的信息，从而获取你想到得到的资料。 第二节、判断能否进行SQL注入 看完第一节，有一些人会觉得：我也是经常这样测试能否注入的，这不是很简单吗？ 其实，这并不是最好的方法，为什么呢？ 首先，不一定每台服务器的IIS都返回具体错误提示给客户端，如果程序中加了cint(参数)之类语句的话，SQL注入是不会成功的，但服务器同样会报错，具体提示信息为处理 URL 时服务器上出错。请和系统管理员联络。 其次，部分对SQL注入有一点了解的程序员，认为只要把单引号过滤掉就安全了，这种情况不为少数，如果你用单引号测试，是测不到注入点的 那么，什么样的测试方法才是比较准确呢？答案如下： ① ② and 1=1 ③ and 1=2 这就是经典的1=1、1=2测试法了，怎么判断呢？看看上面三个网址返回的结果就知道了： 可以注入的表现： ① 正常显示（这是必然的，不然就是程序有错误了） ② 正常显示，内容基本与①相同 ③ 提示BOF或EOF（程序没做任何判断时）、或提示找不到记录（判断了rs.eof时）、或显示内容为空（程序加了on error resume next） 不可以注入就比较容易判断了，①同样正常显示，②和③一般都会有程序定义的错误提示，或提示类型转换时出错。 当然，这只是传入参数是数字型的时候用的判断方法，实际应用的时候会有字符型和搜索型参数，我将在中级篇的“SQL注入一般步骤”再做分析。 第三节、判断数据库类型及注入方法 不同的数据库的函数、注入方法都是有差异的，所以在注入之前，我们还要判断一下数据库的类型。一般ASP最常搭配的数据库是Access和SQLServer，网上超过99%的网站都是其中之一。 怎么让程序告诉你它使用的什么数据库呢？来看看： SQLServer有一些系统变量，如果服务器IIS提示没关闭，并且SQLServer返回错误提示的话，那可以直接从出错信息获取，方法如下： and user0 这句语句很简单，但却包含了SQLServer特有注入方法的精髓，我自己也是在一次无意的测试中发现这种效率极高的猜解方法。让我看来看看它的含义：首先，前面的语句是正常的，重点在and user0，我们知道，user是SQLServer的一个内置变量，它的值是当前连接的用户名，类型为nvarchar。拿一个nvarchar的值跟int的数0比较，系统会先试图将nvarchar的值转成int型，当然，转的过程中肯定会出错，SQLServer的出错提示是：将nvarchar值 ”abc” 转换数据类型为 int 的列时发生语法错误，呵呵，abc正是变量user的值，这样，不废吹灰之力就拿到了数据库的用户名。在以后的篇幅里，大家会看到很多用这种方法的语句。 顺便说几句，众所周知，SQLServer的用户sa是个等同Adminstrators权限的角色，拿到了sa权限，几乎肯定可以拿到主机的Administrator了。上面的方法可以很方便的测试出是否是用sa登录，要注意的是：如果是sa登录，提示是将”dbo”转换成int的列发生错误，而不是”sa”。 如果服务器IIS不允许返回错误提示，那怎么判断数据库类型呢？我们可以从Access和SQLServer和区别入手，Access和SQLServer都有自己的系统表，比如存放数据库中所有对象的表，Access是在系统表[msysobjects]中，但在Web环境下读该表会提示“没有权限”，SQLServer是在表[sysobjects]中，在Web环境下可正常读取。 在确认可以注入的情况下，使用下面的语句： and (select count(*) from sysobjects)0 and (select count(*) from msysobjects)0 如果数据库是SQLServer，那么第一个网址的页面与原页面 是大致相同的；而第二个网址，由于找不到表msysobjects，会提示出错，就算程序有容错处理，页面也与原页面完全不同。 如果数据库用的是Access，那么情况就有所不同，第一个网址的页面与原页面完全不同；第二个网址，则视乎数据库设置是否允许读该系统表，一般来说是不允许的，所以与原网址也是完全不同。大多数情况下，用第一个网址就可以得知系统所用的数据库类型，第二个网址只作为开启IIS错误提示时的验证

几种极其隐蔽的XSS注入的防护

XSS注入的本质

就是: 某网页中根据用户的输入, 不期待地生成了可执行的js代码, 并且js得到了浏览器的执行. 意思是说, 发给浏览器的字符串中, 包含了一段非法的js代码, 而这段代码跟用户的输入有关.

常见的XSS注入防护, 可以通过简单的 htmlspecialchars(转义HTML特殊字符), strip_tags(清除HTML标签) 来解决, 但是, 还有一些隐蔽的XSS注入不能通过这两个方法来解决, 而且, 有时业务需要不允许清除HTML标签和特殊字符. 下面列举几种隐蔽的XSS注入方法:

IE6/7 UTF7 XSS 漏洞攻击

隐蔽指数: 5

伤害指数: 5

这个漏洞非常隐蔽, 因为它让出现漏洞的网页看起来只有英文字母(ASCII字符), 并没有非法字符, htmlspecialchars 和 strip_tags 函数对这种攻击没有作用. 不过, 这个攻击只对 IE6/IE7 起作用, 从 IE8 起微软已经修复了. 你可以把下面这段代码保存到一个文本文件中(前面不要有空格和换行), 然后用 IE6 打开试试(没有恶意代码, 只是一个演示):

+/v8 +ADw-script+AD4-alert(document.location)+ADw-/script+AD4-

最容易中招的就是 JSONP 的应用了, 解决方法是把非字母和数字下划线的字符全部过滤掉. 还有一种方法是在网页开始输出空格或者换行, 这样, UTF7-XSS 就不能起作用了.

因为只对非常老版本的 IE6/IE7 造成伤害, 对 Firefox/Chrome 没有伤害, 所以伤害指数只能给 4 颗星.

参考资料:UTF7-XSS不正确地拼接 JavaScript/JSON 代码段

隐蔽指数: 5

伤害指数: 5

Web 前端程序员经常在 PHP 代码或者某些模板语言中, 动态地生成一些 JavaScript 代码片段, 例如最常见的:

var a = '?php echo htmlspecialchars($name); ?';

不想, $name 是通过用户输入的, 当用户输入a’; alert(1); 时, 就形成了非法的JavaScript 代码, 也就是XSS 注入了.

只需要把上面的代码改成:

var a = ?php echo json_encode($name); ?;

去掉单引号, 利用 PHP 的 json_encode() 函数来生成表示字符串的字符串. 这样做是因为,

最好用 json_encode() 函数来生成所有的 JSON 串, 而不要试图自己去拼接

. 程序员总是犯这样的错误: 自己去解析 HTTP 报文, 而不是用现成的成熟的库来解析. 用 json_encode() 的好处还在于, 即使业务要求我要保留单引号时, XSS注入也可以避免.

隐蔽指数最高级, 伤害所有的通用浏览器

. 这种 XSS 注入方式具有非常重要的参考意义.

最后, 根据工作中的经验, 以及我自己和别人犯过的错, 我总结出一个定理: 没有一劳永逸的单一方法可以解决所有 XSS 注入问题.

有用的经验:输出 HTML 代码时 htmlspecialchars输出JavaScript 代码时 json_encode

输入过滤应该用于解决业务限制, 而不是用于解决 XSS 注入(与严进宽出的原则相悖, 所以本条值得讨论)讨论:上文提到的经验第3条, 是一种宽进严出的原则, 和严进宽出原则是相悖的. 其实, 我认为不应该把严进宽出作为一条伪真理, 好像除了它其它的说法都不对了似的. 宽进严出和严进宽出应该具有完全相等的地位, 根据实现的成本进行取舍.

例如, 用户的名字可以采用严进宽出原则, 不允许用户填写单引号, 大于号小于号等. 但是用户的签名呢? 难道就不能填单引号?

常见的漏洞类型有哪些

一、SQL 注入漏洞

SQL 注入攻击（ SQL Injection ），简称注入攻击、SQL 注入，被广泛用于非法获取网站控制权， 是发生在应用程序的数据库层上的安全漏洞。在设计程序，忽略了对输入字符串中夹带的SQL 指令的检查，被数据库误认为是正常的SQL 指令而运行，从而使数据库受到攻击，可能导致数据被窃取、更改、删除，以及进一步导致网站被嵌入恶意代码、被植入后门程序等危害。

通常情况下， SQL 注入的位置包括：

（1）表单提交，主要是POST 请求，也包括GET 请求；

（2）URL 参数提交，主要为GET 请求参数；

（3）Cookie 参数提交；

（4）HTTP 请求头部的一些可修改的值，比如Referer 、User_Agent 等；

（5）一些边缘的输入点，比如.mp3 文件的一些文件信息等。

SQL 注入的危害不仅体现在数据库层面上， 还有可能危及承载数据库的操作系统；如果SQL 注入被用来挂马，还可能用来传播恶意软件等，这些危害包括但不局限于：

（1）数据库信息泄漏：数据库中存放的用户的隐私信息的泄露。作为数据的存储中心，数据库里往往保存着各类的隐私信息， SQL 注入攻击能导致这些隐私信息透明于攻击者。

（2）网页篡改：通过操作数据库对特定网页进行篡改。

（3）网站被挂马，传播恶意软件：修改数据库一些字段的值，嵌入网马链接，进行挂马攻击。

（4）数据库被恶意操作：数据库服务器被攻击，数据库的系统管理员帐户被篡改。

（5）服务器被远程控制，被安装后门。经由数据库服务器提供的操作系统支持，让黑客得以修改或控制操作系统。

（6）破坏硬盘数据，瘫痪全系统。

解决SQL 注入问题的关键是对所有可能来自用户输入的数据进行严格的检查、对数据库配置使用最小权限原则。通常使用的方案有：

（1 ）所有的查询语句都使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到SQL 语句中。当前几乎所有的数据库系统都提供了参数化SQL 语句执行接口，使用此接口可以非常有效的防止SQL 注入攻击。

（2 ）对进入数据库的特殊字符（ '"\*; 等）进行转义处理，或编码转换。

（3 ）确认每种数据的类型，比如数字型的数据就必须是数字，数据库中的存储字段必须对应为int 型。

（4）数据长度应该严格规定，能在一定程度上防止比较长的SQL 注入语句无法正确执行。

（5）网站每个数据层的编码统一，建议全部使用UTF-8 编码，上下层编码不一致有可能导致一些过滤模型被绕过。

（6）严格限制网站用户的数据库的操作权限，给此用户提供仅仅能够满足其工作的权限，从而最大限度的减少注入攻击对数据库的危害。

（7）避免网站显示SQL 错误信息，比如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断。

（8）在网站发布之前建议使用一些专业的SQL 注入检测工具进行检测，及时修补这些SQL 注入漏洞。

二、跨站脚本漏洞

跨站脚本攻击（ Cross-site scripting ，通常简称为XSS）发生在客户端，可被用于进行窃取隐私、钓鱼欺骗、窃取密码、传播恶意代码等攻击。XSS 攻击使用到的技术主要为HTML 和Javascript ，也包括VBScript和ActionScript 等。XSS 攻击对WEB 服务器虽无直接危害，但是它借助网站进行传播，使网站的使用用户受到攻击，导致网站用户帐号被窃取，从而对网站也产生了较严重的危害。

XSS 类型包括：

（1）非持久型跨站： 即反射型跨站脚本漏洞， 是目前最普遍的跨站类型。跨站代码一般存在于链接中，请求这样的链接时，跨站代码经过服务端反射回来，这类跨站的代码不存储到服务端（比如数据库中）。上面章节所举的例子就是这类情况。

（2）持久型跨站：这是危害最直接的跨站类型，跨站代码存储于服务端（比如数据库中）。常见情况是某用户在论坛发贴，如果论坛没有过滤用户输入的Javascript 代码数据，就会导致其他浏览此贴的用户的浏览器会执行发贴人所嵌入的Javascript 代码。

（3）DOM 跨站（DOM XSS ）：是一种发生在客户端DOM （Document Object Model 文档对象模型）中的跨站漏洞，很大原因是因为客户端脚本处理逻辑导致的安全问题。

XSS 的危害包括：

（1）钓鱼欺骗：最典型的就是利用目标网站的反射型跨站脚本漏洞将目标网站重定向到钓鱼网站，或者注入钓鱼JavaScript 以监控目标网站的表单输入，甚至发起基于DHTML 更高级的钓鱼攻击方式。

（2 ）网站挂马：跨站时利用IFrame 嵌入隐藏的恶意网站或者将被攻击者定向到恶意网站上，或者弹出恶意网站窗口等方式都可以进行挂马攻击。

（3）身份盗用： Cookie 是用户对于特定网站的身份验证标志， XSS 可以盗取到用户的Cookie ，从而利用该Cookie 盗取用户对该网站的操作权限。如果一个网站管理员用户Cookie 被窃取，将会对网站引发巨大的危害。

（4）盗取网站用户信息：当能够窃取到用户Cookie 从而获取到用户身份使，攻击者可以获取到用户对网站的操作权限，从而查看用户隐私信息。

（5）垃圾信息发送：比如在SNS 社区中，利用XSS 漏洞借用被攻击者的身份发送大量的垃圾信息给特定的目标群。

（6）劫持用户Web 行为：一些高级的XSS 攻击甚至可以劫持用户的Web 行为，监视用户的浏览历史，发送与接收的数据等等。

（7）XSS 蠕虫：XSS 蠕虫可以用来打广告、刷流量、挂马、恶作剧、破坏网上数据、实施DDoS 攻击等。

常用的防止XSS 技术包括：

（1）与SQL 注入防护的建议一样，假定所有输入都是可疑的，必须对所有输入中的script 、iframe 等字样进行严格的检查。这里的输入不仅仅是用户可以直接交互的输入接口，也包括HTTP 请求中的Cookie 中的变量， HTTP 请求头部中的变量等。

（2 ）不仅要验证数据的类型，还要验证其格式、长度、范围和内容。

（3）不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。

（ 4）对输出的数据也要检查， 数据库里的值有可能会在一个大网站的多处都有输出，即使在输入做了编码等操作，在各处的输出点时也要进行安全检查。

（5）在发布应用程序之前测试所有已知的威胁。

三、弱口令漏洞

弱口令(weak password) 没有严格和准确的定义，通常认为容易被别人（他们有可能对你很了解）猜测到或被破解工具破解的口令均为弱口令。设置密码通常遵循以下原则：

（1）不使用空口令或系统缺省的口令，这些口令众所周之，为典型的弱口令。

（2）口令长度不小于8 个字符。

（3）口令不应该为连续的某个字符（例如： AAAAAAAA ）或重复某些字符的组合（例如： tzf.tzf. ）。

（4）口令应该为以下四类字符的组合，大写字母(A-Z) 、小写字母(a-z) 、数字(0-9) 和特殊字符。每类字符至少包含一个。如果某类字符只包含一个，那么该字符不应为首字符或尾字符。

（5）口令中不应包含本人、父母、子女和配偶的姓名和出生日期、纪念日期、登录名、E-mail 地址等等与本人有关的信息，以及字典中的单词。

（6）口令不应该为用数字或符号代替某些字母的单词。

（7）口令应该易记且可以快速输入，防止他人从你身后很容易看到你的输入。

（8）至少90 天内更换一次口令，防止未被发现的入侵者继续使用该口令。

四、HTTP 报头追踪漏洞

HTTP/1.1 （RFC2616 ）规范定义了HTTP TRACE 方法，主要是用于客户端通过向Web 服务器提交TRACE 请求来进行测试或获得诊断信息。当Web 服务器启用TRACE 时，提交的请求头会在服务器响应的内容（Body ）中完整的返回，其中HTTP 头很可能包括Session Token 、Cookies 或其它认证信息。攻击者可以利用此漏洞来欺骗合法用户并得到他们的私人信息。该漏洞往往与其它方式配合来进行有效攻击，由于HTTP TRACE 请求可以通过客户浏览器脚本发起（如XMLHttpRequest ），并可以通过DOM 接口来访问，因此很容易被攻击者利用。防御HTTP 报头追踪漏洞的方法通常禁用HTTP TRACE 方法。

五、Struts2 远程命令执行漏洞

Apache Struts 是一款建立Java web 应用程序的开放源代码架构。Apache Struts 存在一个输入过滤错误，如果遇到转换错误可被利用注入和执行任意Java 代码。网站存在远程代码执行漏洞的大部分原因是由于网站采用了Apache Struts Xwork 作为网站应用框架，由于该软件存在远程代码执高危漏洞，导致网站面临安全风险。CNVD 处置过诸多此类漏洞，例如：“ GPS 车载卫星定位系统”网站存在远程命令执行漏洞(CNVD-2012-13934) ；Aspcms 留言本远程代码执行漏洞（ CNVD-2012-11590 ）等。

修复此类漏洞，只需到Apache 官网升级Apache Struts 到最新版本

六、框架钓鱼漏洞（框架注入漏洞）

框架注入攻击是针对Internet Explorer 5 、Internet Explorer 6 、与Internet Explorer 7 攻击的一种。这种攻击导致Internet Explorer 不检查结果框架的目的网站，因而允许任意代码像Javascript 或者VBScript 跨框架存取。这种攻击也发生在代码透过多框架注入，肇因于脚本并不确认来自多框架的输入。这种其他形式的框架注入会影响所有的不确认不受信任输入的各厂商浏览器和脚本。如果应用程序不要求不同的框架互相通信，就可以通过完全删除框架名称、使用匿名框架防止框架注入。但是，因为应用程序通常都要求框架之间相互通信，因此这种方法并不可行。因此，通常使用命名框架，但在每个会话中使用不同的框架，并且使用无法预测的名称。一种可行的方法是在每个基本的框架名称后附加用户的会话令牌，如main_display 。

七、文件上传漏洞

文件上传漏洞通常由于网页代码中的文件上传路径变量过滤不严造成的，如果文件上传功能实现代码没有严格限制用户上传的文件后缀以及文件类型，攻击者可通过Web 访问的目录上传任意文件，包括网站后门文件（ webshell ），进而远程控制网站服务器。因此，在开发网站及应用程序过程中，需严格限制和校验上传的文件，禁止上传恶意代码的文件。同时限制相关目录的执行权限，防范webshell 攻击。

八、应用程序测试脚本泄露

由于测试脚本对提交的参数数据缺少充分过滤，远程攻击者可以利用洞以WEB 进程权限在系统上查看任意文件内容。防御此类漏洞通常需严格过滤提交的数据，有效检测攻击。

九、私有IP 地址泄露漏洞

IP 地址是网络用户的重要标示，是攻击者进行攻击前需要了解的。获取的方法较多，攻击者也会因不同的网络情况采取不同的方法，如：在局域网内使用Ping 指令， Ping 对方在网络中的名称而获得IP；在Internet 上使用IP 版的QQ直接显示。最有效的办法是截获并分析对方的网络数据包。攻击者可以找到并直接通过软件解析截获后的数据包的IP 包头信息，再根据这些信息了解具体的IP。针对最有效的“数据包分析方法”而言，就可以安装能够自动去掉发送数据包包头IP 信息的一些软件。不过使用这些软件有些缺点， 譬如：耗费资源严重，降低计算机性能；访问一些论坛或者网站时会受影响；不适合网吧用户使用等等。现在的个人用户采用最普及隐藏IP 的方法应该是使用代理，由于使用代理服务器后，“转址服务”会对发送出去的数据包有所修改，致使“数据包分析”的方法失效。一些容易泄漏用户IP 的网络软件(QQ 、MSN 、IE 等)都支持使用代理方式连接Internet ，特别是QQ 使用“ ezProxy ”等代理软件连接后， IP 版的QQ 都无法显示该IP 地址。虽然代理可以有效地隐藏用户IP，但攻击者亦可以绕过代理， 查找到对方的真实IP 地址，用户在何种情况下使用何种方法隐藏IP，也要因情况而论。

十、未加密登录请求

由于Web 配置不安全， 登陆请求把诸如用户名和密码等敏感字段未加密进行传输， 攻击者可以窃听网络以劫获这些敏感信息。建议进行例如SSH 等的加密后再传输。

十一、敏感信息泄露漏洞

SQL 注入、XSS、目录遍历、弱口令等均可导致敏感信息泄露，攻击者可以通过漏洞获得敏感信息。针对不同成因，防御方式不同。

什么是sql注入 什么是xss注入

推荐你去百度一下OWASP，你基本上可以看到有关网络安全的全貌了 - SQL注入和xss注入是最常见的两种注入攻击

xss注入漏洞产生的原因？xss注入过程步骤是什么？防范xss注入的方法有哪些

对于的用户输入中出现XSS漏洞的问题，主要是由于开发人员对XSS了解不足，安全的意识不够造成的。现在让我们来普及一下XSS的一些常识，以后在开发的时候，每当有用户输入的内容时，都要加倍小心。请记住两条原则：过滤输入和转义输出。

一、什么是XSS

XSS又叫CSS (Cross Site Script) ，跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意的特殊目的。XSS属于被动式的攻击，因为其被动且不好利用，所以许多人常呼略其危害性。

在WEB2.0时代，强调的是互动，使得用户输入信息的机会大增，在这个情况下，我们作为开发者，在开发的时候，要提高警惕。

二、XSS攻击的主要途径

XSS攻击方法只是利用HTML的属性，作各种的尝试，找出注入的方法。现在对三种主要方式进行分析。

第一种：对普通的用户输入，页面原样内容输出。

打开(限公司IP)，输 入：scriptalert(‘xss’)/script， JS脚本顺利执行。当攻击者找到这种方法后，就可以传播这种链接格式的链接 （）如：http: //go.ent.163.com/goproducttest/test.jsp?key=scriptalert(‘xss’) lt;/script，并对JSCODE做适当伪装，如：

%74%3e%61%6c%65%72%74%28%27%78%73%73%27%29%3c%2f%73%63%72%69%70%74%3e,当其 它用户当点此链接的时候，JS就运行了，造成的后果会很严重，如跳去一个有木马的页面、取得登陆用户的COOKIE等。

第二种：在代码区里有用户输入的内容

原则就是，代码区中，绝对不应含有用户输入的东西。

第三种：允许用户输入HTML标签的页面。

用户可以提交一些自定义的HTML代码，这种情况是最危险的。因为，IE浏览器默认采用的是UNICODE编码，HTML编码可以用ASCII方式来写，又可以使用”/”连接16进制字符串来写，使得过滤变得异常复杂，如下面的四个例子，都可以在IE中运行。

1，直接使用JS脚本。

img src=”javascript:alert(‘xss’)” /

2，对JS脚本进行转码。

img src=”javascript:alert(‘xss’)” /

3，利用标签的触发条件插入代码并进行转码。

img onerror=”alert(‘xss’)” /

4，使用16进制来写(可以在傲游中运行)

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″

以上写法等于img STYLE=”background-image: url(javascript:alert(‘XSS’))”

三、XSS攻击解决办法

请记住两条原则：过滤输入和转义输出。

具体执行的方式有以下几点：

第一、在输入方面对所有用户提交内容进行可靠的输入验证，提交内容包括URL、查询关键字、http头、post数据等

第二、在输出方面，在用户输内容中使用XMP标签。标签内的内容不会解释，直接显示。

第三、严格执行字符输入字数控制。

四、在脚本执行区中，应绝无用户输入。