Google Online Security Blog: 2009

More Information about Malware Details

November 24, 2009

Posted by: Lucas Ballard, Anti-Malware TeamWebmaster Tools featureWebmaster Toolsappeal request

Do machines dream of electric malware?

October 29, 2009

Posted by: Oliver Fisher, Anti-Malware Teamanti-malware processesshowing snippets of the malicious code we findWebmaster Toolstips for finding hidden malware and cleaning up websitesWebmaster Central BlogWebmaster Toolsseveral administrative email addressesWebmaster Tools
We recently discovered that some of your pages can cause users to be infected with malicious software. We have begun showing a warning page to users who visit these pages by clicking a search result on Google.com.
...
We strongly encourage you to investigate this immediately to protect your visitors. Although some sites intentionally distribute malicious software, in many cases the webmaster is unaware because:
1) the site was compromised
2) the site doesn't monitor for malicious user-contributed content
3) the site displays content from an ad network that has a malicious advertiser

If your site was compromised, it's important to not only remove the malicious (and usually hidden) content from your pages, but to also identify and fix the vulnerability. We suggest contacting your hosting provider if you are unsure of how to proceed. StopBadware also has a resource page for securing compromised sites: http://www.stopbadware.org/home/security Once you've secured your site, you can request that the warning be removed by visiting http://www.google.com/support/webmasters/bin/answer.py?answer=45432 and requesting a review. If your site is no longer harmful to users, we will remove the warning.
Webmaster Toolsprotect our advertising networkstheir experiences with deceptive display ads

Best Practices for Verifying and Cleaning up a Compromised Site

October 22, 2009

Written by Panayiotis Mavrommatis, Security Team As part of Cyber Security Awareness Month, Google's Anti-Malware Team is publishing a series of educational blog posts inspired by questions we've received from users. October is a great time to brush up on cyber security tips and ensure you're taking the necessary steps to protect your computer, website, and personal information. For general cyber security tips, check out our online security educational series or visit http://www.staysafeonline.org/. To learn more about malware detection and site cleanup, visit the Webmaster Tools Help Center and Forum.last post1) Verify Your Site with Google Webmaster Tools
added and verified your site's ownershipsamples of the malicious code2) If Your Site Has Been Compromised, Perform a Comprehensive Cleanup
pages listed in Webmaster ToolsRemember to Check Your Web Server Configuration
Deleted & Error Pages: Dark Corners of Your Website Where Malware May Be Lurking
similar problems3) If You Switch Hosting Providers, Disable Access to the Old Version of Your Site
Webmaster ForumBadwareBusters

Protecting Users and Ads from Malware

October 16, 2009

Posted by Eric Davis, Head of Anti-Malvertisingour online security educational serieshttp://www.staysafeonline.org/What is "Malvertising?"Anti-Malvertising.compublishersad operations teamsInternet usersTips for Web Publishers: Know Who You're Working With, Perform Comprehensive QA, & Have a Plan in Placecustom search enginemalvertising research enginehttp://www.anti-malvertising.com/tips-for-publishers

Pay close attention to all agencies and advertisers with whom you work.

Perform due diligence by thoroughly checking prospective partners' references and credentials.

Perform comprehensive QA on all ad creatives.

Protect your own computer and website from infection.

Be aware that various ad networks and exchanges may have significantly different standards for the prevention and detection of malware. No automatic detection system, however robust, can substitute for your own vigilance. However, we strongly advise against exposing your site to harm by using networks or exchanges without strong anti-malware security measures in place.

