Test and Debug Your Web Applications with Tamper Data

Most Perl programmers at some point in their career are involved in a project that includes a bit of Web development.  One of the Firefox plug-ins that I occasionally find useful for the debugging and testing of Web applications is the Tamper Data plug-in for Firefox.  In particular, from a debugging perspective it allows you to capture HTTP and HTTPS headers as well as POST parameters, which can allow you to verify the requests that are being sent to your Web application.  On the testing side, some basic security testing can be done as well, since it allows you to modify captured HTTP/HTTPS headers and POST parameters prior to transmission. While someone that is heavily involved in the security testing of Web applications, would likely be better served by more robust intercepting proxies (e.g. Burp Proxy, etc) it is a nice plug-in to use to introduce people to some of the basic techniques that can be used to test Web application security.  An example of a captured Facebook login request can be seen below.

 

Notice, how it shows the different POST parameters and their values?  Any one of these parameters in the request could then be modified and submitted to the site.  Once the “OK” button is clicked, the request will be forwarded to the Web application, including whatever modifications that you have made. 

Testing Your Tests?

This is an idea that I still consider in the “alpha” phase, and one that I have not yet even begun to code a proof of concept of, but it is an idea that I would be interested in some community feedback on.  Testing has always been an integral part of the culture of Perl and one of the great strengths of the Perl community.  At a NY Perl Mongers meeting in June I saw a preview of the YAPC talk by James Keenan on testing that I think provides a nice introduction to testing for any that are not familiar with Perl’s Test::* modules. Here is a link to the video of the YAPC talk if any are interested:  http://youtu.be/A31VhNeGaw0

What I have been thinking about a lot lately though, is “how do you test your tests?”  In other words, how you do you know if the tests that you put in place are truly adequate.  What I have been thinking of is building a Perl program that will create let’s say 10 variants of a program that each contain a random “mutation” of the original code.  For example, let’s say that it is a math program being developed and tested, at random points in the code a mathematical operator (e.g. +) can be changed to another random operator (e.g. -, *, %, etc). This process would be repeated 10X to create 10 variants of the code that each has one random operator changed. 

Each of these variants could then be run against the testing set.  If the variants result in testing failures in all cases, the tests probably provide sufficient coverage of the codes functionality.  If one or more of the variants pass all tests, it is an indication that the tests are not robust enough to adequately assess the proper functionality of the application. I’ll try to post some proof of concept code soon.  Thoughts?

A Review of the Book "Modern Perl"

I recently finished reading through a copy of Modern Perl by chromatic and think the book serves as an excellent Perl resource, albeit one that I would not recommend as book for a first time programmer.  The book Modern Perl, is one that I believe is much more suitable for readers with at least some basic programming experience and I think it will be of the most benefit to those that already work with Perl, but have not kept up with the latest developments in Perl.  Perl has changed quite a bit over the last 7-8 years, in ways that would pleasantly surprise those that have not been following the evolution of Perl.  I particularly liked the conciseness of the book and how much information it managed to cram into 181 pages, yet it is this same conciseness that I think may make the book challenging for a programming novice. 

For more experienced programmers the book offers a wonderful way to rapidly bring themselves up to speed on the more modern ways of approaching Perl programming.  Coverage of such modern practices ranges from mentioning small changes like using cpanminus as a way to install CPAN modules and the newer three argument syntax for opening files to coverage of some of the major changes in Perl, such as the development of Moose as a more modern approach to OOP.  I was especially pleased to see the chapters towards the end of the book, such as those on “Style and Efficacy”, “Managing Real Programs”, and “What to Avoid”.  These chapters make the book one that goes beyond just teaching how to program in Perl and turns it into one that stresses teaching the authoring of quality Perl code. 

I would recommend that anyone currently making use of Perl take the time to look through a copy of Modern Perl, particularly since the author gives you the option of downloading the book entirely for free. For more information about Modern Perl visit - http://www.onyxneon.com/books/modern_perl/index.html

Basic Error Handling in Perl

