ColdFusion in Context: Hiding Data in Plain Sight

How can you keep users from tampering with prices and identities? Counting on users not to tamper with forms or even cookie values as they interact with your site isn't always a good bet, as recent headlines have shown. Many shopping carts are vulnerable to tampering. Many sites that let users return without logging in again are vulnerable to individuals who simply change a character or two in the identifier you've written to their cookie or URL to see WHOM they can be today.

When ColdFusion manages clients (or sessions), it creates a token that has a "secret" relationship with the ID and stores both the CFTOKEN and CFID on the client's browser or adds them to the URL. Because it's hard to guess what token should be supplied for a given ID, this enhances security.

In a clustered configuration, you can't enforce continuity between pages by confirming these elements against session variables in the server's memory; because, the user may not always be served by the same machine she logged in on. You could use client variables from a common database, but it would be nice not to have to hit the database for every page.

This example creates a token containing user identification and permissions and pairs it with a UserID to make it hard for tampering users to create a valid combination. To do this kind of thing for yourself, you need to create strings using rules that aren't easily guessed by users and for which likely user manipulations won't result in valid-looking data. The result gives you the ability to confirm both identification and permissions on every page, without a database hit, even if you're in a clustered configuration.

Here's a tool you can use to build and read data in scrambled form to do this kind of work. Along the way, you'll generate a range of random numbers, insert characters into a string, work with number bases, read and remove characters from a string, do modulus division, and work with individual bits of a number.

Use pieces of this idea to protect other things that are precious to you, such as checksums in a shopping cart.

Add the UserID to a Random Multiple of a Secret Number

Creating a random number that falls within a given minimum and maximum is straightforward. The wider the range, the greater the number of variations on the value to be given to the same input.

Multiply the random number by the secret number and add the UserID to the result. The secret number must be larger than the largest UserID you plan to use; because, you'll remove multiples of the secret number when you decode this value to get back to the UserID. 

<cfset UserID=18>
<cfoutput>UserID=#UserID#</cfoutput>.
This would typically come from a query.
<p>
<cfset Temp=randRange(54,210)*12345+UserID>
Temp=randRange(54,210)*12345+UserID:
<cfoutput>#Temp#</cfoutput>
<p>

Insert Characters Into a String

You can weave other data into the number you've created. For example, you can assign each user to a permission group and insert the group into this number. The insert function puts the string you're inserting AFTER the position you name. In this example, the group number will be inserted after the third character of the original number so the group begins at the fourth position of the new string and the other characters slide to the right to make room for it. 

<cfset Group=5>
<cfoutput>Group=#Group#</cfoutput>.
This would typically come from a query.
<p>
<cfset Temp=insert(Group,Temp,3)>
Temp=insert(Group,Temp,3):
<cfoutput>#Temp#</cfoutput>
<p>

The product of the secret number and the low end of the random range has to have at least the number of positions you want to come before your inserted string for this to work (unless you want to check the length and tack it on the end).

Change from Base 10 to a Different Number Base

Because you inserted a number rather than a letter, this "string" can still be manipulated as if it were a number. The only caveat is that after the insertion, the value has to fit the largest integer ColdFusion will handle (unless you break it up and play with the pieces separately).

We normally use base 10 (digits 0 through 9) in daily life. We sometimes use base 16 (digits 0 through 9, A, B, C, D, E, and F). This example converts the input to base 20, something less common. You can use larger bases than this, but be sensitive to what might get spelled by your string. If you used base 36 (all digits plus the entire alphabet), you might upset someone from time to time. This example forces the result to upper case because it looks better that way. 

<cfset Token=ucase(FormatBaseN(Temp,20))>
Token=ucase(FormatBaseN(Temp,20)):
<cfoutput>#Token#</cfoutput>
<p>

Use the Encoded String

For this example, the Token is meant to be stored alongside the UserID. If the UserID embedded in the token is the same as the UserID stored alongside the token, this gives some assurance that the Token is valid. You might write them to a cookie; you might add them to a URL. Here's what you've created thus far. 

<cfoutput>ENCODE: UserID=#UserID#; Group=#Group#;
Token=#Token#</cfoutput><p>

Decode the String

