facebook's developer verification isn't that bad an idea

earlier this month ryan naraine penned a post critical of facebook's latest effort to crack down on rogue facebook applications.

facebook plans to force app developers to verify themselves either by submitting a phone number or credit card information - essentially to establish a less anonymous identity.

ryan naraine contends:

While this is clearly a step in the right direction, this won’t stop rogue apps from wreaking havoc on the social network.

and he suggests:

Instead of these minor roadblocks, Facebook needs to implement some sort of code signing or code inspection process for every app that’s submitted to its platform.

while he is right that developer verification won't stop rogue apps, what he apparently fails to realize is that NOTHING will really stop the rogue apps, short of closing the application platform to the outside world entirely. preventing web-based malware is comparable to preventing traditional malware that runs on the desktop - there is no panacea, no magic bullet that will make the problem go away.

code signing, for example, can also be bypassed by the serious criminals. don't believe me? we've already seen examples of malware getting digitally signed by gatekeepers of the sort ryan naraine likely has in mind, and the reason is easily deduced - digital signing protects against malicious alteration of legitimate content, but it has no intrinsic strength against malicious parties getting their own content signed. the people who do the signing aren't qualified to determine the safety of the code, and that's not what a signature establishes anyways, it establishes the authenticity of the code.

likewise code inspection is not going to work because facebook just doesn't have the expertise necessary to determine the safety of the code running on it's platform. even if it developed that expertise, it wouldn't scale, and scalability is important. especially when you consider that the malicious facebook developers appear to be taking a page out of traditional malware creator's playbook and going for volume as a means of compensating for the disabling of individual apps.

verifying or certifying the developer instead of the code means that for a malicious developer to continue using a volume-based strategy he'd need to establish a fake identity for each copy of his rogue app. while facebook hasn't set the bar for this very high, it is higher than it used to be and in so doing makes the strategy more expensive for the attacker. additionally, with this framework facebook could easily make it harder or more expensive in the future without changing all that much besides the verification process itself.

it seems clear to me that developer verification will do some good. there will always be room for improvement, regardless of what approach one takes, so let's not pretend like there's a perfect solution out there and facebook is making a mistake by not choosing it - there isn't and they aren't. we'll see how the bad guys adapt to this countermeasure soon enough and then we can start dreaming up new countermeasures for their countermeasures. like the war against desktop malware, web-based malware is going to be another game of cat and mouse / measure-countermeasure - that much was inevitable.

can facebook sanitize application content?

while reading through some blogs this evening i happened across this article by ryan naraine pointing to a register article by dan goodin about an apparent security vulnerability in facebook's 3rd party application platform that allows arbitrary (and possibly malicious) javascript to be executed...

what struck my eye was a notion that facebook was failing to sanitize application content...

this struck me as an odd statement... i've heard of sanitizing input/data - that's something that makes sense since data should adhere to a strictly defined format... names don't go where dates should be, numbers should actually be numeric, escape sequences should be filtered, etc... it's possible to reject everything that doesn't meet the pre-defined criteria...

i'm going to put on my computer scientist hat and say the same is not applicable to applications written in a turing complete language (which javascript is)... the only way to truly 'sanitize' them is to come up with an entirely new and decidedly less than turing complete language for people to use instead... that is likely outside the scope of what facebook or any other application platform provider is willing to invest their time in - especially since it creates a far more restrictive and less rewarding environment for 3rd party application developers to work with, leading to the very likely result of driving them to other, less restrictive platforms...

that's not to say there aren't some specific instruction sequences that facebook can try to filter out, however with all the ways to obfuscate javascript i doubt it would accomplish much - and even if obfuscation weren't a problem the turing completeness would be; you'd never be able to list (never mind filter) all the possible malicious sequences of instructions, nor could you definitively say that those instructions would ever actually be interpreted by the javascript interpreter of a visitor's browser... detecting malicious sequences of javascript instructions in 3rd party applications is similar to detecting malicious programs like viruses or worms - in fact, they are identical problems and so it should come as no surprise that detecting such malicious sequences of javascript instructions (a necessary precursor to sanitizing the javascript) is reducible to the halting problem... therefore facebook may technically be correct in saying there's no vulnerability (though i have no idea if they actually analyzed the issue in this manner) in the sense that most people would consider... just because you can do bad things doesn't mean there's a vulnerability... sometimes it just means there's more flexibility than you were expecting or wanted...

at any rate, facebook has other ways of dealing with malicious application content - they block the entire application once they discover it's bad... after all, even if they did somehow manage to sanitize javascript, what about flash? or java? or activex? it's not feasible to manually audit all applications before they're allowed to go live on facebook, and it's not possible to find all the malicious code with automated auditing because of the halting problem - so, like more traditional forms of malicious code, malicious facebook applications are something that must inevitably be dealt with after the fact...