Denim Group, Ltd. Blog

Strange Google Trades on NASDAQ: Potential Application Security Issue?

By Dan Cornell

Caveat: This is straight from the "totally irresponsible unfounded speculation" department.  I have not seen any evidence that would indicate any sort of hostile intent behind the trades discussed in this post.  However, these trades do raise some important application security issues.

Apparently NASDAQ is backing out some very late-day trades for Google (NASDAQ:GOOG) that were for amounts all over the map (like $0.01/share).  So far the official explanation was that those orders "were triggered by orders routed from another exchange."

When I read that I thought of two things: input validation and threat modeling:

1. Input Validation - It seems to me that when a stock that used to trade for $400.00/share suddenly has trades in the $0.01/share range that this should trigger some sort of input validation routine to flag the transaction as suspect and force it to endure more scrutiny before actually executing.  Now, everyone noticed that these trades were strange after the fact, but why did they even go through in the first place?  Validating inputs to make sure of length, type and so on is important.  But validating inputs against business logic constraints is also critical.
2. Threat Modeling - Inter-exchange trading is a very complicated thing.  What causes trades from one exchange to be trusted by another?  99.9% of the developers out there aren't building inter-exchange trading systems, but the lesson is universal.  Too many systems we review fail to acknowledge trust boundaries between non-standard external interactors and internal processes.  (Most) everyone now acknowledges that system users should be considered untrusted, but we see a lot of systems that implicitly trust data coming back from 3rd party web services, payment gateways, and other clearing houses.  This is a big mistake - if you don't control the system in question it is most likely on the other side of a trust boundary.  Scrutinize the incoming data accordingly.

Presumably this will all get sorted out and it will be interesting to see how much more information about this incident is released to the public.

--Dan
dan _at_ denimgroup.com

Paranoid Android

Google's Android platform made its worldwide debut at the Mobile World Congress in Barcelona on Tuesday. Android is a Linux-based mobile phone platform created by Google in conjunction with the Open Handset Alliance. This set of tools and libraries is designed as a full-fledged SDK for rapid and full-featured mobile and smartphone applications.

Google Android seeks to fill the niche left behind by Palm's sad exodus from the mobile OS business, which by many accounts is still a great, user-friendly OS. While Microsoft's Windows Mobile platform has a lot to be desired in the OS department, it is a joy to develop on, especially if one has a working knowledge of Microsoft's .NET Framework (Windows Mobile uses a diminutive version called the .NET Compact Framework). Of course, programs written for Windows Mobile only run on that OS. Google's Android hopes to bridge that gap by establishing a set of core functionality that can be accessed and run on any mobile operating system.

With this latest debut, vendors (including TI, Qualcomm, Marvell) showed off their wares using Android . By all accounts, even slow processors were able to run fairly sophisticated applications quickly. As time progresses, I'd be interested in learning more about its security features and licensing.

—Erhan K.

Hello Secure World

Microsoft has just created a new security awareness site. This site, http://www.hellosecureworld.com, attempts to provide security awareness and education in the developer community.

The notion of security awareness is very interesting. Michael Howard, during his security development lifecycle presentation given at Denim Group, discussed some of the security classes he taught up in Redmond. These daylong classes were given to developers of different projects. The goal wasn't to make them security gurus or even to remember the difference between, say, symmetric- and asymmetric-key algorithms (if that doesn't take a security guru). The goals were to simply inform developers of common security scenarios and solutions. If they forgot the solutions the minute they left the class, that was OK, as long as that when presented with similar situations, they might recognize the scenario and perhaps Google for a solution (or, since this is Microsoft, perform a Live search).

And just as Microsoft competes with Google (and, at least for now, Yahoo!), Hello Secure World also requires Silverlight, Microsoft's answer to Adobe's Flash.

—Erhan K.

Google's Christmas Gift to Total Information Awareness: Everyone's Google Reader Feed Data

By Dan Cornell

