Monthly Archive for September, 2005

chunky bacon

Published
by
jonh
on Thursday, September 15, 2005
in Code and Funny
. 0 Comments

Man I love cartoon foxes which it why I love [Why's (Poignent) Guide to Ruby]

Skip to chapter 3 if all you want to see is foxes…

Oh and check out [Daring Fireball on the new iTunes theme]

laterz…

PHP and forms with a sprinkling of security

Published
by
jonh
on Thursday, September 15, 2005
in Code
. 0 Comments

Recently one of my work collegues asked me to investigate some spam he was getting on his personal website account. These little challenges always intrigue me, so I said yes.

After much prodding in the email headers it became clear that the spammer was using a simple Contact from set up on the website.

Firstly I thought this problem down to the form using the POST method, and the PHP assuming the names of the form elements were assigned to global variables as it passed via the URL.

For example if the form looks thus:


<form name="silly_form" method="post" action="$php_self">
<input name="email"/>
</form>

Now when this form is submitted the PHP used to look like this:

<?php
if ($email)
{
mail("john@example.com", "Hi", $email);
}
?>

But that would work if you called the page like this:

http://example.com/page.php?email=fake@example.com

So the code was changed to this

<?php
if ($_POST['email'])
{
$email = $_POST['email'];
mail(”john@example.com”, “Hi”, $email);
}
?>

But still the spam kept a coming….

This is becuase you can create a form in Javascript which can then be submitted, and it’s not too much of a jump to automate the creation of the form.

Here’s what the Javascript could look like:

<SCRIPT LANGUAGE="JavaScript">
function fnSubmit() {
document.emailform.submit();
return;
}
</SCRIPT>
<body LANGUAGE="javascript" onload="return fnSubmit()">
<form method="post" action="index.php" name="emailform">
Email: <input name="email" type="text" value="address"/><br />
<input type="submit" />
</form>

So we need a new approach, some kind of Turing test to make sure the user is human. I’m sure you’ve all seen the images that you can generate using either [CAPTCHA] or [the] [same] [idea]but it’s only a simple contact form.

So we developed a little piece of code that asks a user to enter two characters, that we tell them to enter and these are checked by the contact code. These characters are simple taken from two strings, one 32 characters long, and one 13 characters long. The current day and month are used to select the characters so they can be easily checked on the other side.


<?php
function GetCharacters()
{
// create the array
$day_string = "thirtytwocharactersjustincase";
$month_string = "thirteencharacters";
//
// get todays date
//
$day = date('d');
$month = date('m');
//
// get the array characters
//
$one = $day_string[$day];
$two = $month_string[$month];
// result
$result = $one . $two;
return($result);
}
// check characters
function CheckCharacters($a_characterArray)
{
// create the array
$day_string = “thirtytwocharactersjustincase”;
$month_string = “thirteencharacters”;
//
// get todays date
//
$day = date(’d');
$month = date(’m');
//
// get the characters
//
$characterOne = $day_string[$day];
$characterTwo = $month_string[$month];
$characterArray = $characterOne . $characterTwo;
//
// check the characters
//
if (0 == strcasecmp($a_characterArray, $characterArray))
{
return(true);
}
return(false);
}
?>

And there we have it, just enough Turing test for a contact form - enjoy…

Unit Testing and C++

Published
by
jonh
on Wednesday, September 14, 2005
in Thoughts
. 0 Comments

Having read this article, [A Set of Unit Testing Rules], pointed out to me by my good friend Pete at work I was spurred into a frenzy of thoughts.

The article talks about what a Unit Test should be and what a lot of people call unit tests and the rules for how to unit test.

At first I thought this article was going to be quite interesting and talk, from a code point of view, about how to write code that is easy to test in practice rather than just in principle. Unfortunately this isn’t really the case so I’ve written this little piece so try and explain what I think the pitfalls of Unit Test are in reality.

If you’ve not read the article then the jist of it is that each function should be unit tested, not through an interface or other class, but directly. Now this is all well and good for functional languages (C etc) but not so good for Object Oriented programming. The main issue is that of protection.

I write mainly C++ where I work (with a bit of Java chucked in on the odd occasion) and our product has a large number of DLL’s and a huge unit test suite. Now unit testing a DLL normally involves using the DLL interface and checking that all the functions give the correct results, but this is contrary to the idea of testing each function on its own.

So the first problem is that you can’t just test and arbitrary class from a DLL, you can only instantiate classes that live on the interface. To have access to all the classes contained within a library, the library needs to built statically, making it much larger than the DLL’s and requires the client to recompile their code rather than just drop a DLL in.

There seem to be two general solutions to this, having a specific test building configuration to build all the libraries statically which will be a bit of a maintainence nightmare, or having every project/DLL actually be a static library with the thin interface being the DLL and including the library, which means you have double the projects in your workspace.

The second, and slightly more annoying problem, is that of protected and private functions within classes. The idea of protected and private functions and data and why it’s important is a large area of object oriented design, but due to this restricted access, testing these functions can become very difficult.

Once again there are two solutions which we currently employ to get around this. Testing these functions either requires the tester to create a wrapper class that inherits from the test class and provide access (via stub functions) to the protected member functions, or requires the coder to include the tests within the class bulking the code out substantially.

I come across both of these problems on a daily basis and so far I haven’t found a good solution to them. Currently we create wrapper classes for testing purposes and create thin interface DLL’s and keep the code in static libraries, but this is far from optimal.

So, how can good testing practice and good coding practice marry in such a way as to not alter the process of creating software, at the moment I have no idea, it’s almost as if the test class has to a friend of every class or some kind of ‘god’ object so that nothing is invisible. There are no real answers yet but I’ll have a think maybe something will turn up :)

For now we’ll just carry on getting the job done…