Postman is a great tool for exploratory testing and the Big List of Naughty Strings (BLNS) is a great resource for exploratory testing, so I wanted to put the two things together into a Reese’s Peanut Butter Cup of tasty test flavor.

Step One: Getting the Naughty Strings

My plan was to use the Collection Runner to put each naughty string into my chosen API parameter. To do that, I would need a list of strings in a csv format. The BLNS repo includes a couple files with the strings encoded as base64, which is necessary for the csv parser, so my first quick and dirty solution was just to cut and paste the strings from blns.base64.json into a text file, slap a header on top and save it as a csv.

The problem is that the json file hasn’t been updated in over a year, so it isn’t in sync with the latest blns.txt. My solution was to make a little shell script based off of the one BLNS used to make the base64 files.

# Get the latest blns.txt
wget https://raw.githubusercontent.com/minimaxir/big-list-of-naughty-strings/master/blns.txt -O blns.txt

# Start a new output file with "encoded" as the header
echo encoded > naughty_strings.csv

# Go through the blns.txt file and save the encoded version 
# of each string that is not a comment or an empty line
commentChar="#"
while read p; do 
        firstChar=${p:0:1}
        if [[ "$firstChar" != "$commentChar" && "$firstChar" != "" ]] ; then
                echo -n $p | base64 >> naughty_strings.csv;
        fi
done <blns.txt

With this script, I can get the latest version of the naughty strings list as a csv-formatted list of encoded strings whenever I need it.

Step Two: Turning Naughty Base64 into a Postman Variable

With the data file sorted, the next step is to get the encoded variable produced by the Collection Runner and make it available to put into my request body. This requires just three lines of code in the Postman Pre-request Script tab:

// The atob library does decoding
var b64decode = require('atob');

// Get the base64 naughty string injected by the Collection Runner
var fn64 = pm.variables.get("encoded");

// Set the decoded value as the "naughty" variable
pm.variables.set("naughty", b64decode(fn64))

Side note: Am I the only one that thinks the npm modules for handling base64 strings are named backwards? When I see “atob”, I think “ascii to binary”, but this is actually the module for decoding binary strings. Javascript is so weird sometimes…

Step Three: Using the Naughty String

This is the easy part – just refer to the naughty variable the same way you would any other request variable.

Step Four: Check the Response

I’m looking for two things when I do this kind of testing. First, does the service handle an invalid string gracefully with a 400 Bad Request response, or does it choke on it with a 500 Internal Server Error and/or unhandled exception call stack. Second, if the string is accepted, is it recorded correctly in the database, or is it bungled up somehow by encoding errors.

var encodedParam = pm.variables.get("encoded");
var expected = pm.variables.get("naughty");

// Because the strings are naughty, it is 
// better to log the encoded string value
pm.test("No 500 response : " + encodedParam, function () {
    pm.expect(pm.response.code).to.be.oneOf([200,400]);
});

// if the POST wasn't ok there is no need to continue
if(pm.response.code === 200){
    var jsonData = pm.response.json();
    pm.test("First name in response is correct", function(){
        pm.expect(jsonData.booking.firstname).to.eql(expected);
    });
}

Step Five: Run the Test

Once the Pre-request and Test sections are complete, it is time to run the test.

1. Put your request in a collection, even if it is the only request in there
2. Click the arrow next to the collection name, then click Run to open the Collection Runner. 
3. In the Collection Runner, click the Data button and enter the csv file
4. Run the collection and see what happens!

 

 

• Postman