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 > and <. 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]