Announcing "Browser Security Handbook"

Posted by Michael Zalewski, Security Team.

Many people view the task of writing secure web applications as a very complex challenge - in part because of the inherent shortcomings of technologies such as HTTP, HTML, or Javascript, and in part because of the subtle differences and unexpected interactions between various browser security mechanisms.

Through the years, we found that having a full understanding of browser-specific quirks is critical to making sound security design decisions in modern Web 2.0 applications. For example, the same user-supplied link may appear to one browser as a harmless relative address, while another could interpret it as a potentially malicious Javascript payload. In another case, an application may rely on a particular HTTP request that is impossible to spoof from within the browser in order to defend the security of its users. However, an attacker might easily subvert the safeguard by crafting the same request from within commonly installed browser extensions. If not accounted for, these differences can lead to trouble.

In hopes of helping to make the Web a safer place, we decided to release our Browser Security Handbook to the general public. This 60-page document provides a comprehensive comparison of a broad set of security features and characteristics in commonly used browsers, along with (hopefully) useful commentary and implementation tips for application developers who need to rely on these mechanisms, as well as engineering teams working on future browser-side security enhancements.

Please note that given the sheer number of characteristics covered, we expect some kinks in the initial version of the handbook; feedback from browser vendors and security researchers is greatly appreciated.

[NFGB] Link - from Google Online Security Blog Related From Google Blogs: Wordless Wednesday 38 Moving from more to best My 24th & final for the year Cutbacks come to NPR

Native Client: A Technology for Running Native Code on the Web

Posted by Brad Chen, Native Client Team.

Most native applications can access everything on your computer – including your files. This access means that you have to make decisions about which apps you trust enough to install, because a malicious or buggy application might harm your machine. Here at Google we believe you shouldn't have to choose between powerful applications and security. That's why we're working on Native Client, a technology that seeks to give Web developers the opportunity to make safer and more dynamic applications that can run on any OS and any browser. Today, we're sharing our technology with the research and security communities for their feedback to help make this technology more useful and more secure.

Our approach is built around a software containment system called the inner-sandbox that is designed to prevent unintended interactions between a native code module and the host system. The inner-sandbox uses static analysis to detect security defects in untrusted x86 code. Previously, such analysis has been challenging due to such practices as self-modifying code and overlapping instructions. In our work, we disallow such practices through a set of alignment and structural rules that, when observed, enable the native code module to be disassembled reliably and all reachable instructions to be identified during disassembly. With reliable disassembly as a tool, it's then feasible for the validator to determine whether the executable includes unsafe x86 instructions. For example, the validator can determine whether the executable includes instructions that directly invoke the operating system that could read or write files or subvert the containment system itself.

To learn more and help test Native Client, check out our post on the Google Code blog as well as our developer site. Our developer site includes our research paper and of course the source for the project under the BSD license.

We look forward to hearing what you think!

[NFGB] Link - from Google Online Security Blog Related From Google Blogs: More Adventures from SciPy: Jenny Qing Qian It's a girl... and her name is Athena New Resources for Developers Google D.C. Talk next week: Opening government to citizen participation

User Experience in the Identity Community

Eric Sachs & Ben Laurie, Google Security

One of the major conferences on Internet identity standards is the Internet Identity Workshop (IIW), a semiannual 'un-conference' where the sessions are not determined ahead of time. It is attended by a large set of people who work on Internet security and identity standards such as OAuth, OpenID, SAML, InfoCards, etc. A major theme within the identity community this year has been about improving the user experience and growing the adoption of these technologies. The OpenID community is making great progress on user experience, with Yahoo, AOL, and Google quickly improving the support they provide (read a summary from Joseph Smarr of Plaxo). Similarly, the InfoCard community has been working on simplifying the user experience of InfoCard technology, including the updated CardSpace selector from Microsoft.

Another hot topic at IIW centered around how to improve the user experience when testing alternatives and enhancements to passwords to make them less susceptible to phishing attacks. Many websites and enterprises have tried these password enhancements/alternatives, but they found that people complained that they were hard to use, or that they weren't portable enough for people who use multiple computers, including web cafes and smart phones. We have published an article summarizing some of the community's current ideas for how to deploy these new authentication mechanisms using a multi-layered approach that minimizes additional work required by users. We have also pulled together a set of videos showing how a number of these different approaches work with both web-based and desktop applications. We hope this information will be helpful to other websites and enterprises who are concerned about phishing.

[NFGB] Link - from Google Online Security Blog Related From Google Blogs: Holiday templates to keep you organized Gmail on your Google Desktop Working towards "One Africa, One Health" I'm a fan of this app!

Gmail security and recent phishing activity

Posted by Chris Evans

We've seen some speculation recently about a purported security vulnerability in Gmail and the theft of several website owners' domains by unauthorized third parties. At Google we're committed to providing secure products, and we mounted an immediate investigation. Our results indicate no evidence of a Gmail vulnerability.

