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 comment in the web page itself 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 OK Alternate-Protocol: 443:quic,p=0.5 Cache-Control: private Content-Encoding: gzip Content-Length: 35486 Content-Type: text/html; charset=UTF-8 Date: Wed, 01 Apr 2015 09:54:14 GMT Expires: Wed, 01 Apr 2015 09:54:14 GMT Server: gws Set-Cookie: [redacted] X-Frame-Options: SAMEORIGIN X-XSS-Protection: 1; mode=block X-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 OK Alternate-Protocol: 443:quic,p=0.5 Cache-Control: private Content-Encoding: gzip Content-Length: 33936 Content-Type: text/html; charset=UTF-8 Date: Wed, 01 Apr 2015 09:58:30 GMT Expires: Wed, 01 Apr 2015 09:58:30 GMT Server: gws Set-Cookie: [redacted] X-XSS-Protection: 1; mode=block X-Firefox-Spdy: h2-15

As a result, anyone was free to display the Google search settings page within an iframe on their own site. By embedding images underneath the displayed images, the attackers could then have gone on to replace the legitimate underlying code Google developers wrote with scripts that cause the displayed links to behave vastly differently from what an end user would have expected. See this link for a more detailed description of how click jacking works. Netcraft reported the threat to Google. As a result, Google developers will no longer use the risky method to display the settings page within an iframe on an external domain.