How Skeleton Strings Can Help Your Testing


Brian Noggle writes about how he uses "skeleton strings" to help him when he probes an application under test. Just as skeleton keys unlock doors, these generic skeleton strings open up access to a wide variety of defects.

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.

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=””>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 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.

User Comments

Jeremy Carey-Dressler's picture

While I agree with your idea of testing SQL injections, why would you use drop table?  It is likely you'll break the system badly by running that test.  Is there no other SQL injection you could recommend that would be less likely to break the system under test?



February 10, 2014 - 1:52pm
Danny R. Faught's picture

Great stuff! For testing with long strings, I would expand this idea by using "counterstrings" - see my StickyMinds article "A Look at PerlClip". They give you a measure to see exactly how much of the string you have, and you can generate a string of any size. PerlClip also has a rudimentary method of generating the full range of ASCII characters. I would like to expand the tool to cover various things in the Unicode space as well, to include more of the non-Roman characters like you suggested here.

February 12, 2014 - 6:02pm
Matthew Heusser's picture

Isn't it time you started writing for us again, Danny? :-)

February 13, 2014 - 1:49pm
Matthew Heusser's picture

I have no financial benefit to writing this comment, but reading this post, I am reminded of brian's book, "John Donnelly's Gold." (That is, the author of this post, Brian Noggle, also wrote the myster/suspense novel set in a dot com bust world featuring recent laid-off former dotCom wokers ...)

The book is $0.99 - a dollar - on amazon kindle.

I have a copy. It's a great read. 

I noticed it mentioned in his bio and thought it was worth submitting a link.

Great to have you writng for us, Brian. Let's keep it up!


February 13, 2014 - 1:49pm
Madhava Verma Dantuluri's picture

Excellent article, SQL injection is always a challenge while breaking the system. The results always were surprising for me.

February 13, 2014 - 10:12pm

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.