With help from affected users, we determined that the cause was a phishing scheme, a common method used by malicious actors to trick people into sharing their sensitive information. Attackers sent customized e-mails encouraging web domain owners to visit fraudulent websites such as "google-hosts.com" that they set up purely to harvest usernames and passwords. These fake sites had no affiliation with Google, and the ones we've seen are now offline. Once attackers gained the user credentials, they were free to modify the affected accounts as they desired. In this case, the attacker set up mail filters specifically designed to forward messages from web domain providers.

Several news stories referenced a domain theft from December 2007 that was incorrectly linked to a Gmail CSRF vulnerability. We did have a Gmail CSRF bug reported to us in September 2007 that we fixed worldwide within 24 hours of private disclosure of the bug details. Neither this bug nor any other Gmail bug was involved in the December 2007 domain theft.

We recognize how many people depend on Gmail, and we strive to make it as secure as possible. At this time, we'd like to thank the wider security community for working with us to achieve this goal. We're always looking at new ways to enhance Gmail security. For example, we recently gave users the option to always run their entire session using https.

To keep your Google account secure online, we recommend you only ever enter your Gmail sign-in credentials to web addresses starting with https://www.google.com/accounts, and never click-through any warnings your browser may raise about certificates. For more information on how to stay safe from phishing attacks, see our blog post here.

[NFGB] Link - from Google Online Security Blog Related From Google Blogs: Some favorite Google Maps features now for iPhone 360 degree panoramas in Google Earth Got Questions? Try the new Google Mobile Help Forum Google Maps for iPhone adds Street View, public transit, and walking directions

OAuth for Secure Mashups

Posted by Eric Sachs, Senior Product Manager, Google Security

A year ago, a number of large and small websites announced a new open standard called OAuth. This standard is designed to provide a secure and privacy-preserving technique for enabling specific private data on one site to be accessed by another site. One popular reason for that type of cross-site access is data portability in areas such as personal health records (such as Google Health or Microsoft Healthvault), as well as social networks (such as OpenSocial enabled sites). I originally became involved in this space in the summer of 2005, when Google started developing a feature called AuthSub, which was one of the pre-cursors of OAuth. That was a proprietary protocol, but one that has been used by hundreds of websites to provide add-on services to Google Account users by getting permission from users to access data in their Google Accounts. In fact, that was the key feature that a few of us used to start the Google Health portability effort back when it was only a prototype project with a few dedicated Googlers.