Anyone that has ever sat at a computer help desk quickly becomes aware of just how many issues a user can have with even the seemingly easiest and most user friendly software around.  Whether it is the user that “lost” his email because he clicked on one of the sort buttons and now can’t find today’s messages or the user who manages to crash a calculator-like program because he decides to type “two” instead of “2”, it becomes readily apparent that computer users will often do things that many developers would find unthinkable.  It is important that software developers learn this lesson early in their career.  Whether for malicious reasons or innocuous ones, your application will be abused by those that make use of it.  While some previous posts discussed the basics of input validation and some modules that could be used to perform input validation, these are not the only useful techniques to consider.   Error handling is also a useful technique for dealing with potentially problematic situations that could arise.  For example, perhaps your application requires access to a file on removable media for certain functions or connection to a certain network resource.  While an “or die” type statement alone could be used to deal with the situation, error handling may provide you with a way to allow your application to route around the error or to at least fail gracefully.  The basics of Perl error handling is the eval statement, which is used as follows:

#!usr/bin/perl

use strict;
use warnings;

my $x=5;
my $y=0;

eval {
    my $result=$x/$y;
    print "$result";
    1;
} or do {
    print "Error: $@\n";
};

The above code works because if the code in the eval block executes it will return true, otherwise it will return false, and cause the code contained in the do block to execute.  The above example, forces the do block to execute by intentionally dividing by zero. 

It is also notable that there are several Perl modules that are highly useful for error handling as well such as Exception::Class, Error, and TryCatch.  These modules will be looked at in more detail in a future installment.  

Static Code Analysis with Perl::Critic

It is very important for any group that develops software to adhere to a set of software coding standards.  These coding standards not only help to improve the readability and maintainability of the code base, but can also help to improve the security of the resultant applications.  Any set of coding standards should describe a set of best practices for dealing common types of coding issues. One way to help ensure that code follows the standards dictated by industry and organizational best practices is to make use of a static code analyzer.  For Perl, a popular static code analyzer is the Perl::Critic module.  Before we take a look at what this module does, let’s purposely create some bad Perl code as a test case and save it as badperl.pl.  

#!/usr/bin/perl

$string='string';

#assume $filename provided by user
open (STATFILE, "/home/user/$filename");

#assume input provided by $user
system("cat $input");

 

Now that we have this example of some really bad Perl coding practices lets create a few line of Perl to run our script through Perl::Critic.

use Perl::Critic;
  
my $file = 'badperl.pl';
my $critic = Perl::Critic->new();
my @violations = $critic->critique($file);
print @violations;

If we execute the above we will end up with output as follows:

chris@chris-Aspire-5742:~/Desktop$ perl critic.pl
Code before strictures are enabled at line 3, column 1. See page 429 of PBP.
Bareword file handle opened at line 6, column 1. See pages 202,204 of PBP.
Two-argument "open" used at line 6, column 1. See page 207 of PBP.

 

The Perl::Critic module tells of several problems with the first being that “use strict” was not made use of in our badperl.pl script.  Next, it informs us of some problems with the open statement as well.  The form of open used in that sample is a depreciated syntax which makes use of global typeglobs (the Bareword error), rather than a more modern lexically scoped file handle.  Perl Critic also points out that the older "two argument" open syntax is used rather than the newer "three argument" syntax which can prevent some potential issues with file names that contain special characters and thus improve the stability and reliability of the code.  Using a static code analyzer is a strongly recommended practice and in the majority of cases will help ensure an improvement in the overall quality and consistency of the code, even though compliance with policies may not always be 100% possible.  

 

It is important to note however, that static code analyzers are very useful tools, but that they are not able to catch every possible coding mistake.  In particular design related errors in the code will not be picked up by static code analysis.  For example, in badperl.pl the $filename is never validated and this may provide a potential vector for a directory traversal type attack.  Likewise in the system call, prior validation is also lacking and could allow a user to provide something like “/etc/passwd” as $input.  These issues however were not raised by this analysis, however.  Remember that passing a static code analysis does not necessarily equate with secure code.