Even though you can't really reverse the process, you'll reverse its results to read the token. For example, you don't know what multiple of the secret number was used, but you'll see that it doesn't matter.

Change from a Different Number Base to Base 10

Converting back to base 10 is straightforward; just indicate the base the number is currently in. Someone trying to guess the base could start with bases large enough to accommodate your largest letter and work backwards. However, the correct number in base 10 isn't flashing a neon sign because of the character insertion and multiplication we've done to get to this point. To it even tougher, you might insert some decoy characters after your base manipulation (grin). 

<hr>
<cfset TempIn=inputBaseN(Token,20)>
TempIn=inputBaseN(Token,20):
<cfoutput>#TempIn#</cfoutput>
<p>

Read and Remove a Character from a String

The mid function lets you read characters in a string starting at a given position and continuing for the length specified. In this example, we want to read the fourth character - the group - and it's only one character long. 

<cfset GroupIn=mid(TempIn,4,1)>
GroupIn=mid(TempIn,4,1):
<cfoutput>#GroupIn#</cfoutput>
<p>

Now we need to remove the group to use arithmetic on the result. The removeChars function works just like the mid function. It will remove every character starting at a given position and continuing for the length specified. 

<cfset TempIn=RemoveChars(TempIn,4,1)>
TempIn=RemoveChars(TempIn,4,1):
<cfoutput>#TempIn#</cfoutput>
<p>

Do Modulus Division

This is just a fancy way of saying to find the remainder after dividing one number by the largest whole multiple possible of the second number. For example, 14 mod 5 is 4; 5 fits 14 twice with remainder 4. The mod function doesn't care how many times 5 fits; it only cares about the remainder when it has done the division as many times as it can.

In this example, the mod function removes the secret number, leaving the remainder: the UserID. 

<cfset UserIDIn=TempIn mod 12345>
UserIDIn=TempIn mod 12345:
<cfoutput>#UserIDIn#</cfoutput>
<p>

If the UserID in the token matches the UserID alongside the token, then the group is probably valid also. 

<cfoutput>DECODE: UserID=#UserIDIn#; Group=#GroupIn#</cfoutput><p>

Work with Individual Binary Bits

Each binary bit of the Group can be meaningful. For example, the "1" bit might signify that the individual can obtain statistics, the "2" might mean that the individual can perform day-to-day work with the system, and the "4" might mean that the individual can perform administrative functions such as adding users. In this example, someone in Group 5 (1 plus 4) can run reports and perform administrative functions but not do day-to-day work with the system.

Because you can use the bitOr function to see if a specific bit is present in a number, you can easily test these bit-wise permissions. The bitOr function merges (shows the union) of the bits of the two inputs it's given. For example, the bit pattern of 5 is 101; the pattern of 2 is 010. Their union is 111 (7). If the bit in the second number is already in the first, their union will be the same as the first number. For example, the bit pattern of 3 is 011; the pattern of 1 is 001; their union is 011. Because the 1 bit is already part of the number 3, merging it with 3 leaves 3 unchanged.

In the example below, because the group is five, bits four (admin) and one (statistics) are present. To see this decoding work, simply save all this code as hiding.cfm, change the group, and watch the result. 

<cfoutput>Permissions:<br>
<cfif bitOr(Group,4) is Group>Admin (4)<br></cfif>
<cfif bitOr(Group,2) is Group>Work (2)<br></cfif>
<cfif bitOr(Group,1) is Group>Statistics (1)</cfif>
</cfoutput>

Variations on the Theme

You could also encode the UserID that sits alongside the token. You could use just a token, but using multiple pieces of data encoded (or not) in different ways makes it harder to find a result that opens a door by just incrementing one of them. It reminds me of the city dweller who foiled burglars by locking just half of her locks; the burglars wound up locking as many as they unlocked. Changing both the UserID (unlocked in this example) and the Token (locked in this example) leaves a tampering user out in the cold.

Your data doesn't always remain under your control. With checksums generated through techniques like this, you can add a level of security to help you sleep better at night.

This kind of encoding lets you have more trust in the data you expose to the client and get work done with fewer hits to the database. Strings which look like simple (although unintelligible) values can be complex storehouses for data. Using these techniques, you can hide data in plain sight. =Marty=

[Lines have been added since initial publication to make the code example more self-explanatory.]