Let’s play a bit with numbers

Posted: 13.3.2013 in Ei kategoriaa, Testing

When I see the number input, I have several patterns which I like to test. Here are few of them:

  • 08, 0100 – reason behind this is, that text to integer might interpret that to octal number. In that case 08 is illegal value, which can result strange things.
  • 8-1 – reason behind that is, that sometimes SQL query calculates that
  • 0xa – in that case the text to integer might translate the number to hex number.
  • 1e3 and 1e-3 – those might be interpreted 1*10^3 and 1*10^-3 (=1000 and 0.001)
  • 2147483646, 2147483647, 2147483648 – these are maximum ints in many cases
  • -2147483647, -2147483648, -2147483649 – these are minimum ints in many cases
  • 4294967294, 4294967295, 4294967296 – this is maximum on unsigned integer
  • Some huge number which is far beyond previous numbers

And let’s go a bit more detailed and real life situations to some of these.

At one C++ project the logic were following:

input number X
if (x+2 < fixed number)
loop from 0 to x

So if we input anything below 2147483646 we get correct functionality. But if we insert 2147483646, the result is suddenly -2147483648 and we enter to the loop. This is far from the expected result and in worst case it even opens the security issue. That system didn’t crash. It just stalled for 15 minutes which blocked some batch processing.

Then another issue is 8-1. I usually test that at web applications where I expect the number to be index. If the result is same with numbers 7 and 8-1, there is most likely SQL injection security issue. At the code is query: SELECT * FROM table WHERE id=$intput$. If it calculates 8-1, then it can also parse any other query. That can be e.g. 8+or+1=1 which might cause some really exciting result. Or it can be even such query, which dumps out the user database.

08 is interesting. I’ve seen it only at build number and as compile time error. But give it a shot. You never know what kind of number parser is at the engine room. It can lead to strange errors, or some other fancy effect which the user might dislike. And in that case try also 0100, because if it is parsed to octal, the result is 64. And it is clearly wrong. 0xa is same kind of thing. If the parser parses it to 10, then you will be in trouble if users don’t know that 0x is prefix for hex number. 0x100 is not same as 100, it is 256.

1e3 is exciting thing. I’ve met that kind of input parsed wrongly once. The system were going thru the document and catching all URLs. For some reason if URL contained that kind of string, it was parsed to number and to normal format. E.g. that would have been 1000.

Of course I try also normal border cases, classes, some random text etc. But these are the cases outside them. Do you have some specific patters which you try? And why are you trying them? Leave me the comment.

  1. Joe says:

    Nice – I’ll be making a note of these for using in the next few weeks, thanks!

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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