However, with the development of a common Internet standard in OAuth, we see much greater potential for data portability and secure mash-ups. Today we announced that the gadget platform now supports OAuth, and the interoperability of this standard was demonstrated by new iGoogle gadgets that AOL and MySpace both built to enable users to see their respective AOL or MySpace mailboxes (and other information) while on iGoogle. However, to ensure the user's privacy, this only works after the user has authorized AOL or MySpace to make their data available to the gadget running on iGoogle. We also previously announced that third-party developers can build their own iGoogle gadgets that access the OAuth-enabled APIs for Google applications such as Calendar, Picasa, and Docs. In fact, since both the gadget platform and OAuth technology are open standards, we are working to help other companies who run services similar to iGoogle to enhance them with support for these standards. Once that is in place, these new OAuth-powered gadgets that are available on iGoogle will also work on those other sites, including many of the gadgets that Google offers for its own applications. This provides a platform for some interesting mash-ups. For example, a third-party developer could create a single gadget that uses OAuth to access both Google OAuth-enabled APIs (such as a Gmail user's address book) and MySpace OAuth-enabled APIs (such as a user's friend list) and display a mashup of the combination.

While the combination of OAuth with gadgets is an exciting new use of the technology, most of the use of OAuth is between websites, such as to enable a user of Google Health to allow a clinical trial matching site to access his or her health profile. I previously mentioned that one privacy control provided by OAuth is that it defines a standard way for users to authorize one website to make their data accessible to another website. In addition, OAuth provides a way to do this without the first site needing to reveal the identity of the user -- it simply provides a different opaque security token to each additional website the user wants to share his or her data with. It would allow a mutual fund, for example, to provide an iGoogle gadget to their customers that would run on iGoogle and show the user the value of his or her mutual fund, but without giving Google any unique information about the user, such as a social security number or account number. In the future, maybe we will even see industries like banks use standards such as OAuth to allow their customers to authorize utility companies to perform direct debit from the user's bank account without that person having to actually share his or her bank account number with the utility vendor.

The OAuth community is continuing to enhance this standard and is very interested in having more companies engaged with its development. The OAuth.net website has more details about the current standard, and I maintain a website with advanced information about Google's use of OAuth, including work on integrating OAuth with desktop apps, and integrating with federation standards such as OpenID and SAML. If you're interested in engaging with the OAuth community, please get in touch with us.

[NFGB] Link - from Google Online Security Blog Related From Google Blogs: Spice up your inbox with colors and themes Say hello to Gmail voice and video chata Tip: Your email, wherever you are on the web, with Toolbar YouTube - CPG Brands continuing innovation.

Malware? We don't need no stinking malware!

Written by Oliver Fisher

"This site may harm your computer"
You may have seen those words in Google search results — but what do they mean? If you click the search result link you get another warning page instead of the website you were expecting. But if the web page was your grandmother's baking blog, you're still confused. Surely your grandmother hasn't been secretly honing her l33t computer hacking skills at night school. Google must have made a mistake and your grandmother's web page is just fine...



I work with the team that helps put the warning in Google's search results, so let me try to explain. The good news is that your grandmother is still kind and loves turtles. She isn't trying to start a botnet or steal credit card numbers. The bad news is that her website or the server that it runs on probably has a security vulnerability, most likely from some out-of-date software. That vulnerability has been exploited and malicious code has been added to your grandmother's website. It's most likely an invisible script or iframe that pulls content from another website that tries to attack any computer that views the page. If the attack succeeds, then viruses, spyware, key loggers, botnets, and other nasty stuff will get installed.

If you see the warning on a site in Google's search results, it's a good idea to pay attention to it. Google has automatic scanners that are constantly looking for these sorts of web pages. I help build the scanners and continue to be surprised by how accurate they are. There is almost certainly something wrong with the website even if it is run by someone you trust. The automatic scanners make unbiased decisions based on the malicious content of the pages, not the reputation of the webmaster.

Servers are just like your home computer and need constant updating. There are lots of tools that make building a website easy, but each one adds some risk of being exploited. Even if you're diligent and keep all your website components updated, your web host may not be. They control your website's server and may not have installed the most recent OS patches. And it's not just innocent grandmothers that this happens to. There have been warnings on the websites of banks, sports teams, and corporate and government websites.

Uh-oh... I need help!
Now that we understand what the malware label means in search results, what do you do if you're a webmaster and Google's scanners have found malware on your site?

There are some resources to help clean things up. The Google Webmaster Central blog has some tips and a quick security checklist for webmasters. Stopbadware.org has great information, and their forums have a number of helpful and knowledgeable volunteers who may be able to help (sometimes I'm one of them). You can also use the Google SafeBrowsing diagnostics page for your site (http://www.google.com/safebrowsing/diagnostic?site=<site-name-here>) to see specific information about what Google's automatic scanners have found. If your site has been flagged, Google's Webmaster Tools lists some of the URLs that were scanned and found to be infected.

Once you've cleaned up your website, use Google's Webmaster Tools to request a malware review. The automatic systems will rescan your website and the warning will be removed if the malware is gone.

Advance warning
I often hear webmasters asking Google for advance warning before a malware label is put on their website. When the label is applied, Google usually emails the website owners and then posts a warning in Google's Webmaster Tools. But no warning is given ahead of time - before the label is applied - so a webmaster can't quickly clean up the site before a warning is applied.

But, look at the situation from the user's point of view. As a user, I'd be pretty annoyed if Google sent me to a site it knew was dangerous. Even a short delay would expose some users to that risk, and it doesn't seem justified. I know it's frustrating for a webmaster to see a malware label on their website. But, ultimately, protecting users against malware makes the internet a safer place and everyone benefits, both webmasters and users.

Google's Webmaster Tools has started a test to provide warnings to webmasters that their server software may be vulnerable. Responding to that warning and updating server software can prevent your website from being compromised with malware. The best way to avoid a malware label is to never have any malware on the site!

Reviews
You can request a review via Google's Webmaster Tools and you can see the status of the review there. If you think the review is taking too long, make sure to check the status. Finding all the malware on a site is difficult and the automated scanners are far more accurate than humans. The scanners may have found something you've missed and the review may have failed. If your site has a malware label, Google's Webmaster Tools will also list some sample URLs that have problems. This is not a full list of all of the problem URLs (because that's often very, very long), but it should get you started.

Finally, don't confuse a malware review with a request for reconsideration. If Google's automated scanners find malware on your website, the site will usually not be removed from search results. There is also a different process that removes spammy websites from Google search results. If that's happened and you disagree with Google, you should submit a reconsideration request. But if your site has a malware label, a reconsideration request won't do any good — for malware you need to file a malware review from the Overview page.



How long will a review take?
Webmasters are eager to have a Google malware label removed from their site and often ask how long a review of the site will take. Both the original scanning and the review process are fully automated. The systems analyze large portions of the internet, which is big place, so the review may not happen immediately. Ideally, the label will be removed within a few hours. At its longest, the process should take a day or so.

Link - from Google Online Security Blog
Related:
New spam and virus trends from Enterprise
Keyczar: Safe and Simple Cryptography
Are you using the latest web browser?
A picture is worth a thousand words