This really shouldn’t be that surprising, given that your username is generally consistent across Google services, and a public profile is public. But those who currently have numeric profile addresses (e.g. http://www.google.com/profiles/104424237445852766735) might think their profile is not easily tied to their username.

But by using Picasa, Google’s photo sharing service, it’s often quite simple to go from a numeric profile address to an actual username. To protect yourself from this access, visit the Picasa settings page.  Under “Your gallery URL,” add a new username and select the new username for your gallery URL. Also, you may want to edit your nickname.

In my testing thus far, it matters little whether you’ve used Picasa before – if you have a Gmail account, Picasa is also enabled on your account. And while individual Picasa albums have privacy controls, I have not found a way to block simply loading your Picasa home page.

With the introduction of Buzz, Google is encouraging users to take advantage of Google profiles. But in the process, Google is tying together services that many users may have treated quite distinctly in the past. If you want your Gmail address to remain private, you need to manage properly the other Google services you use to avoid one of them exposing your Gmail username.

Update (Feb. 13): It appears Google has adjusted their services to prevent the original URI trick from working. Previously, adding a profile number to picasaweb.google.com (e.g.  http://picasaweb.google.com/104424237445852766735) would either load a page with the username visible, the username embedded in the page’s source code (_user.name in JavaScript), or an error page in a few particular instances. One configuration that would simply produce an error page was if you had Picasa setup under a different username than your Gmail username, hence my advice. It now seems that using a numeric Picasa URI will either load an error page if the user does have Picasa setup or a page indicating the user does not have Picasa galleries but with no username anywhere in the page.

I’ve already done some preliminary testing to see if Google Reader could also be used to discover usernames, but so far that does not seem possible. Still, it’s wise to be cautious when using a tool that interacts with so many other services.

In broad strokes, a syndicated system occurs when one application or network loads content from another (one-way) while a federated system involves two applications or networks exchanging content in a fully interoperable fashion (two-way). RSS is a syndicated setup – your reader simply loads an XML feed from the site you subscribe to. E-mail is a federated system – many SMTP servers exchange messages with each other.

Both syndicated and federated systems have to deal with a potential security problem: outside content. Any time you load data (particualrly in a web application) that’s not under your control, you need to put in filters to avoid such issues as cross-site scripting. The problem here is not a matter of trust – I’m sure the New York Times considered ReadWriteWeb a trusted source. The problem is that other sources of content may not always provide what your application is expecting. Rather than assume the data’s formatted and encoded correctly, assume it’s not and take appropriate action. This is merely one example of the type of thinking security researchers routinely employ – and a mindset developers need to use more often.

I recently came across another minor example of syndication leading to XSS. The search engine Cuil recently announced that they were launching an opt-in feature to index the posts of your friends on Facebook and include those posts in your search results. Aside from the privacy ramifications (you may be surprised to learn that settings for uninstalled apps and Facebook Connect sites don’t seem to apply to Cuil’s search results), I wondered how secure Cuil’s implementation would be in practice.

Overall, the feature seems to work like most Facebook Connect sites, and thus poses no inherent security problems. However, I did find quickly that Cuil was not encoding the results from Facebook. That is, a friend could post a status saying, “testing <script>alert(document.cookie)</script>” and searching for “testing” in Cuil would load the alert dialog. Obviously the impact of such an attack would be minimal, as it requires jumping through a few hoops first, but it again illustrates accidental XSS via syndicated content. Note that XSS in a Facebook Connect application would open the door to a FAXX-style attack.

An example of a federated system that causes me some concern is Google Wave. When I first started looking at Google Wave from a security standpoint, I admit that I did not fully understand the architecture of the product. In essence, Wave includes two distinct components – a server and a client. On the server end, Wave is an XMPP service that can communicate with any compatible setup. On the client side, Wave is the web interface hosted at wave.google.com for loading messages from servers.

Once I understood this division, I thought it even more important to discuss the security implications of gadgets within waves. I fully expect Google to address most, if not all, of the issues I raised regarding gadgets. (In fact, last time I checked, it appeared they had changed the domains of container iframes, stopping cross-gadget access). But if Wave really does catch on, Google’s client interface will not be the only one on the market. Since gadgets render as HTML/CSS/JavaScript, Wave clients will almost assuredly have some sort of web browser component. If the company that invented Wave did not factor in some of the security considerations I and others have noted in their original client, there’s a good chance other developers will not take into account similar issues unless people raise awareness.

However, security in Wave clients deals with only one direction of a federated system. I’m still wondering how certain aspects of federated waves will work in practice. For instance, from what I understand, each thread of messages in Wave will be stored on the server hosting the thread. What will happen if that server becomes suddenly unavailable? How will corporate record-keeping and e-discovery And while Google’s Wave servers will likely be quite secure, what about other servers?

Granted, some questions about Wave servers could be raised about similar systems, such as e-mail. But several of the decentralized aspects of Wave distinguish it from a typical e-mail setup, and could prove to be good experiments in light of proposals for decentralized social networking. I’ve long supported the idea of distributed social networking, but also felt it could lead to many performance and usability problems not found in a walled garden (I’ve been meaning to write a blog post entitled “In Defense of Walled Gardens” for at least a year). Wave may be one of the first large-scale attempts at building a distributed application somewhat akin to social networking.

First, let me be clear about one point: I would not pretend to know more about application security than the engineers, programmers, and scientists at Google. In addition, I would not want to imply that Google does not care about security or user privacy. I realize that Google takes security issues seriously and has the resources to build highly secure products.

But those realizations are also a source of confusion for me when I observe decisions made about Google Wave. As an outsider, I don’t understand why Wave would include the problems I’ve outlined. What I’ve posted does not involve clever hacks or specific parameters – these problems involve weaknesses in the overall framework of Wave. And such weaknesses relate to well-known issues in application security. In fact, Google has previously addressed deploying third-party code by developing Caja after the launch of OpenSocial.

Returning to the “it’s a preview” argument, though, I would first respond by saying that applications, particularly ones that allow users to embed untrusted third-party code, should include security from the very beginning. Starting with an open model and trying to add restrictions later on is a recipe for disaster.

A larger issue in Wave’s case, though, is that Google has often cast Wave as a reinvention of SMTP e-mail. If you set expectations high, much will be expected of you. If a company with the reputation, resources, and revenue of Google markets a product as a replacement for traditional e-mail, I’m going to evaluate its security even more closely than normal. In my view, the hype that has already built around Wave and the reach it’s already found (Novell is reportedly planning a Wave-based business product in mid-2010) disallow the “preview” excuse.

In addition, if you’re going to reinvent e-mail, don’t forget lessons already learned from traditional e-mail. In a previous post, I outlined four major weaknesses I saw in Google Wave:

1. Allowing scripts and iframes in gadgets with no limits apart from sandboxing
2. Lack of control over what content or users can be added to a wave
3. No simple mechanism for verifying gadget sources or features
4. Automatically loading gadgets when a wave is viewed

Name one webmail interface that executes scripts in messages. Name one recent e-mail client that automatically loads content such as images in messages. Why were such considerations not part of Wave from the very start?

Of course, while Google has at least promised to include further permissions controls in Wave, such controls are one aspect of Wave intentionally left out in initial releases. While one can argue whether Google is correct in the merits of such collaboration, I’m a bit surprised that more of the security implications have not been raised before (at least not to my knowledge). When such changes will appear, though, remains to be seen. Personally, I find it a tad disconcerting that Google has similarly promised such updates as allowing users to turn off Wave’s real-time typing behavior, yet Wave has changed little since its announcement.

Still, I’m confident that Google will address at least some of the issues I’ve raised. If nothing else, I hope I’ve contributed to the public dialogue about Google Wave. I will add that Wave appears to include much security on the backend – most of the problems I’m seeing come in the client implementation. Let’s remember, though, that Wave will be federated. Another reason to bring up client security issues early is that other clients can learn from Google’s implementation. I’m rather concerned that if Wave interfaces proliferate, they may repeat many of the security problems seen in early e-mail interfaces.

I’m also concerned that Wave is not really addressing many of the issues that have plagued e-mail. The current “chaos” with Wave’s lack of permissions does not bode well for how it will handle spam, for instance. Whitelisting alone won’t do the trick. In fact, I would argue that Wave is a collaboration tool, not a communication tool, and thus not a replacement for e-mail.

In conclusion, I’d simply add one more point. While it’s exciting to find exploits such as specific XSS holes on a web site, it’s often more important to raise awareness regarding larger security issues that relate to the overall framework of an application. That’s why I’ve discussed FAXX hacks so much, as they relate to the overall implementation of the Facebook Platform instead of particular vulnerabilities.

Similarly, my concerns about Google Wave thus far involve behaviors built into the current system that open the door for exploiting the privacy and security of users. Preview or not, Wave needs to address these high-level weaknesses if it’s going to match the hype.

However, I also noticed that the container iframes for all of the gadgets I tested used the same domain. That allows one gadget to access the DOM of another gadget. Pictured below is a test gadget that generates an alert displaying the HTML source of the first gadget in the wave, in this case a Yes/No/Maybe gadget from Google.

A test gadget accessing the DOM of another gadget in Google Wave.

What’s the danger in this sort of cross-gadget access? Consider that people have already created gadgets for accessing your Facebook and Twitter via gadgets. Granted, most of those gadgets have used iframes which load other sites, and thus cross-domain rules would prevent any data breaches. Also, one Twitter gadget I tried actually loaded using its own container URI instead of the standard Google server. But as developers continue to publish more powerful gadgets, cross-gadget access poses some serious risks for CSRF and data theft.

After noting potential security issues with the gadgets in Google Wave, I set about to finally setup a BeEF testbed and see if Google Wave was as capable a platform for malware delivery as I suspected.

Example of a BeEF zombie spawned via Google Wave

The picture above shows the results. I successfully created a Google Wave gadget that creates a new BeEF zombie whenever someone views the wave. This does not allow for the keylogger function of BeEF, but I did send an alert dialog (as shown) and used the Chrome DoS function to crash the browser tab. (I could also detect that the zombie machine had Flash installed – imagine the possibilities of using Flash or PDF exploits in an auto-loaded gadget.)

What’s even more disconcerting is that BeEF can integrate with Metasploit to potentially take over a victim’s machine. I do not currently have Metasploit setup to test using Autopwn, but based on my experiences so far, I’m fairly confident such an attack would succeed.

All of these demonstrations about security and Google Wave point to four general weaknesses in Wave’s current structure:

1. Allowing scripts and iframes in gadgets with no limits apart from sandboxing
2. Lack of control over what content or users can be added to a wave
3. No simple mechanism for verifying gadget sources or features
4. Automatically loading gadgets when a wave is viewed

Any one of these issues would be cause for concern, but taken together they present such alarming possibilities as a user getting their computer hacked simply by viewing a wave. Whatever may be said about Google Wave’s usefulness, I have to conclude that the product is not ready for prime time until these types of problems are addressed.

The above screenshot shows an actual gadget inside a Wave that I created to demonstrate it. Imagine the possibilities of connecting Facebook with Google Wave. You could post information to your Facebook profile right from within Wave, or connect wave participants to Facebook profiles. If you came across this gadget in a wave you were viewing, wouldn’t you love to at least try it out?

There’s just one problem. The above gadget is fake. Not the screenshot, mind you – if you’re a Google Wave user, you can see the gadget in action by inserting the gadget http://theharmonyguy.com/facebook.xml into a wave. But nothing will happen when you try to connect.

And in this case, truly nothing will happen, since I’ve designed the gadget to be harmless – your login information is not sent anywhere. But I imagine many users would fall prey to such a trick, which could be easily adapted for phishing attacks. Ask yourself honestly, would you have tried to login? More importantly, if you came across such a gadget in a wave, how would you know whether it came from theharmonyguy.com, facebook.com, or a malicious host?

I post all this to raise a broader point than simply “beware of phishing attacks.” I realize that the balance between security and usability is a constant struggle for developers, or at least should be. Yet I’m somewhat concerned by the patterns we are training users to be accustomed to.

Case in point: chromeless gadgets within a wave that provide no indication of source. In some ways I almost feel that Google Wave is recreating the web browser. Browsers are applications that can load any sort of web page. Google Wave is an application that can load all sorts of web pages within waves. Yet many of the features developed for browsers to warn a user of insecure sites or phishing attacks (even as basic as the address bar, which shows the current domain) are not replicated when a user loads a gadget in Wave. Many have described Wave as a reinvention of e-mail. Reinventing a technology can be very beneficial, but let’s not forget lessons learned in the old technology – there’s a reason most e-mail clients don’t allow iframes and JavaScript, for instance.

I’m certainly not the first to raise these concerns; others have previously mentioned the danger of login forms on iGoogle gadgets. Nor am I saying that I don’t want Google Wave to succeed. But if we’re going to reinvent a technology, let’s address some of these basic issues of user expectations and security precautions from the start.

When I heard that Plaxo had brought an OpenSocial framework online, I decided to check out its security for myself. That led to the first hack of an OpenSocial application, and my white-hat hacking hobby began. Admittedly, the “hack” came from poor coding practices on RockYou’s part, but highlighted the need for better authentication in OpenSocial, a problem corrected in later revisions. Still, the event was an inspiration, and led me to continue investigating my previous hacks of Facebook applications, which led to the more serious issues in this year’s FAXX hacks.

Memories of two years ago came back to mind yesterday when I received a Google Wave invite from a friend. Wave has received its share of hype, despite not being publicly available, though lately it’s drawn increasing criticism. Yet I’ve not seen many people explore the security or privacy implications of using the new platform. I decided to take advantage of the invite and start hacking Wave.

What I find was rather surprising, though not entirely unexpected. I’ve noticed several issues with the current version that could be exploited or create more serious problems in the future. Some will argue that bugs should be expected in early versions of a new product, and that future upgrades will improve the situation.  However, I would contend that some of the points raised here deal with basic aspects that should have been addressed from the very beginning. I would also add that I think Google overlooked an opportunity to add more social networking components to their system that could allow them to offer a stronger alternative to Facebook.

Anyway, here are a few of the problems with Google Wave I’ve noticed so far that I’ve not seen on several other lists of Wave criticisms:

• Allowing iframes in waves. Creating a gadget that loads an iframe is a fairly trivial task. The iframe loads within a container iframe that separates it from the DOM for Wave itself. Still, one can load just about any page using such an iframe. This means that any attack requiring a user to load an infected page, such as my original demonstration of a FAXX hack, can be automated, since viewing the wave loads the iframe page. This can also be easily adapted to make POST requests for CSRF attacks.
• Allowing invisible iframes in waves. Not only can a gadget include an iframe, it can style that iframe to be invisible, either hiding the attack from wave participants or to create a clickjacking attack within the gadget. Basically, while gadgets load in container iframes, they otherwise have free reign to include any HTML a coder desires. Note that allowing iframes could potentially let an attacker include code for finding browser exploits, which can then allow for malware delivery or even taking over a user’s system.
• Allowing scripts in waves. Once again, the scripts execute in a container iframe, so one cannot simply wreak havoc with the main application DOM. But scripts do open up several possibilities. In fact, I’ve already created a wave that forwards users to a particular page as soon as they view the wave, since the script is loaded automatically when someone views the wave.
• Allowing dynamic changes to gadgets. Google may argue that this problem is actually a feature. Essentially, a gadget is loaded dynamically from its source every time a wave is loaded. That means someone could insert an innocent-looking gadget into a wave, then the gadget owner could switch the gadget for a malicious one later on. In fact, since gadgets can be hosted anywhere, an included gadget could even be taken offline, taking away from one of Wave’s selling points (better preserving a record of communications).
• Allowing gadget access to participant information. Currently, a gadget can only access basic identifying information about who participates in a wave and who is viewing the wave when the gadget loads. However, one can already note several indications that Google will likely expand this functionality to resemble a more complete OpenSocial implementation. As with Facebook applications, allowing such unfettered access for any gadget on initialization raises a number of concerns.
• Not allowing users to be removed from a wave. I realize that since waves are shared among participants, removing users raises questions of who in the wave is authorized to make such decisions. Still, I find it a glaring oversight that the product includes no mechanism for removing a user whatsoever, especially considering that anyone can join a public wave.
• Allowing users to add anyone to a wave without approval. If I know the Google account you use for Wave, I can add you as a contact and add you to a wave, which will then appear in your inbox. This all happens without any action on your part. And if I include a malicious gadget, you will load that gadget as soon as you click on the new wave to find out what it’s about.

Once again, many will argue that Google will eventually address these problems, and I certainly hope they do. But I find such oversights of basic security issues rather disconcerting. And while sites such as iGoogle have included “gadgets” with scripts for some time, Wave adds a new dimension in that such gadgets can be loaded with hardly any user interaction or approval.

One possible solution that people will raise is that Google can shut down accounts of known attackers or spammers, ensuring that each Wave user corresponds to a real person who will abide by certain rules, as Facebook has sought to do. But doesn’t this turn Google Wave into exactly the same kind of closed garden which Facebook’s critics have lambasted so often? Yet if Google is not the gatekeeper and opens up the system to users with Google accounts, what has Wave done to address spam and malicious attacks? In fact, as expounded above, if Wave is open to anyone, it provides a powerful new means for delivering malware and exploiting vulnerable users.

Again, I realize that Wave will probably include more privacy controls, such as who can add you to a wave without your permission. But if Google is not building such controls into the product to start with, how effective will they be when they do finally appear?