比特客户端
您的位置：
详解大数据
详解大数据
详解大数据
详解大数据
如 何 正 确 防 御 xss 攻 击
　　XSS:Cross Script，本来简写是，但为了区别样式表的css，因此在领域叫做“XSS”。
　　XSS攻击通常是指通过"HTML注入"篡改了网页，插入了恶意的脚本，从而在用户浏览网页时，控制用户的一种攻击。
　　一、HttpOnly防止劫取Cookie
　　HttpOnly最早由提出，至今已经成为一个标准。浏览器将禁止页面的Javascript访问带有HttpOnly属性的Cookie。目前主流浏览器都支持，HttpOnly解决是XSS后的Cookie支持攻击。
　　我们来看下有没有使用。
　　未登录时的Cookie信息
　　可以看到，所有Cookie都没有设置HttpOnly，现在我登录下
　　发现在个叫BDUSS的Cookie设置了HttpOnly。可以猜测此Cookie用于认证。
　　下面我用PHP来实现下：
　　Php代码
　　header("Set-Cookie: cookie1=test1;");
　　header("Set-Cookie: cookie2=test2;httponly",false);
　　setcookie('cookie3','test3',NULL,NULL,NULL,NULL,false);
　　setcookie('cookie4','test4',NULL,NULL,NULL,NULL,true);
　　alert(document.cookie);
　　js只能读到没有HttpOnly标识的Cookie
　　二、输入检查
　　输入检查一般是检查用户输入的中是否包含一些特殊字符，如&、&、'、"等，如果发现存在特殊字符，则将这些字符过滤或者编码。
　　例如网站注册经常用户名只允许字母和数字的组合，或者邮箱电话，我们会在前端用js进行检查，但在端代码必须再次检查一次，因为客户端的检查很容易绕过。
　　网上有许多开源的“XSS Filter”的实现，但是它们应该选择性的使用，因为它们对特殊字符的过滤可能并非数据的本意。比如一款php的lib_filter类：
　　Php代码
　　$filter = new lib_filter();
　　echo $filter-&go('1+1&1');
　　它输出的是1，这大大歪曲了数据的语义，因此什么情况应该对哪些字符进行过滤应该适情况而定。
　　三、输出检查
　　大多人都知道输入需要做检查，但却忽略了输出检查。
　　1、在HTML标签中输出
　　如代码：
　　Php代码
　　$a = "alert(1);";
　　$b = "";
　　这样客户端受到xss攻击，解决方法就是对变量使用htmlEncode,php中的函数是htmlentities
　　Php代码
　　$a = "alert(1);";
　　$b = "";
　　2、在HTML属性中输出
　　Html代码
　　这种情况防御也是使用htmlEncode
　　在owasp-php中实现:
　　Php代码
　　$immune_htmlattr = array(',', '.', '-', '_');
　　$this-&htmlEntityCodec-&encode($this-&immune_htmlattr, "\"&123123;&\"");
　　这样xss又生效了。首先js变量输出一定要在引号内，但是如果我$c = "\"alert(123);//"，你会发现放引号中都没用，自带的函数都不能很好的满足。这时只能使用一个更加严格的JavascriptEncode函数来保证安全――除数字、字母外的所有字符，都使用十六进制"\xHH"的方式进行编码。这里我采用开源的owasp-php方法来实现
　　Php代码
　　$c = "1;alert(3)";
　　var c = ;
　　最后输出\x22abc\x3Balert\x2B\x2F\x2F
　　4、在事件中输出
　　Html代码
　　可能攻击方法
　　Html代码
　　这个其实就是写在中，所以跟3防御相同
　　5、在css中输出
　　在owasp-php中实现：
　　Php代码
　　$immune = array("");
　　$this-&cssCodec-&encode($immune, 'background:expression(window.x?0:(alert(/XSS/),window.x=1));');
　　6、在地址中输出
　　先确保变量是否是"http"开头，然后再使用js的encodeURI或encodeURIComponent方法。
　　在owasp-php中实现：
　　Php代码
　　$instance = ESAPI::getEncoder();
　　$instance-&encodeForURL(‘url’);
　　四、处理富文体
　　就像我写这篇博客，我几乎可以随意输入任意字符，插入图片，插入代码，还可以设置样式。这个时要做的就是设置好白名单，严格控制标签。能自定义 css件麻烦事，因此最好使用成熟的开源框架来检查。php可以使用htmlpurify
　　五、防御DOM Based XSS
　　DOM Based XSS是从javascript中输出数据到HTML页面里。
　　Js代码
相关文章：
[ 责任编辑：小石潭记 ]
去年，手机江湖里的竞争格局还是…
甲骨文的云战略已经完成第一阶段…
软件信息化周刊
比特软件信息化周刊提供以数据库、操作系统和管理软件为重点的全面软件信息化产业热点、应用方案推荐、实用技巧分享等。以最新的软件资讯，最新的软件技巧，最新的软件与服务业内动态来为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解析如何防止XSS跨站脚本攻击
：老文章了。最近xss火了，发出来看看
这些规则适用于所有不同类别的XSS跨站脚本攻击，可以通过在服务端执行适当的解码来定位映射的XSS以及存储的XSS，由于XSS也存在很多特殊情况，因此强烈推荐使用解码库。另外，基于XSS的DOM也可以通过将这些规则运用在客户端的不可信数据上来定位。&
　　不可信数据
　　不可信数据通常是来自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属性时使用&&并开始新的&SCRIPT&标签。这种攻击将关闭原始context(层次结构的上层部分)，然后开始新的标签允许脚本代码执行。记住，当你试图破坏现有context时你可以跳过很多层次结构的上层部分，例如&/SCRIPT&可以终止脚本块，即使该脚本块被注入脚本内方法调用内的引用字符，这是因为HTML解析器在JavaScript解析器之前运行。
　　Injecting DOWN，下行注入&
　　另一种不太常见的执行XSS注入的方式就是，在不关闭当前context的情况下，引入一个subcontext。例如，将&IMG src=&...&&改为&IMG src=&javascript:alert(1)&&，并不需要躲开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实体编码，如&div&标签内。也可以对进入属性的不可行数据进行实体编码，尤其是当属性中使用引用符号时。但是HTML实体编码并不总是有效，例如将不可信数据放入&script&标签、事件处理器(如onmouseover) 、CSS内部或URL内等。即使你在每个位置都使用HTML实体编码的方法，仍然不能抵御跨站脚本攻击。对于放入不可信数据的HTML文档部分，必须使用escape语法，这也是下面即将讨论的问题。&
　　你需要一个安全编码库
　　编写编码器并不是非常难，不过也有不少隐藏的陷阱。例如，你可能会使用一下解码捷径(JavaScsript 中的&)，但是，这些很容易被浏览器中的嵌套解析器误解，应该使用一个安全的专门解码库以确保这些规则能够正确执行。
　　XSS防御规则
　　下列规则旨在防止所有发生在应用程序的XSS攻击，虽然这些规则不允许任意向HTML文档放入不可信数据，不过基本上也涵盖了绝大多数常见的情况。你不需要采用所有规则，很多企业可能会发现第一条和第二条就已经足以满足需求了。请根据自己的需求选择规则。
　　No.1 & 不要在允许位置插入不可信数据
　　第一条规则就是拒绝所有数据，不要将不可信数据放入HTML文档，除非是下列定义的插槽。这样做的理由是在理列有解码规则的HTML中有很多奇怪的context，让事情变得很复杂，因此没有理由将不可信数据放在这些context中。
&script&...NEVERPUTUNTRUSTEDDATAHERE...&/script&　directlyinascript
&!--...NEVERPUTUNTRUSTEDDATAHERE...--&　　　　　　insideanHTMLcomment
&div...NEVERPUTUNTRUSTEDDATAHERE...=test/&　　　inanattributename
&...NEVERPUTUNTRUSTEDDATAHERE...href=&/test&/&　inatagname
　　更重要的是，不要接受来自不可信任来源的JavaScript代码然后运行，例如，名为&callback&的参数就包含JavaScript代码段，没有解码能够解决。&
　　No.2 & 在向HTML元素内容插入不可信数据前对HTML解码
　　这条规则适用于当你想把不可信数据直接插入HTML正文某处时，这包括内部正常标签(div、p、b、td等)。大多数网站框架都有HTML解码的方法且能够躲开下列字符。但是，这对于其他HTML context是远远不够的，你需要部署其他规则。
&body&...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE... &/body&　　
&div&...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE...&/div&
以及其他的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)必须遵守该规则。
&divattr=...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE...&content&/div&　　insideUNquotedattribute
&divattr='...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE...'&content&/div&　insidesinglequotedattribute
&divattr=&...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE...&&content&/div&　insidedoublequotedattribute
　　除了字母数字字符外，使用小于256的ASCII值&#xHH格式(或者命名的实体)对所有数据进行解码以防止切换属性。这条规则应用广泛的原因是因为开发者常常让属性保持未引用，正确引用的属性只能使用相应的引用进行解码。未引用属性可以被很多字符破坏，包括[space] % * + , - / ; & = & ^ 和 |。&
　　ESAPI参考实施&
String safe = ESAPI.encoder().encodeForHTMLAttribute( request.getParameter( &input& ) );
　　No.4 & 在向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解析器先运行，关闭标签能够关闭脚本块，即使脚本块位于引用字符串中。
　　ESAPI参考实施
Stringsafe=ESAPI.encoder().encodeForJavaScript(request.getParameter(&input&));
　　No.5 & 在向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&标签能够关闭脚本块，即使脚本块位于引用字符串中。
　　ESAPI参考实施
Stringsafe=ESAPI.encoder().encodeForCSS(request.getParameter(&input&));
　　No.6- 在向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] % * + , - / ; & = & ^ 和|)解码。 请注意实体编码在这方面是没用的。
　　ESAPI参考实施&
Stringsafe=ESAPI.encoder().encodeForURL(request.getParameter(&input&));
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467142',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'您的位置： &
防范xss的正确方式
优质期刊推荐XSS跨站脚本攻击剖析与防御_百度百科
XSS跨站脚本攻击剖析与防御
《XSS跨站脚本攻击剖析与防御》是2013年出版的图书，作者是邱永华。
XSS跨站脚本攻击剖析与防御内容介绍
《XSS跨站脚本攻击剖析与防御》是一本专门剖析安全的专业书，总共8章，主要包括的内容如下。第1章 XSS初探，主要阐述了XSS的基础知识，包括XSS的攻击原理和危害。第2章 XSS利用方式，就当前比较流行的XSS利用方式做了深入的剖析，这些攻击往往基于客户端，从挂马、窃取Cookies、到钓鱼欺骗，各种攻击都不容忽视。第3章 XSS测试和利用工具，介绍了一些常见的XSS测试工具。第4章 发掘XSS漏洞，着重以黑盒和白盒的角度介绍如何发掘XSS漏洞，以便帮助读者树立安全意识。第5章 XSS Worm，讲解了Web 2.0的最大威胁——跨站脚本，剖析了Web 2.0相关概念和其核心技术，这些知识对于理解和预防XSS Worm十分重要。第6章 Flash应用安全，就当前的Flash应用安全做出了深入阐述。第7章 深入原理，讨论一些比较深入的XSS理论。第8章 防御，介绍了一些防范XSS攻击的方法，例如，运用XSS Filter进行输入过滤和输出编码，使用Firefox浏览器的插件抵御XSS攻击，使用HTTP-only的Cookies同样能起到保护敏感数据的作用。
《XSS跨站脚本攻击剖析与防御》适合网站管理人员、信息/网络安全或相关工作从业者、软件开发工程师，以及任何对Web安全技术感兴趣的读者。
XSS跨站脚本攻击剖析与防御作者介绍
XSS跨站脚本攻击剖析与防御作品目录
目　录　　第1章　初探　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　的调用　39　　1.6.1　动态调用远程JavaScript　40　　1.6.2　使用window.location.hash　41　　1.6.3　XSS Downloader　41　　1.6.4　备选存储技术　43　　第2章　利用方式剖析　45　　2.1　窃取攻击剖析　45　　2.1.1　Cookie基础介绍　46　　2.1.2　Cookie会话攻击原理剖析　48　　2.1.3　实例剖析　49　　2.2　剖析　51　　2.2.1　了解　51　　2.2.2　XSS实现权限提升　52　　2.2.3　获取网站Webshell　55　　2.3　　57　　2.3.1　XSS Phishing　57　　2.3.2　钓鱼的方式　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　获取客户端　70　　2.6　其他恶意攻击剖析　71　　2.6.1　　71　　2.6.2　DOS和DDOS　72　　2.6.3　XSS Virus/　73　　第3章　测试和工具剖析　75　　3.1　　75　　3.2　Tamper Data　80　　3.3　Live HTTP Headers　82　　3.4　　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　第三种——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　[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　对象　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 与　156　　6.1.2　嵌入Flash文件　158　　6.1.3　语言　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() & XSS　165　　6.3.2　Cross Site Flashing　169　　6.3.3　Flash参数型注入　171　　6.3.4　Flash钓鱼剖析　173　　6.4　利用Flash进行剖析　174　　6.5　利用Flash进行　178　　第7章　深入原理　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进行剖析　203　　7.5.1　Data URIs介绍　203　　7.5.2　Data URIs XSS　204　　7.5.3　vBulletin Data URIs XSS　206　　7.6　 BOM XSS　206　　7.7　浏览器插件安全　211　　7.7.1　Flash后门　211　　7.7.2　来自的　213　　7.7.3　QuickTime XSS　217　　7.8　特殊的XSS应用场景剖析　218　　7.8.1　基于的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章　防御　234　　8.1　使用XSS Filter　234　　8.1.1　输入过滤　235　　8.1.2　输出编码　237　　8.1.3　黑名单和白名单　239　　8.2　定制过滤策略　240　　8.3　编码规范　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　　253　　8.5.4　　254　　8.6　防御攻击　255　　8.6.1　使用POST替代GET　256　　8.6.2　检验HTTP Referer　257　　8.6.3　验证码　258　　8.6.4　使用Token　259　　参考文献　262
．豆瓣读书[引用日期 01:32:34]
企业信用信息