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: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.DOM Snitch is intended for use by developers, testers, and security researchers alike. Click here to download DOM Snitch. To read the documentation, please visit this page.*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.

Posted by Oliver Fisher, Google Anti-Malware TeamOver the past few months, Google’s systems have detected a number of bulk subdomain providers becoming targets of abuse by malware distributors. Bulk s...ubdomain 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. If you are the owner of a website that is hosted in a bulk subdomain service, please consider contacting your bulk subdomain provider if Google SafeBrowsing shows a warning for your site. The top-level bulk subdomain may be a target of abuse. Bulk subdomain service providers may use Google’s tools to help identify and disable abusive subdomains and accounts.

Posted by Chris Evans and Tom Sepez, Google Chrome Security Team 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. As of the first Chromium 14 canary release (14.0.785.0), we are trialing blocking mixed scripting conditions by default. We’ll be carefully listening to feedback; please leave it on this Chromium bug. 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.

Posted by Ian Fette, Google Security TeamLast year, we released version 2 of the Safe Browsing API, along with a reference implementation in Python. This version provides more efficient updates compar...ed 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.

Posted by Gary Illyes, Webmaster Trends Analyst(Cross-posted from the Webmaster Central Blog)Users are taught to protect themselves from malicious programs by installing sophisticated antivirus softwa...re, 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.jpgSo 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.txtWill 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 trustedA simple, harmless URL:http://google-gruyere.appspot.com/611788451095/%3Cscript%3Ealert('0wn3d')%3C/script%3EBut 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 usMany 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 likeJohnDoe’; 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.

Posted by Moheeb Abu Rajab, Google Security Team For the past five years Google has been offering protection to users against websites that attempt to distribute malware via drive-by downloads — tha...t is, infections that harm users’ computers when they simply visit a vulnerable site. The data produced by our systems and published via the Safe Browsing API is used by Google search and browsers such as Google Chrome, Firefox, and Safari to warn users who may attempt to visit these dangerous webpages. Safe Browsing has done a lot of good for the web, yet the Internet remains rife with deceptive and harmful content. It’s easy to find sites hosting free downloads that promise one thing but actually behave quite differently. These downloads may even perform actions without the user’s consent, such as displaying spam ads, performing click fraud, or stealing other users’ passwords. Such sites usually don’t attempt to exploit vulnerabilities on the user’s computer system. Instead, they use social engineering to entice users to download and run the malicious content. Today we’re pleased to announce a new feature that aims to protect users against these kinds of downloads, starting with malicious Windows executables. The new feature will be integrated with Google Chrome and will display a warning if a user attempts to download a suspected malicious executable file: Download warning This warning will be displayed for any download URL that matches the latest list of malicious websites published by the Safe Browsing API. The new feature follows the same privacy policy currently in use by the Safe Browsing feature. For example, this feature does not enable Google to determine the URLs you are visiting. We’re starting with a small-scale experimental phase for a subset of our users who subscribe to the Chrome development release channel, and we hope to make this feature available to all users in the next stable release of Google Chrome. We hope that the feature will improve our users’ online experience and help make the Internet a safer place. For webmasters, you can continue to use the same interface provided by Google Webmaster Tools to learn about malware issues with your sites. These tools include binaries that have been identified by this new feature, and the same review process will apply.

Posted by Ben Laurie, Google Security Team In the wake of the recent Comodo fraud incident, there has been a great deal of speculation about how to improve the public key infrastructure, on which the... security of the Internet rests. Unfortunately, this isn’t a problem that will be fixed overnight. Luckily, however, experts have long known about these issues and have been devising solutions for some time. Given the current interest it seems like a good time to talk about two projects in which Google is engaged. The first is the Google Certificate Catalog. Google’s web crawlers scan the web on a regular basis in order to provide our search and other services. In the process, we also keep a record of all the SSL certificates we see. The Google Certificate Catalog is a database of all of those certificates, published in DNS. So, for example, if you wanted to see what we think of https://www.google.com/’s certificate, you could do this: $ openssl s_client -connect www.google.com:443 < /dev/null | openssl x509 -outform DER | openssl sha1 depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA verify error:num=20:unable to get local issuer certificate verify return:0 DONE 405062e5befde4af97e9382af16cc87c8fb7c4e2 $ dig +short 405062e5befde4af97e9382af16cc87c8fb7c4e2.certs.googlednstest.com TXT "14867 15062 74" In other words: take the SHA-1 hash of the certificate, represent it as a hexadecimal number, then look up a TXT record with that name in the certs.googlednstest.com domain. What you get back is a set of three numbers. The first number is the day that Google’s crawlers first saw that certificate, the second is the most recent day, and the third is the number of days we saw it in between. In order for the hash of a certificate to appear in our database, it must satisfy some criteria: It must be correctly signed (either by a CA or self-signed). It must have the correct domain name — that is, one that matches the one we used to retrieve the certificate. The basic idea is that if a certificate doesn’t appear in our database, despite being correctly signed by a well-known CA and having a matching domain name, then there may be something suspicious about that certificate. This endeavor owes much to the excellent Perspectives project, but it is a somewhat different approach. Accessing the data manually is rather difficult and painful, so we’re thinking about how to add opt-in support to the Chrome browser. We hope other browsers will in time consider acting similarly. The second initiative to discuss is the DANE Working Group at the IETF. DANE stands for DNS-based Authentication of Named Entities. In short, the idea is to allow domain operators to publish information about SSL certificates used on their hosts. It should be possible, using DANE DNS records, to specify particular certificates which are valid, or CAs that are allowed to sign certificates for those hosts. So, once more, if a certificate is seen that isn’t consistent with the DANE records, it should be treated with suspicion. Related to the DANE effort is the individually contributed CAA record, which predates the DANE WG and provides similar functionality. One could rightly point out that both of these efforts rely on DNS, which is not secure. Luckily we’ve been working on that problem for even longer than this one, and a reasonable answer is DNSSEC, which enables publishing DNS records that are cryptographically protected against forgery and modification. It will be some time before DNSSEC is deployed widely enough for DANE to be broadly useful, since DANE requires every domain to be able to use DNSSEC. However, work is on the way to use DNSSEC for the Certificate Catalog well before the entire DNSSEC infrastructure is ready. If we publish a key for the domain in which we publish the catalog, clients can simply incorporate this key as an interim measure until DNSSEC is properly deployed. Improving the public key infrastructure of the web is a big task and one that’s going to require the cooperation of many parties to be widely effective. We hope these projects will help point us in the right direction.

