Home
Home

Of Security

Aug 17 07

Of Security

Paul Weinstein

This past week saw news about leaked source code from Facebook and raised questions about security of personal information on the web. What, a zoomshare user might ask, does this mean for me? Well let us take a look at Facebook and zoomshare and see what we can extrapolate about web security.

Let us say someone got access to some zoomshare code via the web, much like the PHP code posted from Facebook. Our exposed source code might look something similar to the Facebook code:

include_once $_SERVER['PHP_ROOT'].'/lib/statusupdates.php';

// Check and fix broken emails
// LN - disabling due to excessive can_see dirties and sets when enabled.
//check_and_fix_broken_emails($user);

// migrate AIM screenname from profile to screenname table if needed
migrate_screenname ($user);

// homepage announcement variables
$HIDE_ANNOUNCEMENT_BIT = get_site_variable('HIDE_ANNOUNCEMENT_BIT');
$HIDE_INTRO_BITMASK = get_site_variable('HIDE_INTRO_BITMASK');

// todo: password confirmation redirects here (from html/reset.php),
// do we want a confirmation message?
Facebook PHP code
# Basics
use strict;
use warnings;

# Zoomshare Basics
use Ii::CGI qw(:encode);
use Ii::Site;

my $template = undef;
my %include = ();

my $url = $ENV{SHUNT_BASEURL};
( undef, undef, $url, undef ) = split /\//, $url;
my $site = Ii::Site->new(Ii::Site::get_siteroot($url));
zoomshare Perl Code
Despite the different languages being used, PHP for Facebook, Perl for zoomshare, we notice quite a few similarities, we see references for loading other code files. We see variables being created and assigned values. Function calls being made, evocation of common or reusable logic that resides in the loaded source code files. We also see comments about what the code is doing or what needs to be corrected in the code.

Ok, but the real question, if we are malicious at heart, is this code of any use to us? Off-hand, the answer is no. If our goal is to collect a large stash of personal information nothing in this code off-hand will give us that information. Moreover, a quick glance reveals there is nothing here that we can exploit to gain access to personal information. Why, well in part because we don’t have access to all the code libraries in which various logic routines reside. Some of those functions may lead us to where the information is stored, but that doesn’t mean the stored information is in any format we can use. Also keep in mind not all actions undertaken by a user of the web, even on a social site like Facebook, directly involves the use of personal information, thus not all code leads one to the same place.

So we have some code, how might we used it to lead us to what we want? We can try and ‘break’ some function to see how it reacts. Why? Because if we get a ‘nasty’ or ‘debugging’ error message we might be able to gain more information about the underlying system, what assumptions the programmers made and perhaps the personal information we are after.

How would one try and break a function? By injection. Injecting code into text fields or web forms is nothing new. In fact, one doesn’t even need any snippet of source code to try it. One could inject arbitrary code into a form to see how the underlying application behaves or misbehaves. In other words, the leaked Facebook code that everyone was making noise about this week is meaningless to a cracker – as in safe cracker – who might try attacking Facebook or zoomshare in hopes of gaining information of street value.

Alright one doesn’t need any source code to find a crack in the code, nor does access to some or all source code mean a security break is possible. Why is that? Well, as any computer user knows, the good, bad and the ugly behaviors of software can result from complex interactions, in part because human behavior is quite complex. That is what a cracker is looking for, a missing link a ‘I didn’t think of this scenario’ from a computer programmer that can be used to the cracker’s advantage. Code in and of itself can be meaningless, but the behavior of the code is priceless.

So that’s another point we can make about web security, even about computer security in general, what else? That there are degrees to security issues. The degree, which one might not be able to judge given the recent news, of the leaked Facebook code is low to moderate. To be sure you can assume that the folks over at Facebook are reviewing the leaked code, the functions that got exposed, and are working to make sure there isn’t any underlying critical issues one could exploit, but off-hand the risk is minimal.

Finally, what does this mean for zoomshare users? It means we within zoomshare – from customer service to developers to management – understand. We know we’ve been given personal information that needs to be properly taken care of. We also know how web security works, of the threats – there are others besides injection of arbitrary code – and of the defenses. Nothing is unbreakable – that too is a point – but with the proper understanding and process threats can at least be minimized.