eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Google is downplaying concerns about security issues tied to cross-domain Web application sharing that could leave Google users open to attack.
Security researcher Aviv Raff posted general details of a cross-domain Web application sharing flaw to his blog Oct. 10. According to Raff, the vulnerability affects several Google applications available across Google subdomains, including those used by Gmail, Google Maps, Google Images, Google News and Google search. When used in conjunction with other vulnerabilities, the issue could pose problems, he wrote.
“For instance, one small XSS issue in Google Maps can now be exploited to hijack Google, Gmail or Google Apps accounts by bypassing the browser’s Same Origin Policy,” Raff wrote. “There were several XSS issues reported in the past, on some of the google.com subdomains, which are now fixed.”
A second researcher, Adrian Pastor, posted proof-of-concept code on GNUCitizen.org showing that attackers can inject their own pages while the browser still shows the Google domain in the address bar. In Pastor’s example, he created a fake log-in page an attacker could use to trick someone into entering log-in information. Pastor wrote on GNUCitizen:
“I thought that showing a live example would help our readers get an idea of what frame injection looks in action. For that purpose, I prepared a rather not elegant proof of concept which takes advantage of the Google Images service. What’s neat is that although the legitimate URL would normally use the images.google.com domain, Google also allow us to use other google.com subdomains such as mail.google.com which is used by Gmail. This is ideal, as we’re trying to accomplish a frame injection attack which can be used to perform phishing attacks against Gmail users.“
Raff claimed he notified Google of the problem in April and company officials said they were looking into it. As of Oct. 10, he hadn’t received any word of a fix, hence his post. When contacted the same day, a Google spokesperson said the company is aware of the issue and has taken steps to prevent it in cases where there are security consequences.
While Pastor’s example page may seem legitimate at first glance, there are ways for users to determine its authenticity. For one thing, the page’s address bar clearly marks it as an HTTP page, whereas all Google’s log-in pages are HTTPS. In addition, Google’s Safe Browsing API also works to protect users from phishing pages.