Posted by Panayiotis Mavrommatis and Noé Lutz, Google Security TeamThe new version of Google Chrome is not only speedier and simpler but it also improves user security by automatically disabling out-o...f-date, vulnerable browser plugins.As browsers get better at auto-updating, out-of-date plugins are becoming the weakest link against malware attacks. Thousands of web sites are compromised every week, turning those sites into malware distribution vectors by actively exploiting out-of-date plugins that run in the browser. Simply visiting one of these sites is usually enough to get your computer infected.Keeping all of your plugins up-to-date with the latest security fixes can be a hassle, so a while ago we started using our 20% time to develop a solution. The initial implementation was a Chrome extension called “SecBrowsing,” which kept track of the latest plugin versions and encouraged users to update accordingly. The extension helped us gather valuable knowledge about plugins, and we started working with the Chrome team to build the feature right inside the browser.With the latest version of Chrome, users will be automatically warned about any out-of-date plugins. If you run into a page that requires a plugin that’s not current, it won’t run by default. Instead, you’ll see a message that will help you get the latest, most secure version of the plugin. An example of this message is below, and you can read more about the feature at the Chromium blog.

Posted by Chris Evans, Robert Swiecki, Michal Zalewski, and Billy Rios, Google Security Team We’ve noticed some highly targeted and apparently politically motivated attacks against our users. We beli...eve activists may have been a specific target. We’ve also seen attacks against users of another popular social site. All these attacks abuse a publicly-disclosed MHTML vulnerability for which an exploit was publicly posted in January 2011. Users browsing with the Internet Explorer browser are affected. For now, we recommend concerned users and corporations seriously consider deploying Microsoft’s temporary Fixit to block this attack until an official patch is available. To help protect users of our services, we have deployed various server-side defenses to make the MHTML vulnerability harder to exploit. That said, these are not tenable long-term solutions, and we can’t guarantee them to be 100% reliable or comprehensive. We’re working with Microsoft to develop a comprehensive solution for this issue. The abuse of this vulnerability is also interesting because it represents a new quality in the exploitation of web-level vulnerabilities. To date, similar attacks focused on directly compromising users' systems, as opposed to leveraging vulnerabilities to interact with web services.

Posted by Nishit Shah, Product Manager, Google Security(Cross-posted from the Official Google Blog)Has anyone you know ever lost control of an email account and inadvertently sent spam—or worse—to the...ir friends and family? There are plenty of examples (like the classic "Mugged in London" scam) that demonstrate why it's important to take steps to help secure your activities online. Your Gmail account, your photos, your private documents—if you reuse the same password on multiple sites and one of those sites gets hacked, or your password is conned out of you directly through a phishing scam, it can be used to access some of your most closely-held information.Most of us are used to entrusting our information to a password, but we know that some of you are looking for something stronger. As we announced to our Google Apps customers a few months ago, we've developed an advanced opt-in security feature called 2-step verification that makes your Google Account significantly more secure by helping to verify that you're the real owner of your account. Now it's time to offer the same advanced protection to all of our users.2-step verification requires two independent factors for authentication, much like you might see on your banking website: your password, plus a code obtained using your phone. Over the next few days, you'll see a new link on your Account Settings page that looks like this:Take your time to carefully set up 2-step verification—we expect it may take up to 15 minutes to enroll. A user-friendly set-up wizard will guide you through the process, including setting up a backup phone and creating backup codes in case you lose access to your primary phone. Once you enable 2-step verification, you'll see an extra page that prompts you for a code when you sign in to your account. After entering your password, Google will call you with the code, send you an SMS message or give you the choice to generate the code for yourself using a mobile application on your Android, BlackBerry or iPhone device. The choice is up to you. When you enter this code after correctly submitting your password we'll have a pretty good idea that the person signing in is actually you.It's an extra step, but it's one that significantly improves the security of your Google Account because it requires the powerful combination of both something you know—your username and password—and something that only you should have—your phone. A hacker would need access to both of these factors to gain access to your account. If you like, you can always choose a "Remember verification for this computer for 30 days" option, and you won't need to re-enter a code for another 30 days. You can also set up one-time application-specific passwords to sign in to your account from non-browser based applications that are designed to only ask for a password, and cannot prompt for the code.To learn more about 2-step verification and get started, visit our Help Center. And for more about staying safe online, see our ongoing security blog series or visit http://www.staysafeonline.org/. Be safe!