No joke: Google’s inadvertently broke site’s security

[Reefa]

An April Fool's prank Google pulled two weeks ago inadvertently broke some of the site's security, an error that briefly allowed so-called click-jacking exploits that trick users into performing undesired actions such as changing their user preferences.

Google's April Fool's pranks have become a favorite pastime on the Internet. This year, people who visited the site on April 1 found the entire contents of Google's iconic home page displayed backwards. Web developing nerds also found a line in Google's Web response headers that read "!sLooF LIRPA YPPAH," which spells "Happy April Fool's" backward. According to a blog post published Friday by researchers from Netcraft, the prank also caused Google's homepage to omit a crucial header that's used to prevent click-jacking attacks.

Attackers could have seized on the omission of the X-Frame-Options header to change a user's search settings, including turning off SafeSearch filters. The chief reason for using X-Frame-Options is to prevent the use of HTML iframe tags to display Google's homepage on third-party Web pages. With that protection bypassed, attackers were free to stitch the Google page into their own site and embed hidden code that changed the function of certain links. As the Netcraft blog post explained:

The issue stemmed from the way com.google used an iframe to display backwards content from google.com. This would not normally be possible, as google.com uses the X-Frame-Options HTTP response header to prevent other websites from displaying itself within an iframe. But for the purpose of the April Fool's joke, Google stepped around this problem by passing the parameter "igu=2" to google.com, which not only told it to display the content backwards, but also instructed the server to omit the X-Frame-Options header entirely.

A remote attacker could also have leveraged this "feature" to display the Google Search Settings page in an iframe on an external domain, and trick his victims into unwittingly changing those settings. A carefully constructed clickjacking attack could have gone unnoticed by each victim until it was too late and the settings had already been changed.

To highlight the different responses, the following was an ordinary response from Google's Search Settings page at https://www.google.com/preferences?hl=en&fg=1. Note the presence of the X-Frame-Options header:

HTTP/2.0 200 OKAlternate-Protocol: 443:quic,p=0.5Cache-Control: privateContent-Encoding: gzipContent-Length: 35486Content-Type: text/html; charset=UTF-8Date: Wed, 01 Apr 2015 09:54:14 GMTExpires: Wed, 01 Apr 2015 09:54:14 GMTServer: gwsSet-Cookie: [redacted]X-Frame-Options: SAMEORIGINX-XSS-Protection: 1; mode=blockX-Firefox-Spdy: h2-15

Conversely, with the igu=2 parameter appended, the X-Frame-Options header was omitted from the response, allowing the page to be displayed in a frame on an attacker's own website:

HTTP/2.0 200 OKAlternate-Protocol: 443:quic,p=0.5Cache-Control: privateContent-Encoding: gzipContent-Length: 33936Content-Type: text/html; charset=UTF-8Date: Wed, 01 Apr 2015 09:58:30 GMTExpires: Wed, 01 Apr 2015 09:58:30 GMTServer: gwsSet-Cookie: [redacted]X-XSS-Protection: 1; mode=blockX-Firefox-Spdy: h2-15

http://arstechnica.com/security/2015/04/no-joke-googles-april-fools-prank-inadvertently-broke-sites-security/

[player]

Attackers could have seized on the omission of the X-Frame-Options header to change a user's search settings

I have to visit the source article in order to get the idea. I thought the prank was played by google.com

in fact it was on a new domain http://com.google, which then makes sense why they dropped the same-origin policy.