How Skeleton Strings Can Help Your Testing

To help me when I am probing an application under test, I keep a bundle of strings in my back pocket to use in web, mobile, and desktop applications. Just as skeleton keys unlock doors, these generic skeleton strings open up a wide variety of defects. When your users see an edit box or a text area, they’re expected to type a set of letters and/or numbers into them.  The application processes these collections of characters as strings and performs some processing magic on them.

The Hamlet Test
Most edit boxes pass the string you enter into some sort of processing or database. Within the processing process or the database table, the code expects some sane limit on the amount of text entered. William Shakespeare's Hamlet, stripped of line breaks and punctuation, contains 135,014 of the most thought-provoking characters in the English language. This should exceed the limits of most individual controls unless you're testing a word processor. If you see the final stage direction, Exeuntbearingoffthedeadbodiesafterwhichapealofordnanceisshotoff, you will likely see the computer equivalent when you click Save. If you want to try the Hamlet test yourself but don’t want to copy edit the play yourself, you can borrow my copy here.                                                                                                   

When dealing with a number-specific field, which prohibits alphabetic character entry, I have strings of 100,000 and more digits. Both tests quickly test the boundaries of edit boxes whose limits are unknown.

Punctuation
Edit boxes, particularly on the web, might need to exclude certain punctuation characters if the application strips HTML markups and the like. As such, I like to try each text entry control with `~!@#$%^&*()_+|}{[]\":;'<>?/.,’ to see what will happen. If you're testing with a different language or keyboard, try out some other punctuation marks. In this case, it might not crash spectacularly, but the absence of characters you entered might identify a shortcoming in your application or web fonts.

Foreign Characters
The basic character set in your application handles a number of foreign characters even if they're not on your keyboard. I like to see how my application consumes a string like àáâãäåæçèéêëìíîïðñòóôõöøùúûüýþÿš. I am a fan of both Ľuboš Bartečko and José José. Why wouldn’t I want to register as ĽubošJosé1?

Foreign Characters in Another Character Set
You can put a string of traditional Chinese like 您可以撼動它周圍 你可以去向上和向下 你可以失去你 但你不能無視我的化工技術 onto your clipboard, so why not try it in your application? You'll find out quickly how your application and database handles different character sets. Many other character sets are double-byte character sets, which means each individual letter or glyph takes up twice the space of a Latin character; this might yield some unexpected results.

Right-to-Left Foreign Characters
Most languages, including English, read from left-to-right. You're doing it right now. Other languages, such as Hebrew, Arabic, and Urdu, read from right-to-left, so try a string like آپ کے ارد گرد ہلا کر سکتے ہیں تم جاؤ اور نیچے کر سکتے ہیں تم ہار جو آپ محسوس کر سکتے ہیں لیکن تم نے میری تکنیکی کو نظر انداز نہیں کر سکتے to see how your application handles it. You might find that your edit boxes don't know how to mix it with left-to-right text (like the word processor I'm using now) or you might discover that design elements on your website go awry when trying to justify or align writing that it thinks is backwards.

HTML and JavaScript
In many cases, your app or website should not render user-entered HTML. At the very least, rendering the HTML will throw off the carefully crafted layout of your site. At worst, this behavior makes your site subject to attacks like cross-site scripting. I like to use <h2>DOG</h2>; if there’s suddenly a large dog on the page, either I’m browsing Scoobypedia again, or the HTML was not stripped. Likewise, I like to see if the site renders a link for the string <a href=”http://cnn.com”>CNN</a>. Either indicate the potential for users to, at the very least, do things that would make your designers cry or something more sinister if they can embed JavaScript such as javascript:alert("Danger!"); into your edit boxes.

Encoded HTML
Sometimes, the software solves the HTML insertion by escaping out or barring the angle brackets in the HTML tags. However, the string %3Ca%20href%3D%22http%3A%2F%2Fcnn.com%22%3ECNN%3C%2Fa%3E encodes the HTML without using angle brackets. How does your website handle that?

SQL Injection
A SQL injection attack occurs when a malicious user inserts a string into an edit box designed to append a malicious query to the end of a routine database query using quotation marks or apostrophes. While it’s not a comprehensive penetration test, I throw in a SQL injection style string like hello"or 1=1 DROP TABLE or murphy'; drop table Users—into edit boxes to see what havoc they wreak. You can learn a little more about SQL injection here.

SQL Keywords
A long time ago, I ran across a situation where the interface avoided SQL injection problems by barring SQL keywords. This might have worked in certain situations and in a world where testers weren’t naming their children Drop Table Users Noggle just to see whether they got birth certificates or not. Out of habit, I always stuff SELECT FROM WHERE GROUP BY HAVING ORDER BY INSERT UPDATE WHERE MERGE DELETE BEGIN WORK START TRANSACTION COMMIT ROLLBACK CREATE DROP TRUNCATE ALTER into a text box.

In addition to these, your own experience will show you other collections of keystrokes to put into your wallet that you can later pull out to try to loid your applications’ doors. You’ll learn what foibles your developers have and what mistakes they often make that you’ll have to spot every time they do. These samples give you a head start.

What are your favorite strings to insert in text fields? I’m sure other readers would like to know.