Thursday, July 28, 2011
2-step verification: stay safe around the world in 40 languages
(Cross-posted from the Official Google Blog)
Earlier this year, we introduced a security feature called 2-step verification that helps protect your Google Account from threats like password compromise and identity theft. By entering a one-time verification code from your phone after you type your password, you can make it much tougher for an unauthorized person to gain access to your account.
People have told us how much they like the feature, which is why we're thrilled to offer 2-step verification in 40 languages and in more than 150 countries. There’s never been a better time to set it up: Examples in the news of password theft and data breaches constantly remind us to stay on our toes and take advantage of tools to properly secure our valuable online information. Email, social networking and other online accounts still get compromised today, but 2-step verification cuts those risks significantly.
We recommend investing some time in keeping your information safe by watching our 2-step verification video to learn how to quickly increase your Google Account’s resistance to common problems like reused passwords and malware and phishing scams. Wherever you are in the world, sign up for 2-step verification and help keep yourself one step ahead of the bad guys.
To learn more about online safety tips and resources, visit our ongoing security blog series, and review a couple of simple tips and tricks for online security. Also, watch our video about five easy ways to help you stay safe and secure as you browse.
Update on 12/1/11: We recently made 2-step verification available for users in even more places, including Iran, Japan, Liberia, Myanmar (Burma), Sudan and Syria. This enhanced security feature for Google Accounts is now available in more than 175 countries.
Tuesday, July 19, 2011
Using data to protect people from malware
(Cross-posted from the Official Google Blog)
The Internet brings remarkable benefits to society. Unfortunately, some people use it for harm and their own gain at the expense of others. We believe in the power of the web and information, and we work every day to detect potential abuse of our services and ward off attacks.
As we work to protect our users and their information, we sometimes discover unusual patterns of activity. Recently, we found some unusual search traffic while performing routine maintenance on one of our data centers. After collaborating with security engineers at several companies that were sending this modified traffic, we determined that the computers exhibiting this behavior were infected with a particular strain of malicious software, or “malware.” As a result of this discovery, today some people will see a prominent notification at the top of their Google web search results:
This particular malware causes infected computers to send traffic to Google through a small number of intermediary servers called “proxies.” We hope that by taking steps to notify users whose traffic is coming through these proxies, we can help them update their antivirus software and remove the infections.
We hope to use the knowledge we’ve gathered to assist as many people as possible. In case our notice doesn’t reach everyone directly, you can run a system scan on your computer yourself by following the steps in our Help Center article.
Updated July 20, 2011: We've seen a few common questions we thought we'd address here:
- The malware appears to have gotten onto users' computers from one of roughly a hundred variants of fake antivirus, or "fake AV" software that has been in circulation for a while. We aren't aware of a common name for the malware.
- We believe a couple million machines are affected by this malware.
- We've heard from a number of you that you're thinking about the potential for an attacker to copy our notice and attempt to point users to a dangerous site instead. It's a good security practice to be cautious about the links you click, so the spirit of those comments is spot-on. We thought about this, too, which is why the notice appears only at the top of our search results page. Falsifying the message on this page would require prior compromise of that computer, so the notice is not a risk to additional users.
- In the meantime, we've been able to successfully warn hundreds of thousands of users that their computer is infected. These are people who otherwise may never have known.
Tuesday, June 21, 2011
Introducing DOM Snitch, our passive in-the-browser reconnaissance tool
Posted by Radoslav Vasilev, Security Test Engineer
(Cross-posted from the Google Testing Blog)
Every day modern web applications are becoming increasingly sophisticated, and as their complexity grows so does their attack surface. Previously we introduced open source tools such as Skipfish and Ratproxy to assist developers in understanding and securing these applications.
As existing tools focus mostly on testingserver-side code, today we are happy to introduce DOM Snitch — an experimental* Chrome extension that enables developers and testers to identify insecure practices commonly found in client-side code. To do this, we have adopted several approaches to intercepting JavaScript calls to key and potentially dangerous browser infrastructure such as document.write or HTMLElement.innerHTML (among others). Once a JavaScript call has been intercepted, DOM Snitch records the document URL and a complete stack trace that will help assess if the intercepted call can lead to cross-site scripting, mixed content, insecure modifications to the same-origin policy for DOM access, or other client-side issues.
Here are the benefits of DOM Snitch:
*Developers and testers should be aware that DOM Snitch is currently experimental. We do not guarantee that it will work flawlessly for all web applications. More details on known issues can be found here or in the project’s issues tracker.
- Real-time: Developers can observe DOM modifications as they happen inside the browser without the need to step through JavaScript code with a debugger or pause the execution of their application.
- Easy to use: With built-in security heuristics and nested views, both advanced and less experienced developers and testers can quickly spot areas of the application being tested that need more attention.
- Easier collaboration: Enables developers to easily export and share captured DOM modifications while troubleshooting an issue with their peers.
*Developers and testers should be aware that DOM Snitch is currently experimental. We do not guarantee that it will work flawlessly for all web applications. More details on known issues can be found here or in the project’s issues tracker.
Friday, June 17, 2011
Protecting users from malware hosted on bulk subdomain services
Over the past few months, Google’s systems have detected a number of bulk subdomain providers becoming targets of abuse by malware distributors. Bulk subdomain providers register a domain name, like example.com, and then sell subdomains of this domain name, like subdomain.example.com. Subdomains are often registered by the thousands at one time and are used to distribute malware and fake anti-virus products on the web. In some cases our malware scanners have found more than 50,000 malware domains from a single bulk provider.
Google’s automated malware scanning systems detect sites that distribute malware. To help protect users we recently modified those systems to identify bulk subdomain services which are being abused. In some severe cases our systems may now flag the whole bulk domain.
We offer many services to webmasters to help them fight abuse, such as:
- Webmaster Tools lets webmasters find examples of URLs under their domains that may be distributing malware.
- Google Safe Browsing Alerts for Network Administrators allows owners of Autonomous Systems to get notifications for hosts that are involved in malware delivery.
Thursday, June 16, 2011
Trying to end mixed scripting vulnerabilities
A “mixed scripting” vulnerability is caused when a page served over HTTPS loads a script, CSS, or plug-in resource over HTTP. A man-in-the-middle attacker (such as someone on the same wireless network) can typically intercept the HTTP resource load and gain full access to the website loading the resource. It’s often as bad as if the web page hadn’t used HTTPS at all.
A less severe but similar problem -- let’s call it a “mixed display” vulnerability -- is caused when a page served over HTTPS loads an image, iFrame, or font over HTTP. A man-in-the-middle attacker can again intercept the HTTP resource load but normally can only affect the appearance of the page.
Browsers have long used different indicators, modal dialogs, block options or even click-throughs to indicate these conditions to users. If a page on your website has a mixed scripting issue, Chromium will currently indicate it like this in the URL bar:
And for a mixed display issue:
If any of the HTTPS pages on your website show the cross-out red https, there are good reasons to investigate promptly:
- Your website won’t work as well in other modern browsers (such as IE9 or FF4) due to click-throughs and ugly modal dialogs.
- You may have a security vulnerability that could compromise the entire HTTPS connection.
We also added an infobar that shows when a script is being blocked:
As a user, you can choose to reload the website without the block applied. Ideally, in the longer term, the infobar will not have the option for the user to bypass it. Our experience shows that some subset of users will attempt to “click through” even the scariest of warnings -- despite the hazards that can follow.
Tools that can help website owners
If Chromium’s UI shows any mixed content issues on your site, you can try to use a couple of our developer tools to locate the problem. A useful message is typically logged to the JavaScript console (Menu -> Tools -> JavaScript Console):
You can also reload the page with the “Network” tab active and look for requests that were issued over the http:// protocol. It’s worth noting that the entire origin is poisoned when mixed scripting occurs in it, so you’ll want to look at the console for all tabs that reference the indicated origin. To clear the error, all tabs that reference the poisoned origin need to be closed. For particularly tough cases where it’s not clear how the origin became poisoned, you can also enable debugging to the command-line console to see the relevant warning message.
The latest Chromium 13 dev channel build (13.0.782.10) has a command line flag: --no-running-insecure-content. We recommend that website owners and advanced users run with this flag, so we can all help mop up errant sites. (We also have the flag --no-displaying-insecure-content for the less serious class of mixed content issues; there are no plans to block this by default in Chromium 14).
The Chromium 14 release will come with an inverse flag: --allow-running-insecure-content, as a convenience for users and admins who have internal applications without immediate fixes for these errors.
Thanks for helping us push website security forward as a community. Until this class of bug is stamped out, Chromium has your back.
Thursday, May 26, 2011
Safe Browsing Protocol v2 Transition
Last year, we released version 2 of the Safe Browsing API, along with a reference implementation in Python. This version provides more efficient updates compared to version 1, giving clients the most useful (freshest) data first. The new version uses significantly less bandwidth, and also allows us to serve data that covers more URLs than previously possible. Browsers including Chrome and Firefox have already migrated to version 2, and we are confident that the new version works well and delivers significant benefits compared to the previous version.
We are now planning to discontinue version 1 of the protocol to help us better focus our efforts and resources. On December 1, 2011, we will stop supporting version 1 and will take the service down shortly thereafter. If you are currently using version 1 of the protocol, we encourage you to migrate as soon as possible to the new version. In addition to the documentation and reference implementation, there’s a Google Group dedicated to the API where you may be able to get additional advice or ask questions as you prepare to transition. Those of you who who have already migrated to version 2 will not be affected and do not need to take any further action.
If you are looking to migrate from the version 1 API and are worried about the complexity of the version 2 API, we now have a lookup service that you can use in lieu of version 2 of the Safe Browsing Protocol if your usage is relatively low. The lookup service is a RESTful service that lets you send a URL or set of URLs to Google and receive a reply indicating the state of those URLs. You can use this API if you check fewer than 100,000 URLs per day and don’t mind waiting on a network roundtrip. This process may be simpler to use than version 2 of the Safe Browsing Protocol, but it is not supported for users who will generate excessive load (meaning that your software, either your servers or deployed clients, will collectively generate over 100,000 requests to Google in a 24-hour period).
If you are currently using version 1 of the Safe Browsing Protocol, please update to either the Safe Browsing Protocol version 2, or the lookup service, before December 1, 2011. If you have any questions, feel free to check out the Google Safe Browsing API discussion list.
Thursday, May 5, 2011
Website Security for Webmasters
(Cross-posted from the Webmaster Central Blog)
Users are taught to protect themselves from malicious programs by installing sophisticated antivirus software, but they often also entrust their private information to various websites. As a result, webmasters have a dual task to protect both their website itself and the user data that they receive.
Over the years companies and webmasters have learned—often the hard way—that web application security is not a joke; we’ve seen user passwords leaked due to SQL injection attacks, cookies stolen with XSS, and websites taken over by hackers due to negligent input validation.
Today we’ll show you some examples of how a web application can be exploited so you can learn from them; for this we’ll use Gruyere, an intentionally vulnerable application we use for security training internally, and that we introduced here last year. Do not probe others’ websites for vulnerabilities without permission as it may be perceived as hacking; but you’re welcome—nay, encouraged—to run tests on Gruyere.Client state manipulation - What will happen if I alter the URL?
Let’s say you have an image hosting site and you’re using a PHP script to display the images users have uploaded:
http://www.example.com/showimage.php?imgloc=/garyillyes/kitten.jpg
So what will the application do if I alter the URL to something like this and userpasswords.txt is an actual file?
http://www.example.com/showimage.php?imgloc=/../../userpasswords.txt
Will I get the content of userpasswords.txt?
Another example of client state manipulation is when form fields are not validated. For instance, let’s say you have this form:
It seems that the username of the submitter is stored in a hidden input field. Well, that’s great! Does that mean that if I change the value of that field to another username, I can submit the form as that user? It may very well happen; the user input is apparently not authenticated with, for example, a token which can be verified on the server.
Imagine the situation if that form were part of your shopping cart and I modified the price of a $1000 item to $1, and then placed the order.
Protecting your application against this kind of attack is not easy; take a look at the third part of Gruyere to learn a few tips about how to defend your app.
Cross-site scripting (XSS) - User input can’t be trusted
A simple, harmless URL:
http://google-gruyere.appspot.com/611788451095/%3Cscript%3Ealert('0wn3d')%3C/script%3E
But is it truly harmless? If I decode the percent-encoded characters, I get:
<script>alert('0wn3d')</script>Gruyere, just like many sites with custom error pages, is designed to include the path component in the HTML page. This can introduce security bugs, like XSS, as it introduces user input directly into the rendered HTML page of the web application. You might say, “It’s just an alert box, so what?” The thing is, if I can inject an alert box, I can most likely inject something else, too, and maybe steal your cookies which I could use to sign in to your site as you.
Another example is when the stored user input isn’t sanitized. Let’s say I write a comment on your blog; the comment is simple:
<a href=”javascript:alert(‘0wn3d’)”>Click here to see a kitten</a>
If other users click on my innocent link, I have their cookies:
You can learn how to find XSS vulnerabilities in your own web app and how to fix them in the second part of Gruyere; or, if you’re an advanced developer, take a look at the automatic escaping features in template systems we blogged about previously on this blog.
Cross-site request forgery (XSRF) - Should I trust requests from evil.com?
Oops, a broken picture. It can’t be dangerous--it’s broken, after all--which means that the URL of the image returns a 404 or it’s just malformed. Is that true in all of the cases?No, it’s not! You can specify any URL as an image source, regardless of its content type. It can be an HTML page, a JavaScript file, or some other potentially malicious resource. In this case the image source was a simple page’s URL:
That page will only work if I’m logged in and I have some cookies set. Since I was actually logged in to the application, when the browser tried to fetch the image by accessing the image source URL, it also deleted my first snippet. This doesn’t sound particularly dangerous, but if I’m a bit familiar with the app, I could also invoke a URL which deletes a user’s profile or lets admins grant permissions for other users.
To protect your app against XSRF you should not allow state changing actions to be called via GET; the POST method was invented for this kind of state-changing request. This change alone may have mitigated the above attack, but usually it's not enough and you need to include an unpredictable value in all state changing requests to prevent XSRF. Please head to Gruyere if you want to learn more about XSRF.
Cross-site script inclusion (XSSI) - All your script are belong to us
Many sites today can dynamically update a page's content via asynchronous JavaScript requests that return JSON data. Sometimes, JSON can contain sensitive data, and if the correct precautions are not in place, it may be possible for an attacker to steal this sensitive information.
Let’s imagine the following scenario: I have created a standard HTML page and send you the link; since you trust me, you visit the link I sent you. The page contains only a few lines:
<script>function _feed(s) {alert("Your private snippet is: " + s['private_snippet']);}</script><script src="http://google-gruyere.appspot.com/611788451095/feed.gtl"></script>Since you’re signed in to Gruyere and you have a private snippet, you’ll see an alert box on my page informing you about the contents of your snippet. As always, if I managed to fire up an alert box, I can do whatever else I want; in this case it was a simple snippet, but it could have been your biggest secret, too.
It’s not too hard to defend your app against XSSI, but it still requires careful thinking. You can use tokens as explained in the XSRF section, set your script to answer only POST requests, or simply start the JSON response with ‘\n’ to make sure the script is not executable.
SQL Injection - Still think user input is safe?
What will happen if I try to sign in to your app with a username like
JohnDoe’; DROP TABLE members;--
While this specific example won’t expose user data, it can cause great headaches because it has the potential to completely remove the SQL table where your app stores information about members.
Generally, you can protect your app from SQL injection with proactive thinking and input validation. First, are you sure the SQL user needs to have permission to execute “DROP TABLE members”? Wouldn’t it be enough to grant only SELECT rights? By setting the SQL user’s permissions carefully, you can avoid painful experiences and lots of troubles. You might also want to configure error reporting in such way that the database and its tables’ names aren’t exposed in the case of a failed query.
Second, as we learned in the XSS case, never trust user input: what looks like a login form to you, looks like a potential doorway to an attacker. Always sanitize and quotesafe the input that will be stored in a database, and whenever possible make use of statements generally referred to as prepared or parametrized statements available in most database programming interfaces.
Knowing how web applications can be exploited is the first step in understanding how to defend them. In light of this, we encourage you to take the Gruyere course, take other web security courses from the Google Code University and check out skipfish if you're looking for an automated web application security testing tool. If you have more questions please post them in our Webmaster Help Forum.
Subscribe to:
Posts (Atom)