Following my talk on web application security at the Web Directions North I had a lot of questions on PHP security and I have to admit I am OK but not an expert on the matter. Luckily enough there are experts I rely on and if you are in London next Tuesday you can go and see them give a talk for free!

In the second in the series of “YDN Tuesday” monthly events, Jose Palazon, Yahoo’s mobile security expert, will be talking about PHP Security.

The venue is Skills Matter Limited at 1 Sekforde Street, EC1R 0BE
London, England.

Jose will be presenting a series of demos on how to exploit and prevent the most popular security flaws in web applications, such as SQL and blind SQL Injections, Cross Site Scripting, file uploads, file handling functions, global variables and, favorite of them all, programmers ingenuity!

YDN Tuesdays are tech talks held on the first Tuesday of every month at Skills Matter’s London offices. The events are FREE, but you need to sign up for them at Skills Matter’s website.

I just had a bit of fun with Twitter and the Google charts API. You can now add an image to your blog, web site or wherever and show a picture of what kind of a twitter user you are. All you need to do is embed an image and give it the right source:

For example my user name is codepo8, which would be:

And the resulting image is:

For John Hicks for example it is:

And the resulting image is:

How it is done and how to “change stuff”

You can download the source code and have a play with this (I hope this will not spike my traffic :) so it might go offline if that is the case). There’s really not much magic to this:

First I get the user name and filter out nasties:

$user = $_GET[‘user’];

$isjs = “/^[a-z|A-Z|_|-|$|0-9|.]+$/”;

if(preg_match($isjs,$user)){

Then I set the content type to show the image and use cURL to get the information from the user’s twitter page.

header(‘Content-type:image/png’);

$info = array();

$cont = get(‘http://twitter.com/’.$user);

I get the information using regular expressions and put them in an associative array:

preg_match_all(‘/([^>]+)/msi’,$cont,$follow);

$info[‘follower’] = convert($follow[1][0]);

preg_match_all(‘/([^>]+)/msi’,$cont,$follower);

$info[‘followed’] = convert($follower[1][0]);

preg_match_all(‘/([^>]+)/msi’,$cont,$updates);

$info[‘updater’] = convert($updates[1][0]);

The convert function removes the comma punctuation added by twitter and makes sure the values are integers.

I then need to determine which of the three values is the highest and define a scaling factor as the Google API only allows values up to 100. I then check what the type of the user is by getting the right array key and change the values for displaying.

$max = max($info);

$convert = 100 / $max ;

foreach($info as $k=>$f){

if($f = $max){

$type = $k;

}

	
$disp[$k] = $f * $convert;

}
	

I check the type and assemble the display string accordingly:

if($type = ‘updater’){

$t = ’ is an ‘;

}

	
if($type = 'follower'){

$t = ' is a ';

}
	
if($type = ‘followed’){

$t = ’ is being ‘;

}
	
$title = $user . $t . $type;

I assemble the labels array and the values array and add all up to the correct Google charts API url. I use cURL to get the image and echo it out.

$out = array();

foreach($info as $k=>$i){

$out[] = $k.’+(‘.$i.’)’;

}

	
$labels = join($out,’|’);

$values = join($disp,’,’);

$img = get(‘http://chart.apis.google.com/chart?cht=p3&chco=336699&’.

‘chtt=’.urlencode($title).’&chd=t:’.$values.

‘&chs=350×100&chl=’.$labels);

echo $img;

}
	

The rest are the cURL and convert helper functions.

function get($url){

$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, $url);

curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

$feed = curl_exec($ch);

curl_close($ch);

return $feed;

}

	
function convert($x){

$x = str_replace(‘,’,’‘,$x);

$x = (int)$x;

return $x;

}
	

You like?

Faster version (one cURL, instead of two)

Instead of setting the PNG header and echoing out the image you can also just set a location header at the end and redirect the URL request to Google’s servers. I guess they have more bandwidth. :)

I am spending far too much time keeping explanation tutorials of scripts in sync with changes in the code. This is why I wrote myself a PHP solution to do the work for me. I’ve found over the years that the best way to explain a script is to :

• Show an example
• Show the full source code
• Show the source code bit by bit followed by explanations what each part does

If you go and check Tutorialbuilder you’ll see that I managed to automate most of this with a PHP script. It does the following for you:

• It generates the tutorial parts from comments in the script source code.
• It converts the source code to displayable code (encoding it, adding line numbers, allowing for lines to be highlighted)
• It creates a downloadable version of the script with a correct file name
• It creates an executable version of the script without comments to link to with a script element.
• It can minify the script (remove all whitespace to cut down on file size)

In other words, it turns this source script into a tutorial like this using a template and some CSS (most taken from the YUI).

It is not a replacement for JSDoc but instead catered to be easier to use and explain the functionality of code rather than the syntax of the JS code itself.

Tutorialbuilder is licensed with BSD, so go nuts using it for yourself.

I am always fascinated by the amount of Ajax tutorials and examples out there that totally ignore the backend part of an Ajax app. A lot of times you’ll find page-long ravings about the 6-7 lines of JavaScript that allow the client to make an HTTP request but when it comes to talking about the proxy script needed to allow for cross-domain requests a lot is glossed over as “you don’t need to know this, just use this script”.

That would not really be an issue if the scripts offered weren’t that bad. Unsanitized URLs are the main attacking point for cross-server-scripting attacks. If you use a PHP_SELF as the action of your forms you shouldn’t be too confused about a lot of mail traffic from your server or text links on your site you didn’t sign off and get money for.

The other thing about Ajax information on the web that amazes me is that people keep complaining about the slowness and problems with converting data from one format to another on the client side. Let us not kid ourselves: even after all the articles, books and podcasts about Ajax we still have no clue whatsoever what a visitor uses to look at our products. We cannot tell for sure what browser is used, if there is assistive technology involved or anything about the specs of the computer the browser runs on. This to me makes the client side the least preferable place to do heavy calculation and conversion.

The server side, on the other hand, is in your control and you know what it can do. Complex regular expressions, XSLT conversion, all of this is much easier to do on the backend – and you know that the text encoding will work to boot. A lot of complexity of Ajax apps is based on bad architecture and design decisions and on relying on the client side to provide necessary functionality.

So if you ask me what the ratio of client-to-server code of a good Ajax app is I’d say 30% client and 70% server. The 70% on the server should be used to provide security, non-JavaScript fallback functionality (yay accessibility) and conversion of data to small, easy-to-digest chunks for the client (think HTML and JSON). The 30% client side code should mainly be used up to enhance the usability of the product and make it easier for your visitors to reach their goals.

So here’s my plan for 2008: whenever I talk Ajax I will try to cover as much backend as frontend. I’ll do this by partnering with other experts as I myself created some terrible PHP in the past. I hope that others will follow that example as Ajax is a wonderful opportunity to bridge the gap between frontend and backend engineering – and we have to talk to each other to create a good app.