手工做皮具国外的网站led灯具网站模板
手工做皮具国外的网站,led灯具网站模板,简述网站建设的基本特征,可以赚零花钱的小程序翻译文章#xff0c; 原文#xff1a;Deep dive into browser parsing and XSS payload encoding[1]这篇博客文章将深入探讨HTML#xff0c;URL和JavaScript的规范和解析器#xff0c;以及它们之间的交互如何在跨站点脚本转义中有所作为。对于您而言#xff0c;这可能很难… 翻译文章 原文Deep dive into browser parsing and XSS payload encoding[1]这篇博客文章将深入探讨HTMLURL和JavaScript的规范和解析器以及它们之间的交互如何在跨站点脚本转义中有所作为。对于您而言这可能很难或容易地完成具体取决于您对HTML规范和浏览器解析器的了解程度。而且我保证您这是一篇很长的文章所以准备花一两个小时从中受益。因此在继续讨论主题之前请看一下以下HTML并问自己脚本是否将要执行基础1.URl编码javascript:alert(1)2.字符实体编码为javascriptURL编码为alert(2)3.URL编码:4.字符实体编码 和 5.字符实体编码 和 6.高级7.Button字符实体编码 8.Button Unicode转义序列编码 9. 字符实体编码 alert(0);10. Unicode转义序列编码 alert11.Unicode转义序列编码 alert(11)12.Unicode转义序列编码 alert 和 1213. Unicode转义序列编码 14. Unicode转义序列编码的换行更高级15.这个可以分成几步转化22这些问题的答案在这里[2]测试页面在这里[3]。如果您正确回答了大多数问题并且在尝试查找解决方案时没有将黑客弄乱请在此处停止您无需阅读此博客。否则博客中有关浏览器解析过程的其余部分将有所帮助。解析HTML文档涉及三个主要过程HTML解析器URL解析器和JavaScript解析器。每个解析器负责解码和解析其在文档中的份额以及他们应该如何做到这一点在其相应的解析器规范中明确规定。HTML解析从XSS的角度来看我们最感兴趣的是如何对文档进行标记化因为我们不希望将用户提供的数据最终解析为能够执行脚本的标记。HTML标记化的规范在这里。这是一个冗长的文档我不打算涵盖所有内容。在本文中我将只介绍我对如何完成文档解码以及何时创建新标记感兴趣的部分。HTML解析器用作状态机在其中使用输入流中的字符并根据其转换规则转换到不同的状态。解析期间只要遇到“有三个状态可以包含字符实体“数据状态中的字符引用”“ RCDATA状态中的字符引用”和“属性值状态中的字符引用”。在某些状态下HTML实体将从其“...;”解码形式并将相应的字符插入到数据缓冲区中。例如在 问题4 中“”字符在输入流中被编码为“”并且当解析器处于“数据状态”时将对其进行解析。当解析器遇到字符时它切换到“处于数据状态的字符引用”消耗字符引用并发出相应的字符标记。在这种情况下它是“”。您可能在想这是否意味着标记将被视为open和close标记然后它们中的脚本将被执行这个问题的答案是否定的。其背后的原因是解析器在使用了字符引用后将不会转换为“标签打开状态”因此不会创建新标签。这种确切的行为是我们如何利用字符实体编码来逃避不受信任的用户输入并确保仅将它们解析为数据。现在您可能已经了解了为什么我们需要转义和字符但是为什么我们仍然需要转义字符呢在您看来“”是无辜的并且之后的任何内容仅会被解释为字符引用不会触发并且创建新的“标签打开状态”或“结束标签打开状态”开始。事实是不会破坏HTML级别的转义但会中断其他级别发生的转义。稍后我们将在涉及JavaScript解析时再进行讨论。我之前没有提到过一个概念什么是RCDATA要回答这个问题我们需要了解另一个主题。在HTML中有五种元素:Void elementsarea, base, br, col, embed, hr, img, input, keygen, link, menuitem, meta, param, source, track, wbrRaw text elementsscript, styleRCDATA elementstextarea, titleForeign elementsElements from the MathML namespace and the SVG namespaceNormal elements所有其他允许的HTML元素都是普通元素它们之间的区别如下:Void elements 不能有任何内容(由于没有结束标签因此不能在开始标签和结束标签之间放置任何内容)Raw text elements 可以有文字RCDATA elements 可以有文字和字符引用Foreign elements 可以具有文本字符引用CDATA部分其他元素和注释。Normal elements 可以具有文本字符引用其他元素和注释。如果回到HTML解析器规范可以使用字符引用的状态之一是“处于RCDATA状态的字符引用”。这意味着HTML解析器将解码“textarea”和“title”内部的字符引用。同样在解码那些字符引用时没有输入“标签打开状态”这就是为什么 问题5 中没有脚本执行的原因。此外“RCDATA”还有另外一件特别的事情。当浏览器解析RCDATA元素时它将进入“RCDATA状态”。在这种状态下如果遇到“”。这意味着在RCDATA元素(例如)的标签内它唯一识别并认为是标签的打开标签字符是“ ”或“”取决于打开的标签。因此将不会在“textarea”或“title”内部创建其他标签因此无法在其中执行脚本。这解释了为什么脚本无法在 问题6 中执行。关于另一个元素“CDATA”元素需要注意。 CDATA中包含的任何内容都不会导致解析器创建新的打开标签并且它以“]]”序列结尾。因此如果用户输入要转出CDATA上下文则必须使用不带任何编码的确切“]]”序列否则它将不会脱离上下文。(就是只能使用]]结尾)URL解析URL解析器也被称为建模为状态机其中输入流中的字符可以将其定向到不同的状态。解析器规范在这里。从安全性或XSS转义角度来看有些事情很有趣。首先 URL方案必须使用ASCII字母字符。(U0041-U005A || U0061-U007A)否则状态将转换为“无方案”状态。例如您不能使用任何编码对协议方案进行编码否则URL解析器会将其识别为“无方案”。这就是为什么 问题1 中的脚本不执行的原因因为URL解析器未将URL编码的“javascript”解码并识别为协议。相同的理论也适用于:字符如果编码该字符将不会被识别。这就是为什么 问题3 中的脚本无法执行的原因。但是您可能会想为什么当使用字符实体对方案(javascript)进行编码时问题2 的脚本为什么会执行如果您还记得我们在HTML解析部分中讨论的内容则有一个状态称为“处于属性值状态的字符引用”其中字符引用将被解码并替换为其解码版本。稍后我们将讨论解析顺序但是发生的是HTML解析器解析文档创建标记令牌并解码href属性中的字符实体。然后当HTML解析器完成后URL解析器将启动以解析href值中的链接这时“ javascript”方案已被解码并且被URL解析器识别为该方案。然后URL解析器继续对链接的后续部分进行URL解码。因为该方案是“ javascript”所以JavaScript解析器会进入并执行它这就是为什么执行 问题2 中的脚本的原因。(注意解析的顺序问题)其次URL编码过程使用UTF-8编码方案对每个字符进行编码。如果您尝试使用其他方案对链接进行URL编码而URL解析器无法识别它则这可能变得很重要。Javascript 解析JavaScript解析与HTML解析的不同之处在于该语言本身是上下文无关的语言并且存在描述上下文的语法。基本上可以遵循上下文无关的语法来弄清楚如何解析JavaScript。ECMAScript-262的规范位于此处[4]单独的语法文件位于此处[5]。关于安全性字符如何解码以及在某些情况下转义是否有效有几件特别有趣的事情。首先让我们回到HTML解析的“Raw Text”元素。我有意将其留在本节中因为它与JavaScript解析有关。所有“script”块都属于Raw Text元素并且“script”块具有一个有趣的属性字符引用不会在其中解析和解码。这意味着什么这意味着问题9中的脚本将不会执行。因此如果您是攻击者并尝试使用字符引用对输入进行编码并将其放入脚本块中它将无法执行。那么甥塘塘之类的字符(例如 )呢这些字符中编码的JavaScript是否可以解析并执行好吧简短的答案是有附加条件。较长的答案取决于编码序列的放置位置。首先甥塘塘之类的字符称为Unicode转义序列。根据上下文的不同可以在三个位置放置这些转义序列字符串标识符名称或控制字符。字符串当字符串中存在Unicode转义序列时它们将仅被解释为常规字符但不能解释为 或可以终止字符串上下文的行终止符。ECMAScript规范(在下面列出)中明确指出了这一点。因此Unicode转义序列将永远不会超出JavaScript中的字符串上下文因为它们始终会被解释为字符串文字:ECMA-262 edition5.1 Rev 6, Clause 6ECMAScript differs from the Java programming language in the behaviour of Unicode escape sequences. In a Java program, if the Unicode escape sequence
, for example, occurs within a single-line comment, it is interpreted as a line terminator (Unicode character 000A is line feed) and therefore the next Unicode character is not part of the comment. Similarly, if the Unicode escape sequence occurs within a string literal in a Java program, it is likewise interpreted as a line terminator, which is not allowed within a string literal—one must write instead ofto cause a line feed to be part of the string value of a string literal. In an ECMAScript program, a Unicode escape sequence occurring within a comment is never interpreted and therefore cannot contribute to termination of the comment. Similarly, a Unicode escape sequence occurring within a string literal in an ECMAScript program always contributes a Unicode character to the literal and is never interpreted as a line terminator or as a quote mark that might terminate the string literal.标识符名称当标识符名称中存在Unicode转义序列时它们将被解码并解释为标识符的名称例如函数名称属性名称等。这就是为什么问题10中的脚本是可执行的。如果我们深入研究该规范则还应明确说明如下。Unicode escape sequences are also permitted in an IdentifierName, where they contribute a single character to the IdentifierName, as computed by the CV of the UnicodeEscapeSequence (see 7.8.4). The preceding the UnicodeEscapeSequence does not contribute a character to the IdentifierName. A UnicodeEscapeSequence cannot be used to put a character into an IdentifierName that would otherwise be illegal.控制字符当Unicode转义序列表示控制字符时例如单引号双引号括号等它们将不会被解释为控制字符只会被解码和解析为标识符名称或字符串文字。如果您查看ECMAScript的语法则没有Unicode转义序列可以充当任何控制字符。例如如果解析是在解析函数调用语句则括号必须为(和)而不是(和)之类的字符。通常只有在标识符名称的上下文中Unicode转义序列才会被解释为不是字符串并且它们是唯一可以注入这些编码字符并对其进行解释的位置。如果我们看问题11这是行不通的因为(11)无法正确解释并且因为alert(11)不是有效的标识符名称。问题12 无效因为12不会被解释为字符串文字因为它们必须以单引号或双引号开头或者为ASCII数字。问题13 无效因为“”仅被解释为单引号文字并且字符串现在不完整。问题14 之所以有效是因为 被解释为换行文字而没有引入会破坏JavaScript语法的新换行。解析流在讨论了HTMLURL和JavaScript解析之后您应该对要解码的内容在何种上下文中以及如何进行有很好的了解。现在另一个重要的概念是所有这些如何一起发挥作用网页上有很多地方需要多个解析器来计算。因此在这里我们将简要讨论一下浏览器在解码和转义方面通常如何解析文档。当浏览器从网络堆栈获取内容时HTML解析器被触发并开始标记文档。这是完成字符引用解码的步骤。完成标记化之后将构建DOM树并启动JavaScript解析器解析内联和在脚本块中的脚本。这是解码Unicode转义序列和十六进制转义序列的步骤。同时如果浏览器遇到期望使用URL的上下文则URL解析器也会启动以解码URL内容。这是完成URL解码的步骤。根据URL的位置URL解析器可能会在JavaScript解析器出现之前或之后解析内容。请考虑以下两个示例。例子A例子B例子A中HTML解析器将首先启动并执行用户输入的字符引用解码。然后URL解析器开始对href中的值进行URL解码。最后如果URL方案是javascript则JavaScript解析器将出现并执行Unicode转义序列和十六进制转义序列解码。之后脚本被执行。因此按照HTMLURL和JavaScript的顺序总共进行了三轮解码。例子B中HTML解析器也会首先启动。但是此后JavaScript解析器开始解析onclick处理程序中的值因为在onclick处理程序中需要脚本。解析并执行JavaScript后它看到它正在执行“ window.open()”其中参数应为URL。此时URL解析器开始对用户输入进行URL解码并将结果传递回JavaScript引擎。因此按照HTMLJavaScript和URL的顺序总共进行了三轮解码。是否可能会进行超过三轮的解码考虑下面的例子?例子C示例C与A类似但在JavaScript中有一个“ window.open”调用的意义上也有所不同。因此将在UserInput上进行其他URL解码。通常按照HTMLURLJavaScriptURL的顺序进行四个解码。附录(前面问题的答案)Basics1.URL encoded javascript:alert(1)Answer: The javascript will NOT execute.2. Character entity encoded javascript and URL encoded alert(2)Answer: The javascript will execute.3.URL encoded :Answer: The javascript will NOT execute.4.Character entity encoded and Answer: The javascript will NOT execute.5.Character entity encoded and Answer: The javascript will NOT execute AND the character entities will NOT be decoded either6.Answer: The javascript will NOT execute.Advanced7.ButtonCharacter entity encoded Answer: The javascript will execute.8.ButtonUnicode escape sequence encoded Answer: The javascript will NOT execute.9.Character entity encoded alert(9);Answer: The javascript will NOT execute.10.Unicode Escape sequence encoded alertAnswer: The javascript will execute.11.Unicode Escape sequence encoded alert(11)Answer: The javascript will NOT execute.12.Unicode Escape sequence encoded alert and 12 Answer: The javascript will NOT execute.13.Unicode escape sequence encoded Answer: The javascript will NOT execute.14.Unicode escape sequence encoded line feed.Answer: The javascript will execute.Bonus15.Answer: The javascript will execute.References[1] Deep dive into browser parsing and XSS payload encoding: https://www.attacker-domain.com/2013/04/deep-dive-into-browser-parsing-and-xss.html[2] 这里: http://test.attacker-domain.com/browserparsing/answers.txt[3] 这里: http://test.attacker-domain.com/browserparsing/tests.html[4] 此处: http://www.ecma-international.org/publications/standards/Ecma-262.htm[5] 此处: http://www.antlr3.org/grammar/1206736738015/JavaScript.g
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/pingmian/88309.shtml
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!