eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
A test by IT consulting company Chapin Information Services has turned attention toward what is perhaps an undervalued element of browser security-password management.
The company took a look at all the major browsers: Internet Explorer 7, Opera 9.62, Firefox 3.04, Safari 3.2 and Google Chrome. According to the study, each browser was susceptible to a number of vulnerabilities that could expose password information. Of the five, Opera Software‘s Opera and Mozilla Firefox fared the best-meaning they passed seven of the 21 tests. Internet Explorer passed five tests, while Google Chrome and Apple Safari passed only two.
Three issues were cited by CIS as being problems that, when combined, could allow cyber-thieves to steal passwords without a user’s knowledge. The first two are whether the browsers check the destination where passwords are sent and the locations where they are requested.
According to CIS, none of the browsers’ password managers checked the action path when passwords were retrieved or saved. In addition, only Opera and Firefox prevent the browsers’ password manager from delivering a password to a domain other than the one to which the password was delivered when it was saved.
“Intuitively, this is something that should happen all the time,” said Robert Chapin, president of CIS. “If I go to Google.com and I save a password there, and the next day I go to log in again, if Google is telling my browser to send my password to [the] Yahoo Web site, most of these browsers … couldn’t care less where that password is being sent to.”
All this matters, Chapin said, because if there is a Web site that is either compromised or that intentionally allows users to inject their own HTML, users are vulnerable to having their information stolen. However, Ian Fette, a security project manager at Google, correctly pointed out that users in those scenarios would be vulnerable to a number of different attacks.
Other Password Security Issues
“The claimed vulnerability here is that if you don’t check the action authority you might be sending the password to the wrong site, so the attacker would change the action authority to point toward his own site or some other questionable site to steal your password,” Fette said. “If the attacker can actually change the form on the Web page, there is a ton of other things that he could do to get your password.”
In addition, Fette countered that adding such a feature could cause usability problems.
“It might be the case that you have a Web site that’s either a banking Web site or a big commerce Web site with a lot of back-end servers, so they might not always use the same domain name,” he said. “It might not always be ‘mystore.com’-it might be server1.mystore.com … if you put in a check that says the action domain has to be the exact same, then if they ever change their Web site or [are] using some load balancing scheme where they’re sometimes [using] different domains, they would then fail that check.”
Chapin argued that the fact that Firefox addresses this issue means it can work.
“The example of mystore.com vs. server1.mystore.com is invalid when the discussion is about gmail.com versus hotmail.com,” Chapin said. “Every browser can make that distinction because it is already a common feature of JavaScript’s ‘same-origin policy.’ The only real corner case is when mystore.com decides their domain authentication system is going to involve multiple DNS names like login1.mystore.com, login2.mystore.com, etc. There are any number of ways to resolve that case gracefully, but the way Google Chrome does it is by allowing the credentials from any domain to be submitted.”
The third critical issue is whether the password manager delivers a password using a form that is not visible. If an attacker can put an invisible password form on the page and count on the password manager to fill in the form, it is possible to steal a user’s password without the user ever knowing, Chapin explained.
“Firefox and Google Chrome don’t pay any attention to that whatsoever,” he said. “In their Document Object Model, if they find a password field, all bets are off-the password manager gets activated and it sticks a password in there.”
Only Opera and IE required user interaction before a password was retrieved and filled in. Safari required explicit user interaction for passwords to be saved, as did IE; the others did not.
“The password manager is not a relatively large program, but it seems like something that does not get a lot of attention during development,” Chapin said.