| 01:29 | <james7474> | Join BlackHat_Nexus – Trusted by Over 23,000 Subscribers
|
| 14:58 | <gogo> | Hello. I want to document the latest version of the w3c parser for finding client side vulnerabilities. I started with a DOM XSS using the RFC of the parser with element.innerHTML = "XSS";. My goal is to have the syntax possible for each XSS possible. I started with: https://html.spec.whatwg.org/multipage/parsing.html#overview-of-the-parsing-model according to the schema, the loop starts at the HTML tree builder at https://github.com/WebKit/WebKit/blob/main/Source/WebCore/html/parser/HTMLTreeBuilder.cpp#L816 and then I am wondering if according to the code at https://github.com/WebKit/WebKit/blob/2246a2aa28d527e129ebec66183569db035fdc8a/Source/WebCore/dom/Element.cpp#L4347 , the policy of innerHTML could deny to execute a script even if not sanitized. I need to find the parser location to see the grammar syntax for potential XSS as mentrionned there: https://html.spec.whatwg.org/multipage/dynamic-markup-insertion.html#dom-element-innerhtml . Is Elements::replaceChildrenWithMarkup the parser please? |
| 15:28 | <akaster> | if you're looking for the HTML parser, have you tried looking in the directory called "html/parser" ? https://github.com/WebKit/WebKit/tree/main/Source/WebCore/html/parser |
| 15:32 | <akaster> | also your definition of XSS doesn't seem to make much sense. in what way is javascript code that calls the innerHTML setter of an arbitrary element a cross-site scripting vulnerability? |
| 15:38 | <gogo> | Yes I did. I mentionned it for parser/element webkit folder. |
| 15:44 | <gogo> | To clarify technically: Element.innerHTML = ""; Will not execute contrary to: Element.innerHTML = " That will print the 1. |
| 15:45 | <gogo> | In this contextvi need the parser code of policy/ parser of innerHTML output |
| 16:00 | <Luke Warlow> | you're setting JavaScript code to a HTML sink, if you wrap it in a script element it will execute (I think) |
| 20:37 | <gogo> | wrong. It will not. Sanitization is one of the securing methodologies. Check out at https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-innerhtml-sink to see what you must do with the syntax to make it run. |
| 21:16 | <TabAtkins> | Domenic or annevk : Would be really useful to have one of y'all comment on https://github.com/tc39/proposal-idl/issues/8 about the history of getting W3C to be able to refer to WHATWG specs (so ECMA can do the same). |
| 21:28 | <gogo> | element.innerHTML = "XXX"; calls setInnerHTML at |
| 21:28 | <gogo> | https://github.com/WebKit/WebKit/blob/main/Source/WebCore/dom/Element.cpp#L4347 |
| 23:30 | <Domenic> | There isn't much to say. One day W3C decided to stop self-inflicting problems on themselves. SDOs can set their own policies. Ecma can decide at any time what it wants, and TC39 has a lot of power over Ecma since it's the main spec Ecma produces. |