Tuesday, February 17, 2009

FaceBook's Big Problem

FaceBook, and many other site/applications just like it, has a huge problem.

I've argued before that the enemy of security is complexity (and by extension, extensibility)... so it should be no surprise that FaceBook's biggest problem now is the countless plug-in applications that live in its ecosystem. Plug-in applications (or applets) that rely on the FaceBook API to do simple things like keep state, or interact with Beacon for the average user are indistinguishable from the main FaceBook application... and that's a problem as well.

While the FaceBook.com staff may be doing a relatively good job of keeping their code bug and exploit-free, the same cannot be said for the countless applications that plug into the FaceBook framework. These applications, after all, have their own databases, data source/sinks, and control paths independent of FaceBook, but in the final result cannot stand alone. A recent post to my blog and another blog about a "SQL Injection attack on FaceBook" is not actually an attack against FaceBook at all, but simply against an application off-shoot from the FaceBook.com framework... and while that application is full of SQL Injection goodness [or badness, you decide] this does not necessarily reflect on FaceBook.com itself... or does it?

The issue of extensibility of an application is one of function vs. security... and is an age-old battle. On one hand, FaceBook (and others like it) have the need to extend themselves beyond their own means to incorporate community add-ons that make their platform more attractive. On the other, they realize that by doing this they are stripping the very security features which they depend upon right off... Transferring control to a 3rd party application within the framework of your own application is a scary thing. The delicate balance between extensibility and security is like the dance of death between the cobra and the mongoose... Each, on their own merits, is more important - but when juxtaposed they are like a collission between the unstoppable force and the immovable object - something has to give. [OK, I swear I'm done with metaphors]

The $1Bn question is, where does extensibility bleed out into security hazard and what formula would one use to strike the appropriate balance. While I may not have the exact formula [yet], I would like to offer the following components...

Risk = 1 / (Value[e] - Hazard[e] ) {value != hazard, value > hazard} as {Risk --> 0}

Think of extensibility of a framework/API such as FaceBook as a component of both value & hazard at the same time, because extensibility adds to FaceBook's overall value, but it also increases the hazard. Interesting, right?

No comments:

Google+