hoodwink.d gives the following on FF 1 .0.6 greasemonkey 0.5 running on mac osx 10.4

using hoodlum

Error: uncaught exception: [Exception… “Component returned failure code: 0×80004005 (NS_ERROR_FAILURE) [nsIScriptableUnicodeConverter.ConvertToUnicode]” nsresult: “0×80004005 (NS_ERROR_FAILURE)” location: “JS frame :: chrome://greasemonkey/content/utils.js :: getContents :: line 160” data: no]

iam also on osx 10.4 with gm 0.5 and ff 1.0.6 but no such error here. looks like a gm or ff error more likely. ff yields plenty of those (harmless) NS_ERROR_FAILURE in my experience.

Actually, _why, since you’re using the body appending dealio we discussed, I don’t think we need bother with HoOdLuM_onLoad anymore.

Try disposing of it and see how it works—change the last line of the first replacement text chunk in fixup_script back to:

(function() {

And get rid of the script.sub!(/^\}\)\(\);/, "});") altogether.

Incidentally, gm 0.5 DOES fix the security hole I was bitching about.

Actually, MenTaL, we can use a security token in the HoOdLuM_xmlhttpRequest. When the proxy starts, generate a random session id. And overwrite the hoodwinkd.user.js with code to use the key.

I guess the question is: can Javascript read a function’s source code and parse it for the key?

Another idea. The Javascript could contain a list of URL globs (in its masthead probably) which will be needed for XML HttpRequests. The proxy will allow those URLs from http://current.site/http://remote.com. If I could open a couple hoodwink.d URLs then we could do live preview and Ajax submission. (The last one can save a handful of hits to the server.)

why: Hmm, there’s no way to grab the source of an arbitrary function, that I’m aware of.

So long as the function isn’t physically part of the document in question (which would make its definition accessible via DOM , however briefly), and it’s residing somewhere that you can’t get to via standard XMLHttpRequest, we should be okay.

So that means <script src="..."> pointing to some foreign domain (whose content can be generated by the proxy) should be a safe option for an injected key. Provided we keep it all in a closure or something.

Of course, we have to take pains to ensure that we get the “authentic” XMLHttpRequest in the first place. Imagine the page supplies its own malicious window.XMLHttpRequest to gank our popcorn…

Grabbing the source code of a JavaScript function is usually as easy as doing fun.toString(). Note that this includes the function name(param1, param2) { ... } that surrounds the actual function body. You can filter that out with a good old RegExp.

Note that Function.prototype.toString() is not specified by ECMA -262 to return the actual source code, but it’s what all the browsers do. (And probably other implementations as well…)

So yeah, sticking the session ID in a function is not going to work. All the JavaScript implementations can get that.

Another thing you will want to think about:

If a hoodwink’d script accesses the DOM (or any global javascript object, like String), then it can have it’s call graph – uh – hookdwinked and then the calling page has GM_xmlhttpRequest.

The idea of whitelisting domains is pretty nice, but the hoodwinker will still have access to the domains which are whitelisted. Perhaps that is acceptable.