DOM isolation

I was Googling supergenpass and came across this blog on one of the first few hits:

http://akibjorklund.com/2009/supergenpass-is-not-that-secure#comment-18462

it seems that the bookmarklet operates in the same DOM as the page, and this leaves SGP vulnerable to having its master password field read.

What are the current plans for remedying this? I had suggested using an iframe to isolate the DOM, but I'd like to hear suggestions or if this is even important.

 

Using a base password gets around this vulnerable because this only exposes your master password.

http://discuss.supergenpass.com/This-forum-is-for-discussion-of-new-features-and-future-versions-tp1340384p1340384.html

DOM isolation is a significant problem that I'd like to see resolved. As I see it, the only real solution is to move SuperGenPass to a browser extension, which would require significant development. If anyone else has any ideas, I would love to hear them.

What about randomizing the class name and/or HTML in general? It's surely almost impossible to detect after that.

Randomizing class names is not enough. The issue is a vulnerability that exists for all bookmarklets and, depending on your perspective, JavaScript itself.

The commenter "Tim Anderson" touches on it, but basically the issue is that JavaScript allows you to redefine built-in functions. Site A could host JavaScript code that redefines the "substring" function to execute malicious code. When you run SuperGenPass on Site A, it calls the "substring" function and has no way of detecting that it has been redefined. I have spent many hours confirming this problem and looking unsuccessfully for a workaround.

The quick solution is to use the mobile version when dealing with untrusted websites. The long-term solution is to write SuperGenPass into browser extensions so that it is firewalled from potentially polluted JavaScript. However, I do not currently have the time to do this.

Just to understand. This is LastPass bookmarklet:

javascript: (function () { /*Click_This_Button_To_AutoFill___Copyright_LastPass_all_rights_reserved*/
    _LASTPASS_INC = function (u, s) {
        if (u.match(/_LASTPASS_RAND/)) {
            alert('Cancelling_request_may_contain_randkey');
            return;
        }
        s = document.createElement('script');
        s.setAttribute('type', 'text/javascript');
        s.setAttribute('charset', 'UTF-8');
        s.setAttribute('src', u);
        if (typeof(window.attachEvent) != 'undefined') document.body.appendChild(s);
        else {
            if (document.getElementsByTagName('head').length > 0) {
                document.getElementsByTagName('head').item(0).appendChild(s);
            } else {
                document.getElementsByTagName('body').item(0).appendChild(s);
            }
        }
    };
    _LASTPASS_RAND = 'a8-omissis-09';
    _LASTPASS_INC('https://lastpass.com/bml.php' + String.fromCharCode(63) + 'v=0&a=0&r=' + Math.random() + '&h=13-omissis-f9&u=' + escape(document.location.href));
})();

If a script can redefine "substring" function, it could refefine "escape" function, and then leak LastPass passwords. Isn't it? In other words, if the javascript approach is not secure, then all bookmarklets suffer such vulnerability, even ones which connect to password web-management services. Isn't it?

I've just tried to "hack" escape function. Lastpass box warns me that there is a "discrepancy" about site urls.
In fact, I've recognized that LastPass bookmarklet script adds another script to the page which checks several times document.location.href value.
Anyhow, it seems to be that there are two cases:
1- there is a method that safely checks document.location.href without using any built-in (and redefinable) js function, and I wonder if the same method could be "passed" to supergenpass bookmarklet to avoiding any malicious "hacking".  
2 - there is no such method, and hence (my inference) even LastPass bookmarklet can be "hacked" by a malicious site.
Sorry, I'm only a newbie, so I am not very sure about my arguments.