解析如何防止XSS跨站脚本攻击.docVIP

　　解析如何防止XSS跨站脚本攻击～教育资源库 　　这些规则适用于所有不同类别的XSS跨站脚本攻击，可以通过在服务端执行适当的解码来定位映射的XSS以及存储的XSS，由于XSS也存在很多特殊情况，因此强烈推荐使用解码库。另外，基于XSS的DOM也可以通过将这些规则运用在客户端的不可信数据上来定位。 　　不可信数据 　　不可信数据通常是来自HTTP请求的数据，以URL参数、表单字段、标头或者Cookie的形式。不过从安全角度来看，来自数据库、网络服务器和其他的数据往往也是不可信的，也就是说，这些数据可能没有完全通过验证。 　　应该始终对不可信数据保持警惕，将其视为包含攻击，这意味着在发送不可信数据之前，应该采取措施确定没有攻击再发送。由于应用程序之间的关联不断深化，下游直译程序执行的攻击可以迅速蔓延。 　　传统上来看，输入验证是处理不可信数据的最好办法，然而，输入验证法并不是注入式攻击的最佳解决方案。首先，输入验证通常是在获取数据时开始执行的，而此时并不知道目的地所在。这也意味着我们并不知道在目标直译程序中哪些字符是重要的。其次，可能更加重要的是，应用程序必须允许潜在危害的字符进入，例如，是不是仅仅因为SQL认为Mr. O#39;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属性时使用gt;并开始新的lt;SCRIPTgt;标签。这种攻击将关闭原始context(层次结构的上层部分)，然后开始新的标签允许脚本代码执行。记住，当你试图破坏现有context时你可以跳过很多层次结构的上层部分，例如lt;/SCRIPTgt;可以终止脚本块，即使该脚本块被注入脚本内方法调用内的引用字符，这是因为HTML解析器在JavaScript解析器之前运行。 　　Injecting DOG src=...gt;改为lt;IMG src=javascript:alert(1)gt;，并不需要躲开HTML属性context，相反只需要引入允许在src属性内写脚本的context即可。另一个例子就是CSS属性中的expression()功能，虽然你可能无法躲开引用CSS属性来进行上行注入，你可以采用xss:expression(ument.ent.cookie))且无需离开现有context。 　　同样也有可能直接在现有context内进行注入，例如，可以采用不可信的输入并把它直接放入JavaScript context。这种方式比你想象的更加常用，但是根本不可能利用escaping(或者任何其他方式)保障安全。从本质上讲，如果这样做，你的应用程序只会成为攻击者将恶意代码植入浏览器的渠