On 9 Dez., 21:20, Boris Zbarsky <bzbar...@mit.edu> wrote: > On 12/9/10 7:54 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 ? > > Oh, from a tool scanning the DOM you can't. But you can make it appear > in the DOM but be invisible to the user, which is what I thought you > were asking about. > > I see now that you want to ask if there's a password entry field on the > page... but the page can just not use such an entry field at all and use > a regular textfiled instead, no? >
The whole plan depends on the user noticing that his passwords gets "asterisked". With Adrienne's idea it would be possible to sneak a normal text entry through and camouflage it as password entry dialog. My extension will also have to look for text entries with javescript keypress event listeners..... The project gets more complex every day. I am looking forward to tackle that :-) But taking this step will need some Cloud stuff with FP whitelisting I fear. To many pages will use this tech. > > 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. > > Given FormData and XHR, isn't this basically the halting problem? You are right. The whole AntiVirus and attack detection thing is in a decission problem space. Some companies try to sell "Whitelisting" as the solution after AV. Detecting only clean programs and allowing only them to run. This is a classical halting problem. Classifying a program as "definitely doing nothing malicious never ever and in no combination with some other program" is just not possible. Classical AV suffers from not having 100% detection and then some FPs.By using online lookups to fix FPs they can be reduced to almost zero. And the 100% detection thing: Better protect 80 million people than no one. Make it hard for the bad guys and reduce their ROI. Buy time for other technology to be released, for patches to be written. That's the goal. My experience with any kind of blacklist (signatures or URL blacklists): They do not react very well and have their limitations. They are good as additional technology because they are quite easy to maintain. Writing code that detects typcial attacks and blocks this attack technology is far more promising and will force the bad guys to change tactics all the time. A workmate was even able to contribute a lot to getting rid of the whole dialer pest in Germany by detecting dialer technology till there was nothing left for the bad guys to do. Thorsten Sick Before I forget: Next week I will be away from any computer in in the Negev for a few days. Please be patient. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
