Someone on cf-talk today asked about encrypting URL values. They wanted to make sure the user didn't mess with the values. I replied with some important things that I think people should consider:
-
Encrypting URL values is not enough to stop users from messing with them. A user can certainly change the value. Of course, chances are likely the new value will not decrypt, but again, you can't stop them from changing (or removing!) the value.
-
Whether or not you encrypt your code should be secondary. Your primary goal should be to ensure that your code works correctly if the url value is missing or incorrect. Some examples are:
- Ensure the value exists.
- If it must be numeric, ensure that it is a number.
- If it is a number, and represents a auto-number type field, ensure the numeric value makes sense. Ie, -1 is a number, but will not be a PK in your database. Nor will 3.14159.
- If your application uses logic to determine which records are available to users (ie, maybe only where active=true), then your "view" logic should also have that logic. What do I mean by that? If you have a list of press releases where the logic in sql is, select * from tblPressReleases where active=1, your view page, which probably does, select * from tblPressReleases where id = #url.id#, then you need to also add a 'and active=1' to your sql statement. Basically you make sure the logic is preserved when you are getting all records, or just one. (By the way, I know select * is bad, and I know a queryparam above would be better.)
The main gist of this is - I would not worry about encrypting the URL first. I would start with making sure my logic is rock solid. There is nothing wrong with encrypting the URL. It will slow down the typical script kiddie, but certainly do not rely on it.
Archived Comments
-1 could be a PK in my database. An integer in SQL Server will hold numbers from negative 2 billion and some to positive 2 billion and some. If I wanted to double the number of PK's without going to a bigint, I could start the numbering for the table at negative 2 billion and some instead of zero...
Yes, a db certainly could start a PK with a negative number, but I have never seen anyone do that before. Most folks start their autonumber with 1 and therefore should ensure that ID is greater than or equal to 1.
I think what's missing is WHY? Sounds like the programmer might be passing values back and forth other than what the user is capable of entering, such as sending a shopping cart in the form/url (shudder)on each trip....
The programmer should probably be using session or client variables.
In the past, I've also passed a "state" variable that is set on the return trip back to the client which is used to determine the last action of the user, so if the user hits a back button and submits again, you check the state variable in the session against the state variable (hidden) in the form. No Match = Improper Navigation.