On 8 Dez., 19:53, Boris Zbarsky <bzbar...@mit.edu> wrote: > On 12/8/10 5:04 AM, thorsten wrote: > > > What is a bit risky is: Can they hide the password entry or the form > > itself ? > > Yes. >
Heck...this is the only thing where I have no plan B. Can you please tell me how you would hide a password entry from a tool scanning the DOM ? > > If they hack something together to hide it, can we detect > > this hack ? > > Maybe. There are lots and lots of ways to hide things; detecting them > all without hitting false positives would be a pretty tall order. If I get this approved as an official research project in my company, I could get a server facing the internet. With a whitelist "in-the- cloud" as last line of defense I could be a bit more daring and would also get direct feedback whats is going wrong where. FPs can be reduced by just asking the server before warning the user. > > Is there another way to detect if a password has just been > > sent ? > > What do you mean? At the moment I am looking for a password entry in the DOM tree (with attributes matching the HTTP request). This way I detect "Password sent". HTTP content is not relevant. Maybe you got a better idea how to detect that a password is about to be sent. > > Is it possible to restrict keypress event listening to non- > > password entries only? > > Not without breaking existing use cases (e.g. my FIOS modem's login page > relies on a key listener on the password field, as far as I can tell; > certainly the length of the text in the field changes by >1 for every > keystroke I make). Right....I've seen that somewhere too. Worst case: I would have make the criteria that link a password entry to a HTTP request less strict. This will be causing more FPs that must be handled by other smart code in this extension. I still have some ideas how to reduce warning messages. If it flies there will be one more way to fight phising. If it breaks I at least learned how to write larger Firefox Extensions. On the bottom line I just want to find out if there are any other ways besides creating and maintaining blacklists. Some things I was already able to implement in our AV-HTML-Heuristics that worked better than expected. But having the behavior of the phising page, more would be possible. Thanks Thorsten _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
