I'm a programmer working on an application where the only choice/vs/deadline was to implement symmetric encryption on url parameter values. The data is insensitive in nature, but we needed to prevent sales agents from peeking on each other's leads. (Keys are generated on session creation and are cryptographically strong.) Sessions are expected to end frequently.
The role hierarchy was
Manager--> Supervisor--> Agents. The data structures don't currently account for these roles in a way to strictly enforce who can see what. Getting this information from the database was NOT anywhere close to straightforward. (Recursive Database.)
I know that this technique is way down on the list as a defence against parameter manipulation. What would have been a better technique?
Role-based checking is not an option.
[Additional information] The urls built and sent to the client before I made any changes looked like:
The specific threat surface here is parameter manipulation against
Agent ids are assigned uniquely to each agent. So if Agent A wants to look at Agent B's stats, he could have entered agentId=22222 in order to look at that agent's quotes and current sales statistics.
Again, Role-Based checking was not an option for me: I was unable to make changes to the database OR the persistence tier.
My solution was to use a session-created encryption key (using Java's KeyGenerator class) and encrypting the outbound urls sent to the client. So now, the url looks like:
Now, if someone tries agentId=22222, the server will decrypt what it thinks is ciphertext and will ultimately create an invalid character sequence.
(This leaves open the possibility that an existing agentId could be found, but quite unlikely that it would be relevant to the person performing the attack.
I will stress that this question isn't about optimal security (which would be role-based checking to ensure resource access) and about trying to squeeze some security in a grey area.
The parameter encryption solution here was recommended to me by one of our security guys. I got one takeaway I hadn't considered on this solution--broken urls--and will be using that as well as the maintenance issue created by this solution to argue for the time to enforce the access rules in a less stopgap fashion.