As if unpaid Government informants on Facebook weren't enough, now Google has decided to make your shared RSS feeds on Google Reader available to anyone in your GMail contacts.  Or something like that.  Google says that your "friends" should only be folks in your contacts who you have chatted with via Google Talk but other users disagree and say that isn't how it is behaving.  The important thing is that Google made a decision to "social network" up its hosted Reader product, and they didn't have to check with anyone but themselves to see if that was all right.

There are lots of interesting things at play here:

• Google tried to "after-the-fact" develop an automated authorization policy for how users should share their information.  Therefore it isn't terribly surprising that this auto-authZ-policy doesn't meet the needs of all their users.
• Many users had already developed their own "applications" with specific functionality using the sharing features as they previously behaved.  These weren't application they coded, but ways they leveraged the existing functionality of the application to accomplish some purpose.  If you read through some aggregated Google user feedback in the Slashdot Journal of Felipe Hoffa you can see several examples of how users had created their own new aggregation and discussion areas where they were sharing selected links with selected groups of people (often based on the security-through-obscurity of the URL).  When Google introduced these new features, all the previous business rules about who got to see what went out the window.
• We can see the danger of pollinating functionality and data across multiple applications.  The current hubbub is based on Google creating definitions of relationships based on data being tagged in Google Reader, users existing in GMail, and users having performed actions in Google Talk.  There is tremendous potential to create cool new features from these interactions.  But there are also tremendous, unexplored risks for privacy and security.  The current issues have come up because one provider decided to link up several applications in their portfolio.  Imagine the chaos as these social networking APIs (expecially the ones that operate cross-platform like Google's) start to gain more adoption.
• At the end of the day, this is another reminder that when you put data online in someone else's data center, you have no control over what they do with it.  This has huge implications for Software as a Service (SaaS) businesses and the organizations and individuals who come to rely on them.

Prediction: After a couple more incidents like this, some pseudo-tech-savvy Congressman is going to make some noise pushing for regulation of SaaS businesses - privacy, security, etc.  This will result in Google, Microsoft, social networking sites, etc all pushing to move datacenters offshore to jurisdictions where such pesky legislators don't exist.  We have already seen hints of this a number of times at Denim Group for applications we build.  Clients say "Well, we want to comply in spirit with [Insert regulation X here], but since this will be hosted in [Insert country Y here] we don't really have to worry about that."  Too bad those HavenCo folks seem to have jumped the shark...

Merry Christmas and Happy Holidays to everyone.  Travel safe.

--Dan
dan _at_ denimgroup.com

PS Many thanks to the Wikipedia folks and AZAdam for the base cat image I LOL-Cat'd up.

Google Gears and Security

By Dan Cornell

Google has announced their Google Gears tools for making online/offline web applications.  This is a great idea and I am looking forward to looking into it further.

I was kind of surprised to see that it has to run native code on the local machine.  This isn't a terrible idea - it gives you a lot more capabilities and features.  I had been hoping for a fully browser-based JavaScript datastore with online synchronization capabilities.  Something that would run without any special plugins.  This would be more limited because the browser would have to be back on the network before being closed if you wanted to persist any of the changes that had been made when offline.  Instead they are using a local copy of SQLite along with some other native code/browser plugin stuff.

From a features standpoint that allows you to make much more interesting applications.  Maintaining local-disk state that lives across browser lifetimes is super-helpful.  From a security standpoint, however, this opens up a whole can of worms.  If this framework is going to require a user to run local code attackers are not just limited to breaking current browser security protections.  They can also attack the local code that Google Gears will rely on.  This is a huge difference so we will see how things turn out.

However I was encouraged to see that they have a fledgling security page that talks about design and coding issues that could affect Google Gears applications' security.  They have a little bit of talk about their security model and a little bit of talk about things like SQL injection.  This is a good start but with such a new mentality for building web applications and so much new code in the frameworks I suspect that there will be more than a few security issues to work out - both in the framework and in the application built on top of it.

Fun stuff!

--Dan
dan _at_ denimgroup.com