views:

197

answers:

5

Hi All,

I was wondering what backdoor techniques you have used in the past during application development for testing. Which are the easiest, least invasive and easiest to remove prior to release methods?

So far I have come up with two main approaches:

1) Active - i.e. the developer would send some type of command to the program either via a specially crafted command line or input during execution

2) Passive - i.e. a registry key or ini file.

Generally I don't think there is a right or wrong answer to this question (unless it includes leaving the backdoor in for releases), but I would be interested to hear what approaches others have taken over the years. :)

+2  A: 

I believe that if your application is properly designed, you should not need to go through a "back door" to test it.

Kevin
+1  A: 

I set one up to impersonate another user by typing their username as my password.

JosephStyons
+4  A: 

Given the faster development cycles and the "oops" factor, I've pretty much abandoned the backdoor approach in my apps -- I have, however, stepped up my unit testing and create a "stub" app to test the specific piece of the app I'm currently focused on without having to drudge through the "real" app -- (the stub is disposable) I'm not a big proponent in creating my own security holes -- figured there's plenty of folks out there that are just waiting for that job ... :)

just my 2 cents ...

Borzio
I completely agree, which is why I emphasised that it would be removed before release. However with more complex programs sometimes it is the only way to make sure you have dotted the is and crossed the ts. Unit tests help, but it is sometimes hard to replicate highly specific cases.
Konrad
During dev, perhaps a single sign-on approach to ease the quick run-through; however, for testing I would recommend an automated testing tool (such as AutomatedQA or others) to eliminate all manual efforts in that regard and gen a very repeatable test environment.
Borzio
+1  A: 

You can hide special preference screens under certain buttons or Help About menu items that only work when say you hold down Ctrl-Shift and then click.

To touch on something someone else said - I always put an impersonation layer into my programs. It will help you to debug issues when a user calls you (you can see exactly what they see).

tyndall
+1  A: 

Although I would not make back doors, I typically keep some kind of functionality that lets me trace data used for processing that may not be obviously visible in the application. Typically a URL parameter or such for web-apps.

This can be really nice when working with complex data that may be hidden in far-off systems. We usually dump it into the html as a comment when the correct parameter has been supplied.

krosenvold