Bug#388149: Info received (Confirmed)

[Alan Woodland]

Ok, I've had a further look into things, and it appears now that the
first injection problem (when allow HTML is unchecked) is with the function:

function htmlToText(aStr) {
    var    formatConverter =
Components.classes["@mozilla.org/widget/htmlformatconverter;1"].createInstance(Components.interfaces.nsIFormatConverter);
    var fromStr =
Components.classes["@mozilla.org/supports-string;1"].createInstance(Components.interfaces.nsISupportsString);
    fromStr.data = aStr;
    var toStr = { value: null };

    try {
        formatConverter.convert("text/html", fromStr,
fromStr.toString().length, "text/unicode", toStr, {});
    } catch(e) {
        return aStr;
    }
    if(toStr.value) {
        toStr =
toStr.value.QueryInterface(Components.interfaces.nsISupportsString);
        return toStr.toString();
    }
    return aStr;
}

from chrome/sage.js. The simplest way to fix this is via a search and
replace for "<" and ">" on the processed string, since the problem stems
from the way formatConverter treats &gt; and &lt;. The thing that
somewhat alarms me with this though is that there are not one, but
several paths through this code I can see that would allow aStr (the
input) to be returned unchanged, which is clearly a very bad thing(tm).

The idea of just doing a search and replace here wouldn't fix it for
good either I don't think. I think I saw at least one more injection
method that worked using CSS on one of the test cases somewhere that
wouldn't get caught by this.

Additionally this wouldn't address the 2nd major problem, namely when
allow HTML tags is on script can be let in in rather a lot of ways, e.g.
onclick="myscript();", <script> etc.... My proposal as a temporary fix
for this problem would be to remove the "allow html" option all
together, until I can produce either a real fix, or upstream do.

Any comments?

Thanks,
Alan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]