Information Seeding in Testing

Short post today!

There was an episode of The Good Wife, where a known criminal, represented by the show’s lawfirm, suspected there was an information leak at the firm.

He and a partner told the key players at the firm that they’d be shipping drugs to the airport at a particular time. But they told each person a different time, one hour apart.

So, every hour, they’d go drive around and see if they got pulled over.

At one particular time, they did.

The DEA agents that pulled them over saw they had a bunch of cocaine. CAUGHT!

Except, it wasn’t cocaine, it was pancake batter, which was confirmed when they opened the trunk and saw like 50 flattened boxes of Aunt Jemima pancake mix LOL!

They found the leak because of when they got pulled over, and it turned out to be the show’s main character!! But she didn’t actually know, because her phone was actually tapped by the NSA, blah blah.


The point of that story was, sometimes we can use that approach to help identify where bugs live.

And I don’t know what this approach is called, but I guess “Information Seeding” is an ok description.

Here are some examples:

Cross Site Scripting (XSS): When testing for an XSS vulnerability, instead of just putting an alert(1), or a blank popup, put some information in there about where the attack was tried. If the popup shows up, then you automatically get some information about where to check in code to fix the problem, especially if it’s a persistent XSS attack.

Data Migration: When you have a chunk of data that’s going from one system to another, and you expect some parts of the data to be changed to fit the next system, try setting each piece of data to some non-default value. Check each piece. If something didn’t change that should’ve, OR, something changed that shouldn’t have, then you’ll know.

Database Updates: Databases can be surprisingly complex. When you put information into one via one part of the system, try reading a bunch back out of another end of a system. Complicated queries with a lot of moving parts can often yield critical bugs, so inspect the larger superset of data that you read back out, and confirm that it looks correct.

Where else can you think to try this strategy? Where can you seed information into the system, to tell whether it’s behaving properly?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s