Ensure your Ad Operations team has an incident response plan in place (for guidance, visit http://www.anti-malvertising.com/tips-for-ad-operations).

Tips for Users: Protect Your Computer, Update Regularly, and Avoid Getting Tricked

Make sure your browser, operating system, software and plugins are all updated regularly (enable auto-updates when possible).

Be aware that malware can be disguised as antivirus/antispyware software in order to trick people into buying or downloading it. Fake (and harmful) software of this kind is known in the web security community as "rogue security software." How to avoid getting tricked? Always research a company's reputation before downloading its software or visiting its website, and be wary of unexpected warnings from products you haven't installed yourself. You can view a list of some legitimate free security scans at http://www.staysafeonline.org/content/free-security-check-ups.

Exercise caution whenever you're prompted to download an email attachment, follow an instant message link, install a plug-in, or download an unfamiliar piece of software.

Protecting the Free Availability of Online Content

Show Me the Malware!

October 12, 2009

written by Lucas Ballard, on behalf of the Anti-Malware, Anti-Malvertising, and Webmaster Tools teams

As part of Cyber Security Awareness Month, we're highlighting cyber security tips and features to help ensure you're taking the necessary steps to protect your computer, website, and personal information. For general cyber security tips, check out our online security educational series or visit http://www.staysafeonline.org/. To learn more about malware detection and site cleanup, visit the Webmaster Tools Help Center and Forum.

To help protect users against malware threats, Google has built automated scanners that detect malware on websites we've indexed. Pages that are identified as dangerous by these scanners are accompanied by warnings in Google search results, and browsers such as Google Chrome, Firefox, and Safari also use our data to show similar warnings to people attempting to visit suspicious sites.

While it is important to protect users, we also know that most of these sites are not intentionally distributing malware. We understand the frustration of webmasters whose sites have been compromised without their knowledge and who discover that their site has been flagged. We proactively offer help to these webmasters: we send email to site administrators when we encounter suspicious content, we provide a list of infected pages in Webmaster Tools, and we maintain a service that allows webmasters to notify us when they have cleaned their sites. Read more about this process in the previous post on this blog.

We're happy to announce that we've launched a feature that enables Google to provide even more detailed help to webmasters. Webmaster Tools now provides webmasters with samples of the malicious code that Google's automated scanners detected on their sites. These samples — which typically take the form of injected HTML tags, JavaScript, or embedded Flash files — are available in the "Malware details" Labs feature in Webmaster Tools. (UPDATE:

Malware details for your site

Malware details for a particular page

The Malware Warning Review Process

October 9, 2009

written by Lucas Ballard and Ke Wang, Anti-Malware TeamAs part of Cyber Security Awareness Month, Google's Anti-Malware Team is publishing a series of educational blog posts inspired by questions we've received from users. October is a great time to brush up on cyber security tips and ensure you're taking the necessary steps to protect your computer, website, and personal information. For general cyber security tips, check out our online security educational series or visit http://www.staysafeonline.org/. To learn more about malware detection and site cleanup, visit the Webmaster Tools Help Center and Forum.tool to file a reviewPart 1: The webmaster's job:stopbadware.org/home/securityIndex Reinclusion request

From the Tool's home page click on the link to the site that is being flagged. This will bring you to the site's Dashboard.

There should be a large red banner across the top of the dashboard that says "This site may be distributing malware." Clicking on the link that says "More Details" expands the dashboard to reveal a list of pages on the site that were found to be malicious.

Below this list is a link that says "Request a review." A webmaster can fill out this form and click the "Request a review" button to initiate the review process.

More detailed instructions can be found herePart 2: Our job:

Malware Statistics Update

August 25, 2009

Posted by Niels Provos, Security TeamAll Your iFrames Point To UsNumber of Entries on the Google Safe Browsing Malware List

Top-10 Malware SitesSearch Results Containing a URL Labeled as Harmful

that we labeled as harmfulAll Your iFrames Point To UsSafe Browsing API

Ask the Google Anti-Malware Team

August 14, 2009

Posted by Fabrice JaubertThe Google Anti-Malware engineering team knows you have many questions related to our scanning and flagging of infected sites, some with short and simple answers and some with more complex answers. The short-answer questions are already -- we hope -- adequately handled on the Webmaster Forums; now we want to do a better job at answering the more complex questions.
To this end, we have created a Google Moderator page for you to submit your questions, and to vote on other webmasters' questions. In two weeks (on Friday the 28th of August), we will close the page and select a few of the top-rated questions. Over the course of the next several weeks, we will do our best to answer each of these in a write-up, to be published here and to the Webmaster Malware Forum.We hope to repeat this exercise (with a fresh Moderator page) in the fall to give you the opportunity to ask more questions.
Thank you, and see you on the Moderator page!

Improving web browser security

July 22, 2009

Posted by Chris Evans, Security TeamBrowser Security Handbookfuzzersinvolved

Some browsers share code bases with Google Chrome, and we collaborate with those browser vendors.

We develop generic fuzzers that are applicable to most browsers and that we want to share with others.

We spend time analyzing behavior in different browsers, and we sometimes discover bugs in the process.

It benefits our users and the Internet as a whole if we work collaboratively on better web browser security.

this one in OperaHTTP 449 response code issue in IEcontributions to Safari 4's securityXMLHttpRequest leakcross-domain leakSSL interactions with HTTP proxiessharing fuzzersApple

Password strength and account recovery options

July 15, 2009

Posted by Macduff Hughes, Engineering Directorinput a mobile phone number to assist with later account recoverychoose good passwords and security questionswhat to do when you can't access your accountset password length requirements and view password strength indicators

HTTPS security for web applications

June 16, 2009

Posted by Alma Whitten, Software Engineer, Security & Privacy Teams

A group of privacy and security experts sent a letter today urging Google to strengthen its leadership role in web application security, and we wanted to offer some of our thoughts on the subject.
We've long advocated for — and demonstrated — a focus on strong security in web applications. We run our own business on Google Apps, and we strive to provide a high level of security to our users. We currently let people access a number of our applications — including Gmail, Google Docs, and Google Calendar, among others — via HTTPS, a protocol that establishes a secure connection between your browser and our servers.

Let's take a closer look at how this works in the case of Gmail. We know that tens of millions of Gmail users rely on it to manage their lives every day, and we have offered HTTPS access as an option in Gmail from the day we launched. If you choose to use HTTPS in Gmail, our systems are designed to maintain it throughout the email session — not just at login — so everything you do can be passed through a more secure connection. Last summer we made it even easier by letting Gmail users opt in to always use HTTPS every time they log in (no need to type or bookmark the "https").
Free, always-on HTTPS is pretty unusual in the email business, particularly for a free email service, but we see it as an another way to make the web safer and more useful. It's something we'd like to see all major webmail services provide.
In fact, we're currently looking into whether it would make sense to turn on HTTPS as the default for all Gmail users.
We know HTTPS is a good experience for many power users who've already turned it on as their default setting. And in this case, the additional cost of offering HTTPS isn't holding us back. But we want to more completely understand the impact on people's experience, analyze the data, and make sure there are no negative effects. Ideally we'd like this to be on by default for all connections, and we're investigating the trade-offs, since there are some downsides to HTTPS — in some cases it makes certain actions slower.
We're planning a trial in which we'll move small samples of different types of Gmail users to HTTPS to see what their experience is, and whether it affects the performance of their email. Does it load fast enough? Is it responsive enough? Are there particular regions, or networks, or computer setups that do particularly poorly on HTTPS?
Unless there are negative effects on the user experience or it's otherwise impractical, we intend to turn on HTTPS by default more broadly, hopefully for all Gmail users. We're also considering how to make this work best for other apps including Google Docs and Google Calendar (we offer free HTTPS for those apps as well).
Stay tuned, but we wanted to share our thinking on this, and to let you know we're always looking at ways to make the web more secure and more useful.

Update @ 1:00pm: We've had some more time to go through the report. There's a factual inaccuracy we wanted to point out: a cookie from Docs or Calendar doesn't give access to a Gmail session. The master authentication cookie is always sent over HTTPS — whether or not the user specified HTTPS-only for their Gmail account. But we can all agree on the benefits of HTTPS, and we're glad that the report recognizes our leadership role in this area. As the report itself points out, "Users of Microsoft Hotmail, Yahoo Mail, Facebook and MySpace are also vulnerable to [data theft and account hijacking]. Worst of all — these firms do not offer their customers any form of protection. Google at least offers its tech savvy customers a strong degree of protection from snooping attacks." We take security very seriously, and we're proud of our record of providing security for free web apps.

Update on June 26th: We've sent a response to the signatories of the letter. You can read it here.

Top 10 Malware Sites

June 3, 2009

Posted by Niels Provos, Security TeamA recent surge in compromised web servers has generated many interesting discussions in online forums and blogs. We thought we would join the conversation by sharing what we found to be the most popular malware sites in the last two months.

As we've discussed previously, we constantly scan our index for potentially dangerous sites. Our automated systems found more than 4,000 different sites that appeared to be set up for distributing malware by massively compromising popular web sites. Of these domains more than 1,400 were hosted in the .cn TLD. Several contained plays on the name of Google such as goooogleadsence.biz, etc.

Safe Browsing APIreportedreported

Reducing XSS by way of Automatic Context-Aware Escaping in Template Systems

March 31, 2009

Posted by Jad S. Boutros, Security TeamBuilding on our earlier posts on defenses against web application flaws ["Automating Web Application Security Testing", "Meet ratproxy, our passive web security assessment tool"], we introduce Automatic Context-Aware Escaping (Auto-Escape for short), a functionality we added to two Google-developed general purpose template systems to better protect against Cross-Site Scripting (XSS).
We developed Auto-Escape specifically for general purpose template systems; that is, template systems that are for the most part unaware of the structure and programming language of the content on which they operate. These template systems typically provide minimal support for web applications, possibly limited to basic escaping functions that a developer can invoke to help escape unsafe content being returned in web responses. Our observation has been that web applications of substantial size and complexity using these template systems have an increased risk of introducing XSS flaws. To see why this is the case, consider the simplified template below in which double curly brackets {{ and }} enclose placeholders (variables) that are replaced with run-time content, presumed unsafe.

<body>
<span style="color:{{USER_COLOR}};">
Hello {{USERNAME}}, view your <a href="{{USER_ACCOUNT_URL}}">Account</a>.
</span>
<script>
var id = {{USER_ID}}; // some code using id, say:
// alert("Your user ID is: " + id);
</script>
</body>
In this template, four variables are used (not in this order):

USER_NAME is inserted into regular HTML text and hence can be escaped safely by HTML-escape.

USER_ACCOUNT_URL is inserted into an HTML attribute that expects a URL and therefore in addition to HTML-escape, also requires validation that the URL scheme is safe. By allowing only a safe white-list of schemes, we can prevent (say) javascript: pseudo-URLs, which HTML-escape alone does not prevent.

USER_COLOR is inserted into a Cascading Style Sheets (CSS) context and therefore requires an escaping that also prevents scripting and other dangerous constructs in CSS such as those possible in expression() or url(). For more information on concerns with harmful content in CSS, refer to the CSS section of the Browser Security Handbook.

USER_ID is inserted into a Javascript variable that expects a number as it is not enclosed in quotes. As such, it requires an escaping that coerces it to a number (which a typical Javascript-escape function does not do), otherwise it can lead to arbitrary javascript execution. More variants may be developed to coerce content to other data types, including arrays and objects.

Each of these variable insertions requires a different escaping method or risks introducing XSS. To keep the example small, we excluded several contexts of interest, particularly style tags, HTML attributes that expect Javascript (such as onmouseover), and considerations of whether attribute values are enclosed within quotes or not (which also affects escaping).
Auto-Escape
The example above demonstrates the importance of understanding the precise context in which variables are being inserted and the need for escaping functions that are both safe and correct for each. For larger and complex web applications, we notice two related vectors for XSS:

A developer forgetting to apply escaping to a given variable.

A developer applying the wrong escaping for that variable for the context in which it is being inserted.

Considering the sheer number of templates in large web applications and the number of untrusted content they may operate on, the process of proper escaping becomes complicated and error prone. It is also difficult to efficiently audit from a security testing perspective. We developed Auto-Escape to take that complexity away from the developer and into the template system and therefore reduce the risks of XSS that would have ensued.
A Look at Implementation
Auto-Escape is a functionality designed to make the Template System web application context-aware and therefore able to apply automatically and properly the escaping required. This is achieved in three parts:

We determined all the different contexts in which untrusted content may be returned and provided proper escaping functions for each. This is part science and part practical. For example, we did not find the need to support variable insertion inside an HTML tag name itself (as opposed to HTML attributes) so we did not build support for it. Other factors come into play, including availability of existing escaping functions and backwards compatibility. As a result, part of that work is template system dependent.

We developed our own parser to parse HTML and Javascript templates. It provides methods which can be queried at a point of interest to obtain the context information necessary for proper escaping. The parser is designed with performance in mind, and it runs in a stream mode without look-ahead. It aims for simplicity while understanding that browsers may be more lenient than specifications, particularly in certain corner cases.

We added an extra step into the parsing that the template system already performs to locate variables, among other needs. This extra step activates our HTML/Javascript parser, queries it for the context of each variable then applies its escaping rules to compute the proper escaping functions to use for each variable. Depending on the template system, this step may be performed only the first time a template is used or for each web response in which case some limitations may be lifted.

A simple mechanism is provided for the developer to indicate that some variables are safe and should not be escaped. This is used for variables that are either escaped through other means in source code or contain trusted markup that should be emitted intact.
Current Status
Auto-Escape has been released with the C++ Google Ctemplate for a while now and it continues to develop there. You can read more about it in the Guide to using Auto-Escape. We also implemented Auto-Escape for the ClearSilver template system and expect it to be released in the near future. Lastly, we are in the process of integrating it into other template systems developed at Google for Java and Python and are interested in working with a few other open source template systems that may benefit from this logic. Our HTML/Javascript parser is already available with the Google Ctemplate distribution and is expected to be released as a stand-alone open source project very soon.
Co-developers: Filipe Almeida and Mugdha Bendre

Why Googlers attend the Internet Identity Workshop

March 26, 2009

Posted by Eric Sachs, Senior Product Manager, Google Security

Google’s participation in the Internet Identity Workshop (IIW) has grown from a few lone individuals at its founding in 2005 to fifteen Googlers at the last IIW. The reason for this growth is that as Google has started to provide more APIs and developer tools for our application hosting business, we have found that standards and interoperability for identity and security on the Internet are critical. Our engineers attend to discuss standards such as OAuth, OpenSocial, OAuth, SAML, Portable Contacts, as well as longer term trends around discovery, malware, phishing, and stronger authentication. Another major topic is the usability of these technologies, which we summarized in a blog post after the last IIW.

We hope that other companies and individuals working in these areas will register to attend IIW 2009a and start building momentum for another great event. If you attended either the Facebook hosted UX summit in Feb 2009 or the Yahoo hosted UX summit in Oct 2008, you can join in further discussions on those topics at the upcoming IIW.

Google attendees: Dirk Balfanz, Nathan Beach, Breno de Medeiros, Cassie Doll, Brian Eaton, Ben Laurie, Kevin Marks, John Panzer, Eric Sachs, and more to come

Sep	OCT	Nov
	26
2024	2025	2026

Security Blog